A store launches on a light, fast theme. A year and a half later its product page loads a reviews widget, a currency converter, two chat bubbles, a discount pop-up, several tracking pixels and a hero image the size of a poster. Nothing is broken. Everything is slow, and nobody decided it should be.
Store speed isn't a theme you chose once. It's the running total of everything added since, and the way back is to measure what each piece costs and remove whatever doesn't pay its way.
What Google measures, and how much it counts
Google's page-experience signals are built on Core Web Vitals, three measurements defined by web.dev. Largest Contentful Paint (LCP) is how long the biggest visible element takes to appear; web.dev's threshold for "good" is 2.5 seconds or less. Interaction to Next Paint (INP) is how long the page takes to respond after a tap or click; web.dev's "good" is 200 milliseconds or less. Cumulative Layout Shift (CLS) is how much the layout jumps around while loading; web.dev's "good" is 0.1 or less. web.dev assesses all three at the 75th percentile of real visits, so a page passes only if most visitors get the good experience. web.dev also records that an older metric, First Input Delay, was retired in favour of INP in 2024, so any tool still reporting FID is out of date.
Google's own page-experience documentation says it still ranks the most relevant content first even when its page experience is weaker. Speed rarely makes a store rank; it removes a reason to lose a close contest, and it decides whether the visitor who arrives stays long enough to buy.
Search Console's Core Web Vitals report is built from real Chrome visitors, which Google documents as the Chrome User Experience Report. A lab test, like the free speed test, is a single load from a single place. Use the lab to find what's slow and the field report to know whether it's hurting you.
Where the seconds go on a store
Three sources cause most of the damage.
Images. On a product or collection page, the LCP element is almost always the main product image or a hero banner. Full-resolution uploads the browser has to shrink, a carousel that loads every slide up front, and images with no width and height set (so text jumps when they arrive, which is CLS) are the usual causes. Both Shopify and WooCommerce can serve resized images when the theme asks for the right size, so the fix is usually in the theme, plus compressing what you upload. Lazy-load images below the fold, but never the main image.
Apps and their scripts. Every app adds JavaScript, and many load it on every page whether that page uses the app or not. Those scripts compete with your own page for the browser's attention, which is what INP measures: a shopper taps "add to cart" while the page is busy starting a chat widget, and the tap waits. On Shopify, an app that edited your theme files can leave its code behind after you uninstall it; apps built as theme app extensions remove cleanly.
The theme itself. Custom web fonts that render text late, sliders and animation libraries, and bloated stylesheets all add up. On WooCommerce the theme runs on your own hosting, so caching and server speed sit underneath everything else; Shopify hosts the page for you, so theme weight and apps are almost the whole story.
Measure, cut, measure again
Removing things blindly is how stores lose the one app that was earning. Follow the sequence:
- Test three pages: the homepage, your best-selling product page and your biggest collection page. Run each test twice and note how long until content appears and until the page settles.
- List every installed app. Next to each, write the page where you can see its output. An app you can't place goes first.
- Uninstall the unused ones. On Shopify, check the theme code afterwards for leftover snippets that reference the app, and remove them.
- For the apps you keep, restrict where they load. Chat, pop-ups and review widgets can wait until the page is interactive.
- Re-test the same three pages, one change at a time, so you know which change paid.
- Watch Search Console's Core Web Vitals report over the following weeks. Google's Chrome User Experience Report documentation describes the field data as a rolling window of the most recent 28 days, so a fix takes about a month to show fully.
When to change the theme, and what comes with you
Switching themes fixes theme weight and nothing else. The apps, their leftover code and the oversized images come along to the new theme. Do the app work first. If the page is still slow with a clean app list and right-sized images, the theme is the remaining cost.
When you do switch, test the theme's demo store with the same speed tool before buying, and after launch re-check the things a theme controls that aren't about speed: canonical tags, product structured data and internal links. The previous lesson covers what to look for, because a new theme is the most common way a store quietly loses its canonicals.
What to take away
- Google measures speed through Core Web Vitals (LCP, INP and CLS, with thresholds set by web.dev) using real visitors, and it still ranks relevance first.
- On a store, images, app scripts and the theme itself are where the time goes.
- Measure the same three pages before and after every change so you keep the apps that earn and drop the ones that don't.
- A new theme doesn't fix app bloat or oversized images, so cull first and switch second.
Next
Speed is about pages you want to keep. Out-of-stock and discontinued products covers the pages you're tempted to remove.