How to read a website audit
A Site Inspector dossier can look intimidating — four scores, a wall of audits, field data, severity badges. Here is how to read it top to bottom, what "good" looks like for each part, and how to decide what to fix first.
Start with the verdict, not the scores
The banner at the top gives you the count of CRITICAL findings and the overall report severity. The report is graded by its worst section, so a single critical issue makes the whole report critical. That is deliberate: scores can flatter a site that has one genuinely broken signal. Read the verdict first to know whether you are firefighting or fine-tuning.
The four category scores
Performance, SEO, Accessibility and Best Practices are each 0–100. As a rule of thumb: 90+ is green (good), 50–89 needs work, under 50 is failing. Performance is the volatile one — it moves run to run and is the hardest to keep green. The other three are mostly structural: fix them once and they stay fixed.
Field data vs lab data
The CrUX field panel is the most important block on the page and the one people skip. It is what real Chrome users experienced over 28 days — the truth. The audits below it are lab data: one synthetic load, useful for diagnosing why, not for judging how bad. If field data says your LCP is SLOW, that is real; fix it. If there is no field panel, your site just lacks enough traffic for the dataset — lean on the lab results instead.
What "good" looks like in the field
- LCP ≤ 2.5 s (FAST). The main content should paint quickly.
- INP ≤ 200 ms (FAST). Taps and clicks should feel instant.
- CLS ≤ 0.10 (FAST). The layout should not jump as it loads.
- FCP ≤ 1.8 s (FAST). Something should appear fast.
See the dedicated Core Web Vitals guide for the thresholds and how to pass each one.
Reading each dossier section
Performance & Core Web Vitals (lab)
Look at server response time (TTFB) first — if it is slow, everything downstream is slow, and it is usually a hosting problem. Then LCP and Total Blocking Time. High TBT means too much JavaScript on the main thread.
Asset delivery & caching
Render-blocking resources, missing HTTP/2, no text compression and unused JS/CSS are delivery problems. They affect every visitor and are often fixable without touching application code — at the edge or in build config.
SEO
These are mostly binary: a missing <title>, missing meta description, a non-canonical page, or a
blocked crawl. They rarely move the score much individually but they directly affect whether you get indexed. Fix any
that fail — they are cheap.
Accessibility
Low colour contrast and missing image alt text are the usual offenders. These hurt real users first, and
search engines second. Most are one-line fixes in your templates.
Best-practices & security signals
A CRITICAL here usually means a known-vulnerable library or no HTTPS — both are forced-critical for good reason. But: Lighthouse does not check security response headers, so a green score here is not a security pass. It is triage, not a clearance.
What to fix first
- Anything CRITICAL in security (vulnerable libs, no HTTPS) — fastest path to real risk.
- Slow field Core Web Vitals — these are real users, right now.
- Slow TTFB / server response — it gates everything else.
- SEO binaries (title, description, canonical, crawlability) — cheap, high leverage for indexing.
- Everything else, worst-first, using the prioritised remediation list at the bottom of the dossier.
Ready? Run a scan and read your own dossier with this guide open.
Affiliate disclosure: some "FIX THIS" recommendations are affiliate links. If you sign up through one we may earn a commission, at no extra cost to you. Recommendations are triggered by issues detected in your dossier, never by payment. Full details in our affiliate disclosure.