How to Test and Improve Your Website Speed
Page speed affects everything — bounce rate, conversions, and Google rankings via Core Web Vitals. The good news: measuring it is free, and the biggest fixes are straightforward.
What to measure
Google's Core Web Vitals are the key metrics: LCP (how fast the main content loads), CLS (visual stability), and INP (responsiveness). A test tool reports these plus an overall score and specific recommendations.
The highest-impact fixes
- Optimise images — usually the biggest win (see our image guide).
- Minify CSS/JS and enable compression (how to minify).
- Cache static assets and use a CDN.
- Reduce third-party scripts.
Test it
Run any URL through our free page speed checker for metrics and fixes, before and after changes.
Bottom line
Measure Core Web Vitals, then attack the biggest culprits first — images, then minification and caching. Speed is a ranking factor and a conversion driver, so these fixes pay off twice. Re-test after each change to confirm the win.
Lab data versus field data
This distinction matters more than any individual metric. Lab data is a simulated load on throttled hardware — Lighthouse runs an emulated mid-range phone on a slow connection. Field data comes from the Chrome UX Report: real visits by real people on real devices.
Google ranks on field data. That is why a site can score 69 in Lighthouse and still pass Core Web Vitals, or score 95 and fail. Lab scores are a diagnostic tool for finding what to fix; field data is the scoreboard.
The gap between them is normal and often large. A lab LCP of 5.3 seconds alongside a field LCP of 2.9 seconds is not a contradiction — it means your real audience has better devices and connections than the deliberately harsh simulation.
The three metrics that count
- LCP — when the largest visible element finishes rendering. Target under 2.5s. Usually a hero image or heading.
- INP — how quickly the page responds to interaction. Target under 200ms. Long JavaScript tasks are the usual cause of failure.
- CLS — how much the layout jumps while loading. Target under 0.1. Nearly always images or ads without reserved space.
All three are measured at the 75th percentile, meaning three quarters of visits must hit the target. Optimising the median while ignoring a slow tail does not pass.
Fix in this order
TTFB first. Every other metric sits behind it — LCP can never beat time to first byte. Under 800ms is the working threshold. Slow TTFB is usually server-side: uncached database work, no page caching, or shared hosting under load.Then the critical path. Render-blocking CSS and fonts delay first paint. Preload fonts used above the fold, inline critical CSS, and defer everything not needed for the initial view. A three-hop chain of document to stylesheet to font is a common and costly pattern.Then images. Serve at display size, use WebP or AVIF, set width and height to prevent layout shift, and lazy-load everything below the fold — but never the LCP element, where lazy loading actively hurts.Then third parties. Ad and analytics scripts are frequently the largest single cost and the hardest to change. Audit what each one earns you before accepting its weight.Frequently asked questions
Why is my mobile score so much lower than desktop?
Lighthouse deliberately throttles the mobile test to a mid-range phone on a slow connection, while desktop runs unthrottled. A 25-30 point gap is normal for every site and is not evidence of a mobile-specific problem.
What is a good TTFB?
Under 800ms as a working threshold, under 200ms as a good target. It is the foundation for every other metric, so it is the first thing to fix when it is slow.
Do I need a perfect 100 score?
No. The score is a weighted diagnostic, not a ranking factor. Passing Core Web Vitals in field data is what matters, and that is achievable well below 100.
