Shopify Speed Optimization: What to Measure Before and After

Measure the shopping journey, not one score

A homepage score can't describe the experience of choosing a variant or opening a cart. Select representative landing, collection and product pages, plus the cart interaction. Include a complex product template and a common paid-traffic destination. Record the URLs and why each one is included before making changes.

Start with the store's real-user reports where data is available. Record the time window, device split, sample coverage and any template groupings. Shopify's web performance reports give a storefront view. A report with insufficient data is a gap, not a passing result.

Keep field measurements and lab diagnosis separate

Field data captures what real visitors experienced on their own devices and networks. Lab tests use a fixed environment to reproduce technical causes. They answer related questions, and their numbers needn't match.

Use a waterfall or browser trace to find large resources, blocked rendering or long main-thread work. Then change one coherent cause and repeat the same test. A Lighthouse score is a diagnostic summary. It isn't a measurement of sales, and it doesn't replace checking a real interaction.

Record Core Web Vitals with their units

Google's Web Vitals guidance uses Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, measured at the 75th percentile and split by device.

Record the metric and unit, not just a green badge. A page-load trace can help explain LCP, but it doesn't reproduce a shopper's interactions for INP. Check variant selection and cart opening directly.

Make before and after comparable

Use the same URLs, browser and tool versions, viewport, CPU and network settings, test location, login state, consent choice and cache policy. Record theme version, app changes and release dates. Don't compare a preview theme with a live theme without noting the preview overhead.

Run at least five lab repetitions per page and condition. Keep every run, including failures, and report a median with a range. Inspect outliers rather than silently dropping them. Repeated runs reduce noise. They don't create a randomized experiment.

Include functional acceptance criteria

Check navigation, search, product media, variants, price updates, add to cart, cart editing and the path into checkout on mobile and desktop. Confirm consent, analytics and required app behavior still work. Removing a script can improve a lab score while breaking reviews, subscriptions or tracking.

Explain what the comparison can establish

A repeated lab comparison can show a technical change under recorded conditions. A field comparison can show how visitor experience changed across periods, with traffic-mix and sampling limits. Neither alone proves that a revenue change was caused by speed. Promotions, inventory, pricing, traffic sources and seasonality change at the same time.

Where an experiment is feasible, agree the design and main metric before launch. Otherwise, report the comparison as observational and keep the raw counts and dates. Link speed findings to the wider conversion diagnosis, so speed work is chosen for a real shopping problem.