How Site Speed Affects Conversion, and the Fixes That Are Worth It

Two different claims hide inside the sentence “site speed affects conversion”. The first is that fast stores convert better than slow ones. The second is that making this store faster will make it convert better. Only one of them is straightforward to demonstrate, and it is not the one a budget has to rest on.

Shopify’s analysis of actively-selling stores reports that conversion tends to be about 3.5% lower for every 100 milliseconds of additional load time, then states the limit of its own finding: the data shows “a clear correlation between performance and conversion, though not direct causation”. The quickest stores in a sample like that also tend to run better hosting, tidier themes, fewer apps and more experienced teams. Taken without the caveat, a number like that funds work that was never going to pay, and that is where most site speed conversion optimization budgets quietly go astray.

Speed work tends to repay the effort when data from real visitors puts the store outside Google’s thresholds on the templates that carry revenue, and when the cause is structural: a slow server response, a main image the browser discovers late, render-blocking scripts, or apps nobody has reviewed in two years. It repays much less when the store already sits inside those thresholds and the work is aimed at a test score. Working out which of the two situations applies takes roughly a day of measurement, and it is the step most often skipped.

What the Evidence Actually Supports, and What It Does Not

The Shopify figures come from a defined method. The company divided actively-selling stores into buckets by their aggregated performance across a 28-day period at the turn of January and February 2026, then compared the median conversion rate of the stores in each bucket. On interactivity the pattern is similar in shape: conversion “tends to drop by about 1.5%” for every 32 milliseconds of additional delay in responding to interactions. That is a large dataset measured consistently, which makes the direction of the relationship hard to dismiss.

What a study of that design cannot tell a single retailer is how much of the gap is caused by speed. Stores are not randomly assigned to be fast. A brand that has invested in infrastructure has usually invested in merchandising, photography and customer service as well, and all of those also move conversion. The honest reading is that the figure sets an expectation for the direction of travel, not a forecast for one store.

The more useful class of evidence is a controlled experiment, where the same store is tested against itself. Vodafone ran one on a landing page and published it: “A 31% improvement in LCP led to 8% more sales, a 15% improvement in their lead to visit rate, and a 11% improvement in their cart to visit rate”. Half the traffic went to the optimised version and half to the baseline, and the write-up is explicit that “there were no functional or visual differences between the two versions”.

That design is what makes the result worth something. Because nothing else changed, the improvement can reasonably be attributed to the loading work rather than to the kind of store Vodafone happens to be. Two cautions still apply before anyone borrows the number. The traffic was enormous, roughly 34,000 visits per day per version, which is well beyond what most stores can run a clean split test on. And the gain came from specific structural changes: moving widget rendering from the client to the server, server-side rendering critical HTML, resizing the hero image and using media queries to avoid loading images that were not yet in the viewport. It did not come from being faster in the abstract.

What Site Speed Conversion Optimization Can and Cannot Fix

Loading and responsiveness problems produce a recognisable kind of loss. Visitors leave before the page has resolved, they tap a filter or a variant selector and nothing appears to happen so they tap again, or a late-loading banner pushes the add-to-cart button under their thumb as they reach for it. Those failures fall disproportionately on mobile sessions, on slower networks and on older devices, which is why a store with a healthy desktop conversion rate can still be losing a large share of its phone traffic. The same asymmetry shows up in the gap between mobile and desktop conversion rates.

Speed has no purchase at all on a different and often larger group of problems. A shopper who cannot find the delivery cost, does not trust the returns policy, cannot tell which of four variants fits, or reaches checkout and finds the only payment method they use is missing, will abandon a page that renders instantly. Performance work removes an obstacle in front of the decision. It does not improve the offer behind it.

There is a search consideration as well, and it is more modest than it is usually presented. Google states that Core Web Vitals “are used by our ranking systems”, while also saying that “there is no single signal” for page experience and that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par”. Google adds that good scores in those reports “doesn’t guarantee that your pages will rank at the top of Google Search results”. Speed work is worth doing on its own commercial merits. A business case that rests mainly on an expected ranking gain is resting on the weaker half of the argument.

The Thresholds That Matter, and Why a Lab Score Is Not One of Them

Google defines three Core Web Vitals and a target for each: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. The part teams forget is how the assessment is made. Performance is evaluated “at the 75th percentile of page loads, segmented across mobile and desktop devices”, so the question is not what the page does on a good connection. It is what it does for the slowest quarter of real sessions, counted separately by device.

This is also where two kinds of data get confused, usually expensively. PageSpeed Insights presents both. Its lab results come from a simulated load on a single device and fixed network conditions, and Google describes them as “useful for debugging issues” while noting they may “not capture real-world bottlenecks”. Its field results come from the Chrome User Experience Report over the previous 28-day collection period, and are “useful for capturing true, real-world user experience”. A store can move the lab number substantially and see nothing change in the field data, because the simulated device was never the constraint.

Field data also runs out, which matters for anyone auditing a specific template. Google states that a page “might not have sufficient data if it has been recently published or has too few samples from real users”, in which case the tool “will fall back to origin-level granularity”. If the origin is also thin, no real-user data is shown at all. Smaller stores and newly launched collection pages frequently sit in that position, which makes lab data their only option and makes careful interpretation of it more important, not less.

A platform dashboard is the third view, bounded differently again. Shopify’s web performance report uses real user metrics and combines the home page, the most visited product page and the most visited collection page from the last 7 days, with scores that “reflect how real customers experience your store”. The same documentation sets the bar as “at least 75% of your page loads need to achieve Good scores across all Core Web Vitals”.

Its boundaries are published too. The data “might be delayed by up to 36 hours”, only the last 90 days are retained, and Shopify warns that “if your site has less traffic, then there might be larger fluctuations displayed”. Three sampled templates is genuinely useful, and it is not the same thing as coverage of the pages a campaign actually lands on.

Before any budget is committed, a short list of questions separates a measurement problem from a performance problem:

• Which templates carry the revenue, and what is their field data by device? A slow blog template is an annoyance. A slow collection template on the pages paid traffic lands on is a commercial problem, and the two often get the same priority because the report averaged them together.
• Is the store outside a threshold, or inside it and merely unimpressive? Moving LCP from 4 seconds to 2.3 seconds changes which side of the line the store sits on. Moving it from 2.1 to 1.8 seconds may be worth doing for other reasons, but it is a smaller commercial event than the effort usually suggests.
• Is mobile the failing segment? Because thresholds are assessed separately by device, a store can pass comfortably on desktop and fail on phones, where most sessions are. An aggregate number hides this.
• Does enough field data exist to judge the result later? If a template has too few samples to report now, it will have too few to confirm an improvement, and the work will be evaluated on a lab score by default.
• What else is competing for the same money? If the checkout is missing a payment method that 15% of the market expects, that is likely to be the better first investment, and it can be found in the same diagnostic pass.

Where the Time Actually Goes on an Ecommerce Page

LCP is not a single event, and treating it as one is why speed projects so often spend their budget in the wrong place. Google breaks it into four parts: Time to First Byte, resource load delay, resource load duration and element render delay. On a well-optimised page the guidance is that roughly 40% of the total sits in TTFB, roughly 40% in loading the resource itself, and under 10% in each of the two delays.

That breakdown turns a vague complaint into a diagnosis. Time to First Byte measures “the time between starting navigating to a page and when the first byte of a response begins to arrive”, and Google suggests most sites aim for 0.8 seconds or less. It is not itself a Core Web Vital, but it precedes every other loading metric, so nothing that happens in the browser can recover a server that answered late. If a collection page returns its first byte after 1.4 seconds, compressing images will not bring LCP inside 2.5 seconds, and a project that starts with the image pipeline will report small gains and a puzzled team.

Key takeaway: measure the parts before choosing the fix. A page with a 1.4 second server response and a page with a 1.4 second hero image can show the same LCP and need entirely different work, different budgets and different people. The diagnosis is cheap. Rebuilding the wrong layer is not.

The Fixes That Usually Repay the Work

Server response time, caching and the paths that cannot be cached

When TTFB dominates, the work sits behind the storefront and the platform decides its shape. On Adobe Commerce the documented recommendations include activating all caches, using Varnish because Adobe “highly recommend[s] using Varnish, as it is an efficient production page cache solution”, and setting indexers to “Update on Schedule” for performance purposes, with the Customer Grid index as the stated exception. On WooCommerce the official guidance is to enable server-side caching through the host or with solutions such as Varnish, NGINX FastCGI Cache or Redis, while ensuring the configuration allows “dynamic content such as cart and checkout pages to remain uncached”.

That last detail carries a consequence worth planning for. Page caching does not apply to the cart, checkout and account pages, so the steps closest to the order remain as fast as the server genuinely is. Stores with a large logged-in or B2B audience see less benefit from page caching than the headline figures suggest, because a higher share of their sessions runs on uncached paths. For those stores the honest options are better hosting, a working object cache and less work per request, which cost more and take longer than installing a plugin.

On Shopify the hosting is not yours to change, so a slow first byte usually points at the theme. Shopify names deeply nested Liquid loops as the most common cause of high TTFB, along with metafield access inside loops and excessive pagination depth. That is a narrower problem than it sounds, and often a cheaper one to fix than a hosting migration.

The largest element above the fold

The element that defines LCP on a product or collection page is usually an image, and the cheapest real gains tend to be here. Shopify’s theme guidance is specific: never lazy-load the LCP image, mark it with fetchpriority="high", avoid hiding it behind animations, do not use a CSS background image for LCP content, and include width and height attributes to prevent layout shift. Each of those is a small change to a template, with no effect on what the page offers the shopper.

The reason this work returns well is that it usually removes a delay rather than shrinking a file. A browser cannot start loading an image it has not discovered, and lazy-loading the hero, or painting it from CSS, guarantees late discovery. That is resource load delay, the subpart Google suggests keeping under 10% of LCP. The limit is equally clear: if the LCP element is a block of text and the server is slow, there is nothing here to win, and a team that has only been given the image checklist will keep polishing a part that was already fine.

Scripts, apps and tags nobody has audited

Third-party code is where performance quietly regresses between projects. Shopify’s recommendations include removing render-blocking apps, auditing and removing unused scripts including tracking pixels and leftover theme code, using defer and async on non-critical scripts, loading JavaScript on user interaction, and removing A/B test anti-flicker snippets when no tests are running. WooCommerce’s documentation points the same way, recommending tools such as Query Monitor to “analyze the performance impact of the plugins you install” and replacing those that hurt the store.

The technical part of this is rarely the hard part. The difficulty is that the tags belong to other people. A pixel that looks dormant may feed a campaign somebody is judged on, and removing it without agreement buys a performance gain and an argument. Scripts also come back: an app is reinstalled for a promotion, a snippet is pasted in for a test that ends, and six months later the store is slow again in the same way. Without a named owner and a recheck in the calendar, this category delivers a one-off gain and then erodes.

Catalogue, search and template work at scale

Large catalogues fail differently. The constraint moves from the weight of one page to the cost of producing it: filters across tens of thousands of products, search queries, deep pagination and templates that loop over more data than the shopper will ever see. WD Market’s Evelatus project is published as a rebuild around a catalogue of “860,000 products”, with “Elasticsearch Integration For High-Performance Search” and real-time ERP synchronisation across that catalogue. No performance figures are published for it, and none should be inferred here. The relevant point is architectural: at that scale, search and data flow are part of the speed question rather than separate from it.

Platform-specific detail matters more than general advice in this category. Our notes on speeding up a slow WooCommerce store and on improving Magento speed go further into the individual changes than is useful to repeat here.

Work That Rarely Justifies Its Cost

A smaller set of activities absorbs site speed conversion optimization budgets without reliably changing what visitors experience. They persist because they are visible, easy to demonstrate and easy to approve.

• Chasing a perfect lab score. Past the point where field data sits inside the thresholds, further lab points tend to measure the simulation more than the shopper. Google’s own framing is that lab data is for debugging. Its usefulness as a target is limited, and it can also be gamed by removing things customers were using.
• Installing an optimisation app to compensate for other apps. Adding another script to defer the existing scripts sometimes helps and sometimes adds a layer that breaks during a theme update. Where the underlying issue is thirty tags nobody owns, this treats the symptom and leaves the cause in place.
• Replatforming mainly for performance. A migration resets the front end, which can produce a genuine improvement, and it also carries risk to URLs, integrations and data that a template fix does not. It rarely makes commercial sense unless the platform is constraining the business in other ways as well.
• Removing features that were earning their place. Reviews, search filters and size guidance all cost milliseconds and all answer questions that otherwise end the session. Stripping them can improve a score and reduce orders, and the score is the metric being watched.
• Micro-optimising fonts and CSS while the server is the constraint. Work of this kind is measurable, enjoyable and easy to report. When roughly 40% of LCP is sitting in TTFB, it is close to irrelevant until the server response is addressed.

Comparing the Realistic Options Before Committing Budget

Most stores are choosing between a handful of options rather than doing everything. The comparison below is written in terms of what each option demands and what it risks, because those are the differences that decide the order of work in a site speed conversion optimization programme.

Note that the bottom row belongs in the comparison on merit. Where a store already sits inside the thresholds on its main templates, the next increment of conversion is more likely to come from the checkout, the product page or the delivery proposition than from another 200 milliseconds. A technical audit that concludes no speed work is warranted has done its job, and an agency that cannot reach that conclusion is not measuring anything.

A Sequence That Keeps Speed Work Honest

The order below exists to prevent the two failures that waste most of this budget: fixing a layer that was not the constraint, and finishing with no way to tell whether anything improved.

1. Establish a field baseline by template and device. Record real-user data for the home page, the main collection templates, the main product templates and the checkout steps, separating mobile from desktop. Note which pages have too little data to report, because those will need a different standard of proof later.
2. Rank templates by revenue, not by how slow they look. The page that carries the most qualified sessions sets the ceiling on what any fix can return. This is also the point to check whether speed is plausibly the main loss on that page at all.
3. Split LCP into its subparts on the priority templates. Establish how much of the time is server response, how much is discovering the resource, how much is loading it and how much is rendering. The answer usually names both the fix and the person who should do it.
4. Fix the dominant subpart first, and only then the next one. Doing the cheap front-end work first is tempting because it is available, but if the server response dominates, the result will be a small gain and a loss of credibility for the whole programme.
5. Ship changes in isolation where the platform allows it. One change at a time makes the effect attributable. Where traffic supports a split test, that is better still, for the reason Vodafone’s published test is more persuasive than any cross-store average.
6. Re-measure after the field window has turned over. A 28-day collection period means a fix shipped today is not fully reflected for weeks, and platform reporting may lag by a further day or more. Judging the work on a lab score the morning after deployment is how real gains get dismissed and imaginary ones get celebrated.
7. Set a performance budget and name an owner. Agree a threshold that new apps, tags and templates must respect, and put a recheck in the calendar. Without this step, site speed conversion optimization becomes a project that is repeated every eighteen months rather than a property of the store.

Internal expert input required: add the performance budget thresholds WD Market applies on client engagements, and the recheck interval used for stores with frequent app changes.

Deciding Whether Speed Is Your Constraint

The correlation between performance and conversion is well established, and it is not the same as a promise that this store will earn more by loading faster. That is why site speed conversion optimization begins with measurement: field data by template and device, then the subparts of LCP, then a fix aimed at whichever part dominates. Stores outside the thresholds on revenue-carrying templates, particularly on mobile, have the clearest case. Stores already inside them are usually looking at a different constraint, and the diagnostic pass that says so has saved the budget rather than wasted it.

Treat the outcome as conditional in both directions. Speed work removes an obstacle in front of the buying decision, and a faster page still cannot answer a question the product page never addressed.

From Speed Diagnosis to Measured Conversion Gains

If the store is failing Core Web Vitals on the templates that carry orders, or if the reporting is contradictory enough that nobody can say whether it is, the useful next step is a measured diagnosis rather than a list of fixes. Request CRO and growth support and you get a field-data baseline by template and device, an LCP subpart breakdown that names whether the constraint is the server, the resource or the render, a prioritised list separating defects from candidates for testing, and a measurement plan that can confirm the result after the field window turns over. Where performance turns out not to be the main loss, the same pass says where the loss actually sits.

To discuss a specific store, contact the WD Market team with the templates and markets that matter most to you. Teams who want the shorter version of analyses like this one can follow WD Market on LinkedIn.

Questions Ecommerce Teams Ask About Speed and Conversion

How much conversion will we gain by making the store faster?

Nobody can responsibly quote a figure for a specific store in advance. Cross-store data shows the direction clearly, and the publisher of the best-known ecommerce dataset describes it as correlation rather than causation. The controlled experiments that do exist, such as Vodafone’s split test on a landing page, produced sales gains in the single digits from a substantial loading improvement. Treat that as an indication of the scale available when a page is genuinely slow, then measure your own result against a field-data baseline.

Is a PageSpeed score above 90 the right target?

It is a useful diagnostic and a poor target. That number comes from a simulated load on one device and fixed network conditions, which Google positions as a debugging aid rather than a measure of real experience. The thresholds that describe shoppers are the field metrics at the 75th percentile of real page loads, counted separately for mobile and desktop. A store can hold a high lab score while a quarter of its phone sessions still fall outside the loading threshold.

What does site speed conversion optimization actually involve?

Four stages, in order. Measuring real-user data for the templates that carry revenue, by device. Breaking the loading metric into its parts so the constraint is identified as server response, resource discovery, resource loading or rendering. Fixing the dominant part, whether that is caching and hosting, a template change, or an audit of apps and tags. Then re-measuring after the reporting window turns over, and setting a budget so new additions do not quietly undo the work.

Our key landing pages have no field data. What should we do?

This is common on newer templates and lower-traffic stores. Reporting tools fall back to origin-level data when a page has too few samples, and show nothing at all if the origin is also thin. In that situation, lab data becomes the working instrument, used carefully: compare like with like, test on a device and connection profile close to your actual audience, and prefer structural fixes whose benefit is explainable rather than changes justified only by a score moving.

Does page speed affect our Google rankings as well as conversion?

It contributes. Google confirms Core Web Vitals are used by its ranking systems, while also stating there is no single page experience signal and that genuinely relevant content can rank even where page experience is weak. Good scores carry no guarantee of position. The practical conclusion is to justify performance work on the experience and revenue case, and treat any search benefit as a secondary reason rather than the basis of the business case.

Should we replatform to fix performance?

Rarely for that reason alone. A rebuild does reset the front end and can deliver a real improvement, but it also puts URLs, integrations, data and trading continuity at risk, which a template fix does not. Replatforming becomes easier to justify when performance is one of several structural constraints, for example when the platform also blocks the checkout, payment or B2B functionality the business needs. If the main symptom is a slow theme or unmanaged apps, that is a cheaper problem.

How long before a speed fix shows up in our reporting?

Longer than most teams expect. Field metrics are reported over a 28-day collection period, so a change shipped today appears gradually as the window moves rather than immediately. Platform dashboards add their own lag, and stores with lower traffic see larger swings between refreshes, which can look like a result in either direction. Agree in advance which date you will judge the work on, and avoid drawing conclusions from the first few days after deployment.