In short
Yes, but modestly. Core Web Vitals are part of how Google assesses page experience, and they act more like a tiebreaker between comparable pages than a force that lifts a weak page above a strong one. Relevance and usefulness decide far more. The stronger argument for speed on an ecommerce site is commercial: slow product and category templates lose add to carts and orders on mobile, and that effect is measurable in your own analytics long before any ranking change would be.
Small for ranking, large for revenue
Google has described page experience signals as a differentiator between pages that are otherwise similarly useful. In practice, a fast page that answers the query poorly does not outrank a slower page that answers it well. Treating speed as a ranking project usually disappoints.
Treating it as a conversion project rarely does. Every extra second before a shopper can see the price, tap a variant or reach the buy button costs orders, and the effect is heaviest on mobile, on slower networks and on first-time visitors who have nothing cached. Those are exactly the visitors paid campaigns are buying.
There is a third effect worth knowing about. Pages that are heavy and slow to respond are also more expensive to crawl, and on a very large catalogue that can reduce how much gets fetched in a given period. This matters at hundreds of thousands of URLs, not at hundreds.
So the honest position is that speed work is worth doing, and worth measuring in add to cart rate and revenue per session rather than in positions. If rankings improve as well, treat it as a bonus rather than the business case.
What Google is actually measuring
Three field metrics make up Core Web Vitals. Largest Contentful Paint measures how long until the main content of the page has rendered, which on a product page is usually the hero image. Interaction to Next Paint measures how quickly the page responds to taps and clicks across the whole visit, and it replaced First Input Delay in 2024. Cumulative Layout Shift measures how much the page moves around while it is loading.
The important detail is that the assessment uses field data from real visitors, collected in the Chrome User Experience Report over a rolling window of recent visits, not the score a lab tool produces on your laptop. A store can pass in the lab and fail in the field, or the reverse.
Google groups URLs by similarity when it reports this, which suits ecommerce well. Product pages are assessed together as a template, so fixing the product template fixes the group rather than one page at a time.
Search Console's Core Web Vitals report is the authoritative view of your own site, split by mobile and desktop. Read that first, then use lab tools to diagnose the specific causes on a representative URL.
Where store templates lose their time
Third-party scripts are the usual answer. Review widgets, chat, analytics, ad pixels, personalisation, popups, currency converters and loyalty tools each add requests and execution, and a theme that has accumulated a dozen of them will struggle on a mid-range phone regardless of how well the theme itself is written. Interaction responsiveness suffers most, because the main thread stays busy.
Images are the second. Product photography that is uploaded at full resolution and resized in the browser wastes bandwidth on every visit. Modern formats, correctly sized variants, lazy loading below the fold and an explicitly prioritised hero image handle most of it, and platform image CDNs do a lot of this automatically if the theme asks for the right sizes.
Fonts are the third, particularly where several weights load before text can render. Layout shift usually comes from images without dimensions, banners injected after load, and cookie or promotion bars that push content down.
The fourth is code left behind. Apps that were uninstalled often leave script tags and snippets in the theme, and those keep loading for every visitor for years. Auditing the theme for orphaned code is frequently the fastest single improvement available.
How to work on it without spending money badly
Start with the field data, not with a score. Open the Core Web Vitals report, find which template group is failing and on which metric, and confirm the pattern on real URLs. A store that is passing on mobile does not need a speed project, whatever a lab tool says.
Then fix at the template level, in the order of impact: remove what is not needed, defer what is not needed immediately, and optimise what remains. Removing an unused app beats optimising it. Deferring a chat widget until after first interaction beats making it smaller.
Set a budget and hold to it. Agree what the product template is allowed to load, and make adding anything new a decision rather than an installation. Most stores get slower gradually because nobody owns that limit.
Measure the outcome in two places. The Search Console report will move as field data accumulates, which takes weeks because the window is rolling. Your analytics will show the conversion effect sooner, and it is the number that justifies the work. Compare add to cart rate and revenue per session on the affected template, mobile only, before and after.
Related questions
Does a store need a perfect performance score?
No. The thresholds that matter are the Core Web Vitals ones measured on real visits, and passing them is the goal rather than maximising a lab score. Chasing the last few points usually costs developer time that would return more if spent on merchandising, content or the checkout.
Does site speed affect how much of a catalogue gets crawled?
It can on very large sites. Google adjusts crawl rate partly on how the server responds, so slow responses and errors reduce what gets fetched in a given period. For a store with a few thousand URLs this is rarely the binding constraint, and indexing problems there usually trace to internal linking or thin pages instead.
Is mobile speed more important than desktop for a store?
Yes, for two reasons. Indexing is based on the mobile version of the page, so that is the version assessed, and mobile is where most retail traffic and the weakest devices are. Always look at the mobile split of the field data first, and test on a mid-range phone rather than a recent flagship.