Your store is not slow to you. It is slow to the person about to buy

Your store feels fine on your phone because your browser cached it. How Google measures speed, where a store loses time, and the fix order that works.

By Yannis Spanenburg · 2026-07-01 · 6 min read

Open your own store on your own phone and it feels fine, because your browser has cached the whole thing and you are on good wifi. The experience that gets measured belongs to the customer standing in a doorway on a three year old Android with two bars of signal.

What are Core Web Vitals?

Core Web Vitals are Google's three field metrics for real-world page experience: Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Google measures them from real visits over a rolling 28 days, which a single lab test run on demand cannot reproduce.

Key Takeaways

• Google grades a page at the 75th percentile, so the slowest quarter of a site's real visitors decides whether it passes Core Web Vitals.
• A Lighthouse score in the nineties can still fail in the field, because lab tests do not account for the worse devices and connections real customers use.
• The single most common speed problem in ecommerce is a product photo exported far larger than the size it is displayed at.
• On paid traffic you pay for a slow landing page twice: once for the click, and again when the visitor bounces before the page finishes loading.

What fast enough actually means

Google defines three thresholds. Largest Contentful Paint under 2.5 seconds, so the main content appears quickly. Interaction to Next Paint under 200 milliseconds, so taps respond. Cumulative Layout Shift under 0.1, so nothing jumps while someone is reaching for a button. Clear all three for most visitors and your site is fast enough.

Two details matter more than the numbers themselves. These are measured on real visits rather than on your machine, and you are graded at the 75th percentile. Three quarters of your visitors need a good experience to pass, which means the slowest quarter of your traffic decides your result.

Why your Lighthouse score disagrees with Search Console

Lighthouse runs a simulation on demand. Search Console reports what happened to real people over the previous 28 days. A store can score in the nineties in the lab and still fail in the field, usually because real customers arrive on worse devices and worse connections than any test assumes.

When the two disagree, go with the field data, because that is the measurement Google uses.

Why does mobile page speed decide your score?

Mobile page speed is the number that determines an ecommerce store's Core Web Vitals result, since Google's field data is dominated by phone traffic and graded at the 75th percentile. A store that looks fast on a desktop review can still fail its real score if the mobile experience lags behind.

This is why the fix order in this piece leads with Search Console's mobile tab rather than a desktop Lighthouse run, the same field-data-first discipline our SEO team applies to every technical audit: the mobile number reflects whether real customers, on real phones, stick around long enough to buy.

Proof of Pixel is a marketing and consulting agency for businesses that live on enquiries and orders, building the website, the tracking and the follow-up as one system, with offices in Dubai, New York, London, Antwerp and Kuala Lumpur.

Where the time actually goes in a store

Apps you installed and forgot

Every app that adds a widget adds JavaScript, and most of it loads on every page rather than only the page it serves. A review widget running on checkout, a currency converter running on the blog, an upsell script on a page with nothing to upsell. Uninstalling an app does not reliably remove its code from the theme either.

Images that were never resized

A product photo exported at 3000 pixels wide and displayed at 600 is the most common single problem in ecommerce. Serve modern formats, size images to the space they occupy, and give every one explicit dimensions so the layout stops jumping while they load.

Third-party tags nobody can name

Analytics, pixels, chat widgets, heatmaps and consent scripts all queue up before your customer can do anything. Most stores have accumulated more of these than anyone still remembers approving. Auditing that list is usually faster and cheaper than optimising code you wrote yourself.

Does speed actually change sales?

Yes, speed changes sales, but the famous statistic about it is unreliable. You have seen the line about one second costing a fixed percentage of conversions. It gets quoted constantly, sourced almost never, and it does not transfer cleanly between businesses. Treat any universal number here with suspicion.

The honest mechanism is simpler. Slow pages get abandoned before they finish rendering, so those visits never enter your funnel to be counted. Speed is a real if modest ranking signal, so it compounds with everything else you do. And on paid traffic you pay twice for a slow landing page, once for the click and again for the bounce.

The fix order that works

Measure the field data first, before any lab score. Then remove before you optimise: unused apps, duplicate tags, fonts nobody is using. Then fix images. Then defer whatever is left that does not need to run immediately. Rewriting code comes last, and for most stores it never needs to come at all.

How do you improve site speed without a rebuild?

Improving site speed for a store means measuring real field data first, removing unnecessary code before optimising anything, fixing oversized images, deferring non-critical scripts, and only rewriting custom code as a last resort. Most stores get most of the win from deletion, without a developer rewriting a theme from scratch.

1. Open Search Console's Core Web Vitals report and read the mobile score, since that is the one Google uses.
2. List every app and third-party script currently loading on the homepage and the checkout.
3. Remove or disable anything nobody on the team can explain the purpose of.
4. Re-export product images at the dimensions they display at, in a modern format.
5. Defer or lazy-load anything that does not need to run before the main content appears.
6. Re-measure field data after two to four weeks, since lab scores change instantly but field data needs real traffic to catch up.

Proof of Pixel's position: most slow stores get faster by deleting the apps, tags and scripts they no longer use, before anyone rewrites code.

Your first two moves

Open Search Console, find the Core Web Vitals report, and look at the mobile tab. That is your real score. Then open your theme and count the third-party scripts loading on your homepage. If that number surprises you, you have found your project, and it is a deletion project rather than a development one.