PageSpeed Performance: How to Audit and Improve a Website
PageSpeed Insights combines performance information from real users when available with Lighthouse lab analysis. The most useful way to read a report is not to chase the headline number, but to understand the metrics and audits underneath it. Performance work should connect a measured problem to a technical cause and then verify the result after the fix.
What the Lighthouse performance score means
Lighthouse produces a performance category score from a set of measured audits. The score is useful as a high-level signal, but it is not the same thing as a real-user experience measurement. Two runs can differ because of network conditions, CPU simulation, page state, third-party activity and other variables.
Core lab metrics to understand
- FCP: when the first content is rendered.
- LCP: when the largest relevant content element is rendered.
- TBT: how much main-thread blocking occurs during the lab window.
- CLS: visual layout instability.
- Speed Index: how quickly visible content is populated during loading.
1. Reduce server and document latency
The browser cannot render useful content before it receives the document and discovers the resources it needs. Review backend processing, redirects, connection setup, caching and the path between the user and server. A fast frontend cannot completely compensate for a slow initial response.
2. Optimize images intelligently
Images are frequent contributors to page weight. Serve appropriately sized responsive images, use efficient formats, compress without unacceptable quality loss, and avoid loading below-the-fold media before it is needed. The LCP image deserves special attention because delaying it can directly affect the loading experience.
3. Control JavaScript
JavaScript can delay rendering and block the main thread. Remove unused dependencies, split large bundles, defer non-critical code and audit third-party scripts. If an interaction is slow, use a performance trace to find long tasks rather than simply reducing the number of script tags.
4. Reduce render-blocking work
Critical CSS should be delivered efficiently, while non-critical resources can be deferred or loaded later. Review fonts, stylesheets and scripts that prevent the browser from reaching meaningful content quickly.
5. Use caching and modern delivery
Effective browser and CDN caching can reduce repeated downloads. Compression, HTTP/2 or HTTP/3 where supported, connection reuse and edge delivery can also improve delivery efficiency. Configuration should be tested rather than assumed to be beneficial for every resource.
| Problem | Where to investigate | Possible direction |
|---|---|---|
| Slow LCP | Network, server, LCP element | Faster response, earlier discovery, optimized LCP asset |
| High TBT | Main-thread trace | Reduce JS, split tasks, remove third-party work |
| High CLS | Layout shift records | Reserve dimensions and stabilize dynamic content |
| Large page weight | Network panel | Compress, resize, remove unnecessary assets |
A practical PageSpeed workflow
- Run the URL more than once when investigating a variable problem.
- Compare mobile and desktop results separately.
- Start with user-impact metrics such as Core Web Vitals.
- Open the diagnostic audits behind the score.
- Inspect network requests and the main-thread timeline when necessary.
- Fix the highest-impact bottleneck first.
- Retest in the same general conditions and monitor field data after release.
Why a 100 score is not the goal
A performance score can be useful for regression testing, but real users need a page that is fast, stable, responsive and functional. Removing a useful feature only to gain a few lab points can be a poor engineering trade-off. The objective is a better experience with measurable evidence.