If you're staring at a number between 0 and 100 in your Shopify admin and wondering whether it's the thing holding back your Google rankings: it isn't. Google has never seen your Shopify speed score. It's a lab number that Shopify calculates on its own infrastructure for your benefit. What Google uses for ranking is Core Web Vitals measured on real devices belonging to real visitors, collected in the Chrome User Experience Report, reported at the 75th percentile over a rolling 28 days. Those two numbers can move in opposite directions, and often do.
That's the whole answer. The rest of this is why they diverge, how to read the data that actually counts, and which of the two is worth your engineering hours.
What the dashboard score is measuring
Shopify's online store speed score is a Lighthouse performance score, run in a mobile emulation with CPU and network throttling, then weighted across three pages: your home page, your most-trafficked product page and your most-trafficked collection page. It refreshes on a lag of several days, which is why you can ship a real fix on Tuesday and see no movement until the following week.
The composition matters more than most people realise. In current Lighthouse versions, the performance score is a weighted blend: Total Blocking Time at 30%, Largest Contentful Paint at 25%, Cumulative Layout Shift at 25%, First Contentful Paint at 10%, Speed Index at 10%. So nearly a third of your dashboard score is driven by a metric Google does not use as a ranking signal at all, and 20% comes from two metrics Google ignores entirely.
It also runs on one simulated device profile, from one place, with a cold cache, on a page a bot loaded. No logged-in customer, no cookie banner triggered by region, no Razorpay iframe warming up because the visitor got as far as the cart, no third-party review widget deciding to load 40 avatars because that product happens to have 200 reviews.
What Google actually reads
Three field metrics, thresholds unchanged and easy to remember:
- LCP — good at 2.5 seconds or less, poor above 4.0
- INP — good at 200ms or less, poor above 500ms. This replaced FID in March 2024 and it is where most Shopify stores now fail
- CLS — good at 0.1 or less, poor above 0.25
Every one of those is taken from Chrome users who visited your store, on their phone, on their network. Then the 75th percentile is reported, per URL group where there's enough traffic, otherwise rolled up to the whole origin. Safari and Firefox visitors contribute nothing, which for an Indian D2C store means the data is dominated by mid-range Android on 4G, and for a store selling into the UAE or the US it skews differently again.
Notice that INP has no lab equivalent. Lighthouse cannot measure it, because measuring response to interaction requires someone to interact. TBT is the stand-in, and it's a loose one. A theme can post a respectable TBT in the lab and still take 380ms to respond when a customer taps a variant swatch, because the handler that fires on tap is a different code path from the scripts that block the main thread during initial load.
The 75th percentile is the part that breaks people's assumptions
Here is the arithmetic that explains most of the confusion we get asked about.
Say your store recorded 20,000 mobile page views in the last 28 days. LCP distribution comes back like this: 12,000 views under 2.5s, 4,000 between 2.5s and 4.0s, 4,000 above 4.0s. That's 60% good. Your p75 sits inside the 2.5–4.0s bucket, so Search Console marks the group as needing improvement, and your dashboard score might be a perfectly cheerful 72 because the lab run resembles those first 12,000 views.
To pass, you need 75% under 2.5s. You're at 60%. So 15 percentage points of that traffic has to move, which is 3,000 page views. Making your fastest visitors faster contributes nothing. Not one point. The only work that counts is work that lands on the slow tail: the 4G connection in a tier-2 city, the two-year-old Android with 40 Chrome tabs open, the visitor arriving on a Meta ad link with a long UTM string and a cold cache.
This is why "we optimised the images and the score went up 9 points" and "we still fail LCP" are both true at once. We've had stores sitting at 58 in the admin that pass all three vitals, and stores at 80 that fail INP on every product page. The correlation is real but weak enough that you cannot use one as a proxy for the other.
So how much do Core Web Vitals actually move rankings?
Less than the amount of founder anxiety spent on them. Page experience is one signal among a large number, and Google has been consistent that relevance wins. If a competitor's product page answers the query better than yours, a 1.9s LCP will not overtake them.
Where vitals do earn their keep is at the margin: two comparable pages competing for the same commercial keyword, and in crawl efficiency on large catalogues. And more usefully, in money. A slow product page loses sales whether or not Google notices. We'd rather argue the conversion case than the ranking case, because the conversion case is measurable inside 30 days in your own analytics.
The unwelcome version: if you're chasing 90+ in the Shopify dashboard as a project goal, you're optimising a vanity metric. Two brands with identical field performance can be 25 dashboard points apart depending on how their theme handles hero rendering in a throttled lab run. Pick a target in field data and ignore the admin number until the field data is green.
Getting your own field data in about twenty minutes
No tooling budget required.
- Search Console → Core Web Vitals. Mobile report first. It groups similar URLs, so you'll typically see one group for product pages, one for collections, one for the home page. This is your ranking-relevant view.
- PageSpeed Insights, on a specific URL. Ignore the score at the bottom. Read the top panel, the one headed with real-user data. If it says there's insufficient data for the URL, it falls back to origin-level, which for a store with a wide catalogue means your worst templates are hiding inside an average.
- The CrUX dashboard or BigQuery, if you want month-over-month trend by device and country. Worth it when you sell into India and the UAE from the same store, because those two markets will not look alike.
- Your own RUM. The
web-vitalslibrary sends LCP, INP and CLS to GA4 as events. Twenty lines in the theme. Now you can segment by template, by country, by whether the session included a cart interaction. This is the only view that tells you which app is costing you INP on product pages specifically.
For ongoing tracking rather than one-off checks, our own app SwiftStore scans the store, fixes what can safely be automated and keeps a history of the score so you can see whether last month's app installs cost you anything. Use it alongside field data, not instead of it.
What we fix first on a typical Indian D2C store
Roughly in the order we get to them, and roughly in order of how much field movement they buy:
The LCP element itself. Nine times out of ten it's the hero image on the home page and the main product image on PDPs. Correct dimensions, correct format, fetchpriority="high", never lazy-loaded, no carousel wrapper that waits for JavaScript before painting frame one. Most stores lose a full second here.
Third-party scripts, counted honestly. Open the network tab and total the JavaScript that isn't yours. Reviews widget, WhatsApp chat, two pixels, a wheel-of-fortune popup, a size chart app, a COD verification app, an upsell app. Each one was worth installing in isolation. Together they're 600KB of main-thread work and your INP is 420ms. We delete or defer more app scripts than we write code.
Fonts. Two families, four weights, self-hosted, font-display: swap, preloaded for the one that renders above the fold. Cuts both LCP and CLS.
Reserved space. Any element injected by an app after paint needs a container with dimensions. Announcement bars, cookie notices for EU/UK traffic, review stars under the title. That's your CLS, and it's usually a two-hour fix.
Collection pages on big catalogues. Filtering and search that fires a full page reload, or worse, renders 60 products at once with no pagination. Both a speed problem and a merchandising one, and worth treating together rather than separately.
Where a store is on a heavily customised older theme, the honest answer is sometimes that the incremental work costs more than a clean rebuild on a modern Online Store 2.0 theme. We say so. Details of how we scope either path are on our speed optimisation page.
When the dashboard number is still useful
It's a decent smoke alarm. If it drops 12 points in a week, something got installed. It's also the only quick signal you have for a store that's too new to have CrUX data at all, which describes most stores in their first few months. And because Shopify recalculates it for you without any setup, it catches regressions on stores nobody is actively watching.
Just don't report it to your board as a performance KPI, and don't let a developer close a speed ticket on the strength of it. Ask for the p75 numbers before and after, from field data, segmented by template.
Where to start this week
Open Search Console, mobile Core Web Vitals, and write down three numbers: p75 LCP, p75 INP, p75 CLS for your product page group. Then open PageSpeed Insights on your single highest-revenue product URL and check whether the field panel agrees. If the two disagree, your traffic mix is doing something your templates weren't built for, and that's the conversation worth having.
If you'd rather have someone else read it, we do a free store audit that includes field-data vitals by template and a ranked list of what's costing you the most seconds. If you already know what needs doing and just need hands, our developers work on a monthly or project basis.