A new piece published on Medium caught our attention this week. Brian Keary's analysis, Core Web Vitals for Shopify: Speed vs. SEO Tradeoffs, argues that the supposed tension between optimising for speed and optimising for search rankings is mostly a false dilemma. Fast sites rank better. Fast sites convert better. The two goals pull in the same direction.
That framing is correct. But there's a layer the article touches on that deserves more attention: the actual cost of failing Core Web Vitals, in pounds and dollars, not just PageSpeed scores.
The Gap Between "Mostly Fine" and "Actually Fine"
The article cites a striking platform-level stat: 75.22% of Shopify sites now achieve good Core Web Vitals scores, placing Shopify second among all CMS platforms. On the surface, that sounds like a solved problem.
It isn't. That figure is desktop-weighted. On mobile, where the Web Almanac puts pass rates at just 48% as of 2025, more than half of sites are failing. And mobile is where 60%+ of e-commerce traffic lives. So the real picture is: the majority of Shopify stores are serving a degraded experience to the majority of their visitors.
That's not an SEO problem. That's a revenue problem.
What the Numbers Actually Mean for a Shopify Store
Let's put some concrete figures on it.
Google's own case study on Rakuten 24 found that achieving a good LCP score correlated with a 61.13% increase in conversion rate, a 26.09% lift in revenue per visitor, and an 11.26% increase in average order value. These weren't projections from a lab test. They came from real user monitoring and controlled A/B testing on live traffic.
Keary's analysis points to a similar finding: each one-second improvement in LCP drives 2-4% higher conversions. For a store doing £500K a year, that's £10,000-£20,000 per second of load time. Not hypothetically. Per second.
Swappie saw 42% higher mobile revenue after a CWV optimisation programme. eBay found that shaving just 100ms off load times produced 0.5% more add-to-cart actions across their catalogue. At eBay's scale that's trivial to calculate. At a mid-size Shopify store, 0.5% more add-to-carts is still real money.
And an Unbounce report cited by Shopify puts the consumer sentiment angle plainly: 70% of shoppers say page speed directly affects their willingness to buy. It's not a background concern. It's front of mind at the moment of purchase.
The Three Metrics That Actually Move Revenue
Core Web Vitals covers five signals, but three of them do the heavy lifting for Shopify stores specifically.
LCP (Largest Contentful Paint)
This measures how quickly the main content of a page loads. On a product detail page, it's almost always the hero image. Shopify stores frequently fail LCP because product images are large, uncompressed, and loaded eagerly. Lazy loading helps, but misconfigured lazy loading on above-the-fold images actively makes LCP worse. The p75 threshold for a "good" score is 2.5 seconds. Many stores are sitting at 4-6 seconds on mobile.
INP (Interaction to Next Paint)
INP replaced FID in 2024 and it's harder to pass. Google's shift to INP tightened performance standards considerably, particularly for storefronts heavy on dynamic content. INP measures responsiveness to user interactions across the entire page session, not just the first one. Every click on a size selector, every quantity update, every variant swap gets measured. Heavy JavaScript, especially from third-party apps, is the primary culprit. The good threshold is under 200ms. Scripts that block the main thread push interaction delays well past 500ms.
CLS (Cumulative Layout Shift)
Layout shift happens when elements move after the page has rendered. On Shopify stores, the usual offenders are late-loading cookie banners, chat widgets that push content down, and promotional banners injected by apps after page load. A CLS score above 0.1 is a failing grade. It's also deeply annoying to users: they go to click a button, the page shifts, and they click something else entirely. Sometimes that something else is the back button.
Why Shopify Stores Specifically Struggle
The Keary piece is right that Shopify has improved its platform-level performance. Hydrogen, Online Store 2.0 themes, and CDN improvements have all helped. But they've also made it easier to install more apps, each of which loads more scripts.
The average Shopify store runs 15 to 25 third-party scripts. Review widgets, upsell popups, loyalty programmes, live chat, retargeting pixels, affiliate trackers. Each one adds blocking time. Each one is a potential source of layout shift. Some of them are themselves broken, throwing JavaScript errors that prevent other scripts from executing, or making failed network requests that hang the page.
The compounding effect is significant. A store might have a well-optimised theme that scores 85 on PageSpeed in isolation. Add the standard app stack and that score drops to 55. The theme developer gets blamed. The app developers don't hear about it. Nobody fixes it.
Monitoring Is Not the Same as Optimising
Here's where a lot of merchants go wrong. They run a Lighthouse audit once, fix the obvious issues, and consider it done. Lighthouse is a synthetic test run against a single URL from a controlled environment. It doesn't reflect what real users on real devices in real network conditions actually experience.
Field data matters more. Google's ranking signals use the Chrome User Experience Report (CrUX), which aggregates real user data at the 75th percentile. A store's p75 LCP is what actually affects rankings. Not the score you got last Tuesday from a fibre connection in a London office.
Real user monitoring shows regressions as they happen. An app update at 11pm ships a new script that blocks the main thread. INP scores spike. Bounce rate climbs overnight. By the time someone notices the following week, a weekend of traffic has already converted at a lower rate.
This is exactly the problem Bloodhound monitors for. It tracks LCP, CLS, INP, FCP, and TTFB in real time against Google's p75 thresholds, and alerts via Slack or Teams the moment scores regress. Paired with its script analytics feature, which ranks every JavaScript file on the storefront by blocking time and transfer size, it's possible to trace a CWV regression directly to the specific script that caused it.
A Practical Checklist for CWV on Shopify
Based on the patterns above, here's where to focus attention:
- Audit hero images on product pages. Use next-gen formats (WebP, AVIF) and set explicit width/height attributes to prevent layout shift.
- Check which scripts have the
asyncordeferattribute. Anything loading synchronously in the<head>that isn't critical to render is blocking LCP. - Reserve space for late-loading elements. Cookie banners and chat widgets should have a fixed height in CSS before they load, not after.
- Audit your app stack. Every installed Shopify app adds at least one script. Remove apps that aren't actively earning their place.
- Check INP on variant selection and cart interactions. These are the highest-frequency interactions on any Shopify store, and they're the ones most likely to be degraded by heavy app scripts.
- Use field data, not just Lighthouse. Check CrUX data in Google Search Console under Core Web Vitals to see real p75 scores for real users.
The Compounding SEO Effect
One thing Keary's analysis makes clear, and it's worth restating: Core Web Vitals are a Google ranking factor. Failing them doesn't just hurt conversions. It reduces the organic traffic that would have converted in the first place.
A store with a poor LCP score is penalised twice. It ranks lower, so fewer people find it. The people who do find it bounce more often because the page loads slowly. Both effects are measurable. Both compound over time as competitors with faster stores accumulate more ranking authority.
Carpe, one of the case studies in the Medium article, achieved a 15% revenue boost from CWV optimisation alone. That wasn't from paid ads or a redesign. It was from fixing performance. The 5% conversion increase and 10% traffic lift came together.
Start With What's Actually Broken
The hardest part of CWV optimisation isn't knowing what to fix. It's knowing what to fix first, and whether the fix actually held.
Scores regress constantly. An app update, a new promotional banner, a larger image uploaded to a collection page, any of these can push a passing score back into failing territory. Without real-time monitoring, that regression is invisible until it shows up in revenue data weeks later.
The Keary article is a useful reminder that this stuff compounds in both directions. Fix it and you get more traffic and better conversions. Leave it broken and you lose both. The data on what good CWV is worth, from Rakuten to Swappie to Carpe, is consistent enough at this point that treating it as optional is a genuine business risk.
Speed isn't a developer checkbox. It's a revenue variable. Treat it like one.
Sources
- web.dev, "A good LCP can lead to an increase of up to 61.13% in conversion rate, 26.09% in revenue per visitor, and 11.26% in average order value."
- shopify.com, "A report by Unbounce found 70% of consumers think a site's page speed impacts their willingness to buy from an online retailer."
- almanac.httparchive.org, "Mobile Core Web Vitals have shown consistent year-over-year improvement, increasing from 36% in 2023 to 44% in 2024, and reaching 48% in 2025."
- shopify.com, "Google's shift in their Core Web Vitals from First Input Delay (FID) to Interaction to Next Paint (INP) in 2024 tightened performance standards, directly impacting media-heavy fashion storefronts."
- rumvision.com, "Swappie: Achieved 42% higher mobile revenue after optimization; eBay: Just 100ms faster load times resulted in 0.5% more 'Add to Cart' actions."