A Lighthouse audit, and how to read one
This website speed test runs a Google PageSpeed Insights audit of a public URL and returns four Lighthouse category scores together with the individual timing metrics behind the performance number.
A single performance score is a poor unit of work. What makes a page slow is specific — an oversized hero image, a render-blocking font, a third-party tag that runs before anything paints — and each of those shows up in a different metric. Reading the metrics is what turns a score into a task list.
This test asks Google’s PageSpeed Insights API to run Lighthouse against your URL, so the numbers are the same ones you would get from Google’s own tool, with the four category scores and the core timing metrics presented together.
What the test measures
- Performance
- A weighted composite of the timing metrics below, scored 0–100. Because it is a weighted average, two pages with the same score can have completely different problems.
- Accessibility
- Automated checks for contrast, labels, alt text and landmark structure. It catches real defects but cannot judge whether a page is usable with a screen reader.
- Best Practices
- Security and correctness checks: HTTPS usage, deprecated APIs, console errors, correct image aspect ratios.
- SEO
- Basic crawlability and markup checks — title, meta description, indexability, link text, viewport. Passing all of it is a floor, not a strategy.
- Mobile and desktop strategies
- The mobile run throttles CPU and network to emulate a mid-range phone on a slow connection. Scores are usually far lower than desktop, and mobile is the one that reflects most of your real traffic.
- Requirement
- The URL must be publicly reachable. Staging behind basic auth, an IP allowlist or a firewall cannot be audited by an external service.
The metrics behind the score, and what fixes each one
Direct answer: ignore the composite score and read these six. Each maps to a different class of fix.
| Metric | What it measures | Usual cause when it is bad |
|---|---|---|
| LCP — Largest Contentful Paint | When the main content element finishes rendering | An unoptimised hero image, a slow server response, or a font that blocks text rendering. Start by compressing the largest image. |
| CLS — Cumulative Layout Shift | How much the layout jumps while loading | Images and ad slots without reserved dimensions, and web fonts swapping in at a different size. |
| TBT — Total Blocking Time | How long the main thread was blocked and unable to respond | Heavy JavaScript, especially third-party tags, analytics and chat widgets loaded early. |
| FCP — First Contentful Paint | When the first pixel of content appears | Render-blocking CSS and JavaScript in the document head. |
| TTFB — Server response time | How long the server took to send the first byte | Slow application code, no caching, or a distant origin with no CDN in front of it. |
| Speed Index | How quickly the visible area fills in | A page that renders in stages rather than in one pass — usually a knock-on effect of the metrics above. |
How to avoid drawing the wrong conclusion
This is lab data, not field data
Lighthouse loads your page once in a simulated environment. Google’s ranking systems use Core Web Vitals from real Chrome users over a 28-day window. A lab score is a diagnostic; the field data is the assessment.
Scores vary run to run
Network conditions, server load, the audit location and A/B tests all move the number. Run three times and compare the median, and never compare a morning run against an evening run as if it were a regression.
A 100 score is rarely the goal
The last 10 points usually cost more than they return. Moving LCP from 4.2s to 2.4s changes user behaviour; moving a score from 92 to 97 typically does not.
Test the pages that matter
Auditing only the homepage is the classic mistake. Product pages, blog posts and landing pages carry different weight and usually have very different problems.
Third-party scripts dominate more often than your code
Tag managers, chat widgets, heat maps and ad scripts commonly account for the majority of blocking time. Audit what is loaded before optimising your own bundle.
A slow page is not always a slow site
If the page is slow only for you, the problem may be DNS or routing rather than the site. Check what the domain actually resolves to with the DNS checker.
A first optimisation pass that usually works
In practice, most sites recover the majority of their available gain from four changes. Do them in this order.
- 1
Fix the largest image
Find the LCP element, resize it to the dimensions it is actually displayed at with the image resizer, then compress it. A 3 MB hero scaled to 1600px wide and re-encoded often drops below 200 KB.
- 2
Serve modern formats
Convert photographic assets to WebP with the image converter. WebP typically lands 25–35% smaller than comparable-quality JPEG.
- 3
Reserve space for anything that loads late
Give images explicit width and height attributes and give embeds and ad slots a fixed container height. This is the cheapest CLS fix there is.
- 4
Defer non-critical JavaScript
Load analytics, chat and marketing tags after interaction or on idle. Audit every third-party script and remove the ones nobody reads reports from.
- 5
Re-test and record the numbers
Keep a note of LCP, CLS and TBT before and after. A score alone will not tell you which change earned the improvement.
How this page is maintained
The category list, the mobile and desktop strategies and the six timing metrics reported by this tool were read from its server implementation, which calls the Google PageSpeed Insights API. The distinction between lab and field data is stated explicitly because conflating the two is the most common misreading of any speed test.
Written and reviewed by the ToolsRacks editorial team. Last reviewed: .