A slow first load costs conversions before a visitor has even decided to trust the site, and it's measured in milliseconds most teams don't notice while building on a fast office connection with a warm cache. Testing performance properly means testing conditions closer to how real visitors will actually experience the site.
Google also uses Core Web Vitals as part of ranking, which means a launch-week performance gap isn't just a conversion problem — it's a visibility problem that compounds the longer it goes unfixed. The tricky part is that lab tools give a score immediately, before a single real visitor has loaded the page, while the field data that actually influences rankings only accumulates once real traffic exists. Both are worth checking, at different stages: lab data before launch to catch obvious problems, field data in the weeks after to confirm real-world performance matches the lab estimate.
Testing checklist
- PageSpeed Insights and Lighthouse are both run — Lighthouse for a detailed lab-based audit with specific fix recommendations, PageSpeed Insights for the same lab data plus real-world field data once enough traffic exists.
- Tests are run on mobile and desktop separately — scores and bottlenecks often differ significantly between the two.
- At least one test is run under throttled network conditions (simulating a mid-range 4G connection), not just on a fast office wifi connection, since that's closer to real mobile visitor conditions.
- Once live, Chrome UX Report (CrUX) field data is checked after enough real traffic accumulates, since lab scores and real-world field scores can diverge.
Fix-readiness checklist
- Images are compressed and served in modern formats (WebP or AVIF) with appropriate sizing for the display context, rather than full-resolution originals scaled down by CSS.
- Caching headers are set so returning visitors and repeat page views don't re-download unchanged assets.
- A CDN is enabled so assets are served from a location physically closer to the visitor, rather than a single origin server regardless of where the visitor is.
- Render-blocking scripts are deferred or loaded asynchronously so they don't delay the page's first paint.
- Web fonts are loaded with a strategy that avoids invisible text or a layout shift when the font finishes loading.
Mobile checklist
- The site is tested on at least one real mid-range mobile device, not only a desktop browser's device-emulation mode, which doesn't reflect real processing power constraints.
- Tap targets (buttons, links) are large enough and spaced enough to avoid mis-taps on a real touchscreen.
- Animation-heavy sections are checked specifically on mobile, since animations that run smoothly on a desktop GPU can visibly stutter or drop frames on mobile hardware.
| Metric | Good Threshold | Common Fix |
|---|---|---|
| Largest Contentful Paint (LCP) | Under 2.5 seconds | Compress/resize the largest above-the-fold image, preload it, remove render-blocking resources |
| Interaction to Next Paint (INP) | Under 200 milliseconds | Break up long JavaScript tasks, defer non-critical scripts |
| Cumulative Layout Shift (CLS) | Under 0.1 | Set explicit width/height on images and embeds, avoid inserting content above existing content |
Testing tells you where the problems are; fixing specific Core Web Vitals failures once you've identified them is a deeper, metric-by-metric process covered in the full Core Web Vitals fix guide. Run the tests before launch so any fixes happen before the first real visitor, not after rankings and conversion data already reflect a slow first impression.
FAQ
What Core Web Vitals scores are considered good before launch?
Google's published thresholds are: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1 — all measured at the 75th percentile of real visits once traffic exists, though lab tools like Lighthouse give a useful pre-launch estimate before real user data is available.
- Lab data (Lighthouse) and field data (CrUX, real visits) can diverge — both are useful, but field data is the one that actually affects rankings.
- The 75th percentile threshold means occasional slow loads are tolerated; consistent slowness across most visits is what triggers a "poor" rating.
Should I test performance on mobile or desktop before launch?
Test both, but weight mobile more heavily — Google's indexing and ranking are mobile-first, and mobile devices on real-world network conditions (not office wifi) are where performance problems are most visible and most damaging to conversions.
- Desktop scores are often misleadingly good since desktops typically run on faster, more stable connections.
- A real mid-range mobile device on throttled network conditions is the closest pre-launch proxy for how most visitors will actually experience the site.