E-commerce mobile speed & conversion calculator.

Faster stores tend to convert more. A Deloitte study of brands in Europe and the US, run over four weeks, found that a 0.1 second gain in mobile site speed came with 8.4% more retail conversions and a 9.2% higher average order value. That is one study across many brands. Your own store may move more or less, so measure before and after any change.

It takes the seconds you plan to cut from your mobile load time (LCP) and counts them in steps of 0.1 seconds. Each step adds 0.85% to your current conversion rate, and the total lift is capped at 65%. The model is a straight line with a ceiling. It does not use live data from your store, so the result is an estimate.

Revenue today = monthly visitors × conversion rate × average order value × 12. Lift % = seconds cut × 10 × 0.85, up to a maximum of 65. Added revenue = revenue today × lift % ÷ 100. The calculator shows that added revenue as the amount a slow store is leaving on the table each year.

It is a FactoryJet planning number, not a measured result. We set it well below the 8.4% retail conversion gain Deloitte reported for a 0.1 second speed-up, because one study across many brands cannot predict what one store will see. If you have your own before-and-after or A/B test data, use that instead.

Take the calculator defaults: 100,000 monthly visitors, a 1.8% conversion rate and a $95 average order value. That is $2,052,000 a year. Cutting LCP from 3.6 to 0.9 seconds is 27 steps of 0.1 seconds, so the lift is 27 × 0.85 = 22.95%. The calculator estimates about $471,000 more a year. That is the model output, not a promise.

You pay for every ad click, even when the shopper leaves before the page loads. A slow page means fewer of those paid visitors ever see a product. Google Ads says landing page experience is one of three parts of Quality Score, and its help page describes it as how relevant and useful the page is. It does not publish a speed penalty.

Google says good Core Web Vitals, along with other page experience signals, line up with what its core ranking systems seek to reward, and it recommends that site owners reach good scores. It does not say speed alone will lift your rankings. Helpful, relevant content still comes first. Fast pages help shoppers who arrive from any source.

It means 2 out of every 100 visits end in an order. With 50,000 visits a month at a 2% rate, you get 1,000 orders. At an $80 average order value, that is $80,000 a month. Small changes matter at scale: moving from 2% to 2.2% on the same traffic adds 100 orders a month.

It depends on what you sell, your prices, where your traffic comes from and whether shoppers are on phones or desktops. A store selling low-cost repeat items will look different from a store selling furniture. The best comparison is your own store over time, split by device and traffic source. We do not quote a benchmark here without a source we can show you.

Start with speed, because every other fix depends on the page loading. Then make product pages clear about price, delivery and returns. Show shipping costs early. Cut checkout steps and offer the payment methods your buyers expect. Test one change at a time so you know which one worked, and compare results by device.

LCP measures how long the largest thing in the first screen takes to show, usually the main product image or hero banner. Google rates LCP as good when it happens within 2.5 seconds of the page starting to load, measured at the 75th percentile of real visits on mobile and desktop.

INP measures how fast the page responds to taps, clicks and key presses during the whole visit, such as adding to cart or opening a filter. First Input Delay only measured the first tap. INP became a stable Core Web Vital in 2024 and replaced FID. Google rates 200 milliseconds or less as good.

CLS measures how much the page jumps around while it loads. Late banners, images with no reserved space and font swaps push content down. If a shopper aims for Add to Cart and the button moves, they tap the wrong thing and may give up. Google rates a CLS of 0.1 or less as good.

Each popup, review widget and tracking tag usually loads its own JavaScript. That code competes for the same main thread the browser needs to draw the page and respond to taps. Apps that were removed often leave code behind in the theme. Checking what each app loads, and on which pages, is one of the quickest wins.

Phones have slower processors than laptops. Large scripts take longer to download, parse and run, and while they run the page cannot respond. Shoppers feel this as taps that do nothing or menus that open late, which shows up as a poor INP score. Sending less JavaScript, and running it later, helps most on mid-range phones.

Chrome’s Lighthouse documentation says it warns when the page body has more than about 800 nodes and flags an error above about 1,400. Big DOMs make layout and style work slower, which hurts scrolling and tap response. Long product grids, mega menus and repeated hidden markup are the usual causes on store pages.

Run your key pages through Google PageSpeed Insights. When your site has enough traffic it shows field data from real Chrome users, plus a lab test from Lighthouse. Use the field data for decisions, because it reflects real phones and networks. Test your home page, a collection page, a product page and the cart separately.

The causes are the same on both: theme JavaScript, app scripts, large images and fonts. BigCommerce Stencil themes and Shopify Liquid themes both respond to the same fixes, such as trimming scripts, sizing images and reserving space for content. Measure your own pages with PageSpeed Insights rather than trusting a platform-wide claim.

Resource hints tell the browser to start connecting to important outside servers, such as a payment provider or image CDN, before the page asks for files from them. The DNS lookup and secure connection are then ready when needed. Use them only for a few origins that matter on first load, since each one costs some work.

Critical CSS means putting only the styles needed for the first screen straight into the HTML head. The browser can draw that screen without waiting for a full stylesheet to download. The rest of the CSS loads after, so it no longer blocks the first paint.

Serve AVIF or WebP versions in several sizes using picture and srcset, so each phone downloads only the size it needs. Give the main hero or product image a high fetch priority and do not lazy load it. Lazy load the images further down the page, and always set width and height so the layout does not jump.

A headless store can pre-build pages as HTML and serve them from a CDN close to the shopper, and React Server Components send less JavaScript to the phone. That can make pages faster, but it is not automatic. A headless store with heavy scripts can still be slow, and it costs more to build and run than a theme.

Often, yes. Most slow Liquid stores are held back by app scripts, oversized images, unused theme code and late-loading fonts, and all of those can be fixed inside the theme. We check field data first. If the theme still cannot reach good Core Web Vitals after those fixes, that is when a rebuild is worth pricing.

The page layout and product content can be cached at the edge and served fast to everyone. Things that change per shopper or per minute, such as stock counts, prices for logged-in buyers and the cart, load separately in small requests after the page shows. That keeps the first screen fast without showing stale data.

FactoryJet was founded in 2014 and has served 500+ businesses, with 97% on-time delivery. We are a registered Shopify Partner. We fix the code that slows a store, instead of adding another speed app on top. Every phase has a fixed price quoted in writing after scoping, and we measure field data before and after.

A typical project covers an audit of every app and tracking script, image and font fixes, critical CSS, layout shift fixes, caching setup and a before-and-after report using real-user data. The exact list depends on what the audit finds, and it is written into the quote before work starts. Defect cover is included for a stated period.

A speed fix on an existing store is scoped after the audit, and the timeline is written into the quote. If the audit shows a rebuild is the better route, our build timelines are 3 to 5 weeks for a custom-theme store, 5 to 8 weeks for stores with subscriptions, B2B or a migration, and 8 to 14 weeks for headless or custom builds.

Book a 30-minute call with founder Bhavesh Barot using the button on this page. Send your store address first if you can. We look at your real-user Chrome data, point out what slows the page down, and follow up with a fixed price per phase in writing. There is no monthly minimum.