Shopify Speed Optimization: What to Measure

To judge Shopify speed work, measure the pages customers buy from before and after each change, using real-customer data and repeatable lab tests. This guide covers what to record, how to keep the comparison fair and what the results can and can’t prove.

Measure how customers shop, not one score

A homepage score can’t tell you what it’s like to pick a variant or open the cart. Choose a few key landing, collection and product pages, plus your cart. Include your most complex product page and the page most of your paid traffic lands on. Write down the URLs, and why you picked each one, before you change anything.

Start with real-customer data where you have it. Note the date range, the mobile and desktop split, how much data there is and how pages are grouped. Shopify’s web performance reports give you a view of your whole store. A report that says there isn’t enough data is a gap, not a pass.

Keep real-customer data and lab tests separate

Real-customer data shows what visitors actually experienced on their own devices and connections. Lab tests run in a fixed setup so you can find technical causes. They answer related questions, and their numbers won’t always match.

Use a waterfall chart or browser trace to find large files, blocked loading or long-running scripts. Then fix one cause at a time and repeat the same test. A Lighthouse score is a quick summary. It doesn’t measure sales, and it doesn’t replace actually clicking through your store.

Record Core Web Vitals with their units

Google’s Web Vitals guidance uses three measures. Largest Contentful Paint (LCP) covers loading. Interaction to Next Paint (INP) covers how quickly the page responds. Cumulative Layout Shift (CLS) covers how much the page jumps around. Good scores are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, and at least 75% of visits should meet them. Check mobile and desktop separately.

Write down the number and unit, not just a green badge. A page-load test can help explain LCP, but it doesn’t copy what a customer actually taps, so it can’t measure INP. Test picking a variant and opening the cart yourself.

Make before and after a fair comparison

Use the same URLs, browser, tool versions, screen size, device and network settings, test location, login state, consent choice and cache settings. Note your theme version, app changes and release dates. Don’t compare a preview theme with your live theme without noting that previews load extra code.

Run each lab test at least five times per page and setting. Keep every run, including failures, and report the middle result with the range. Look into unusual results instead of quietly dropping them. Repeating tests cuts down on noise, but it doesn’t turn them into a proper experiment.

Check that everything still works

On mobile and desktop, check navigation, search, product images, variants, price updates, add to cart, cart editing and the path into checkout. Make sure cookie consent, analytics and the apps you need still work. Removing a script can boost a lab score while breaking reviews, subscriptions or tracking.

Be clear about what the results prove

Repeated lab tests can show a technical improvement under the conditions you recorded. Real-customer data can show how the experience changed over time, within the limits of traffic mix and sample size. Neither one alone proves that speed caused a change in sales. Promotions, stock, pricing, traffic sources and seasons all change at the same time.

If you can run a proper experiment, agree how it works and what you’re measuring before launch. If not, call it a before-and-after comparison and keep the raw numbers and dates. Tie speed work to the bigger picture of why customers aren’t buying, so you fix speed where it actually costs you sales.