Teams spend hours chasing a higher Lighthouse score without understanding what they're actually measuring. A score can change by 8 points between runs without a single line of code changing. Two pages can have the same score and feel completely different to users. The score is a tool — and like any tool, it's only useful if you understand what it measures and what it ignores.
Key Takeaways
- Lighthouse (PageSpeed Insights) scores weight 5 metrics: FCP, LCP, TBT, CLS, and Speed Index — LCP and TBT together account for 55% of the score
- A score of 90+ is achievable without perfect metrics — the scoring curve rewards improvement more at the bottom than the top
- Field data (CrUX, real users) and lab data (Lighthouse, controlled tests) often differ by 15–30 points
- TTFB is not a Lighthouse metric, but it is the root cause behind many LCP failures — fix server response before anything else
- Score changes of ±5 points on the same page without code changes are normal — Lighthouse has inherent variance from CPU throttling and network simulation
Which Score Are You Looking At?
There are multiple "page speed scores" and they are not the same thing:
Lighthouse Performance Score (0–100) — the most common. Runs in Chrome DevTools, PageSpeed Insights, or CI pipelines. Uses a synthetic throttled network (4G simulation) and CPU slowdown (4×). Aggregates 5 metrics into a weighted composite. This is a lab test — controlled, reproducible, but not real-user data.
PageSpeed Insights Field Score — PSI pulls Chrome User Experience Report (CrUX) data, which is real user measurements from Chrome browsers for pages with sufficient traffic. Shown as "Fast", "Moderate", or "Slow" at the 75th percentile. Often significantly worse than the lab score because real users are on real networks with real browser state — extensions, cached resources, older devices.
Core Web Vitals (CWV) — Google's search ranking signal. Three metrics: LCP, INP, and CLS. Rated "Good", "Needs Improvement", or "Poor" at the P75 of field data. A passing CWV rating does not require a perfect Lighthouse score — they measure overlapping but different things.
Server-side timing scores (like the ByteWaveNetwork Page Speed Inspector) — measure network-layer metrics: DNS, TCP, TLS, TTFB, download time. No browser rendering involved. Shows what happens before the browser even starts parsing the page. Scores reflect server and network performance, not rendering performance.
The 5 Lighthouse Metrics and Their Weights
| Metric | Weight | What it measures |
|---|---|---|
| First Contentful Paint (FCP) | 10% | Time until first text or image appears |
| Largest Contentful Paint (LCP) | 25% | Time until the main content element is rendered |
| Total Blocking Time (TBT) | 30% | Main thread blocked time — lab proxy for INP |
| Cumulative Layout Shift (CLS) | 15% | Visual stability — unexpected layout shifts |
| Speed Index | 10% | How quickly content visually populates above the fold |
LCP + TBT = 55% of the score. Fix these two first. The remaining 45% is split across three metrics that are often easier to address once the heavyweight two are handled.
Note: Lighthouse deprecated FID (First Input Delay) in favour of INP (Interaction to Next Paint) in 2024. TBT remains as the lab proxy for INP because INP requires real user interaction to measure — it cannot be captured in a synthetic test.
What Each Metric Actually Means
LCP (Largest Contentful Paint) — the render time of the largest visible element in the viewport, usually the hero image or the main heading. Google's thresholds: ≤2.5s = Good, 2.5–4s = Needs Improvement, >4s = Poor.
Most common causes of slow LCP:
- Hero image not preloaded — add
<link rel="preload" as="image">for the LCP candidate - Hero image missing
fetchpriority="high"— browser deprioritises the image without this hint - Slow TTFB — a server that takes 800ms to respond pushes LCP out even if rendering is fast
- Render-blocking scripts delaying HTML parse before the image can be discovered
TBT (Total Blocking Time) — the sum of time the main thread was blocked for more than 50ms between FCP and Time to Interactive. This is the metric most correlated with how "janky" a page feels during load. Heavy JavaScript — large bundles, synchronous execution — drives high TBT.
Good threshold: <200ms. Above 600ms is poor. Third-party scripts — chat widgets, A/B testing tools, tag managers — are frequent culprits because they execute synchronously and cannot be deferred without breaking their functionality.
CLS (Cumulative Layout Shift) — measures visual instability: elements jumping as the page loads. Common causes: images without explicit width/height attributes, late-loading ads that push content down, web fonts causing text reflow (FOUT). Good threshold: <0.1.
FCP (First Contentful Paint) — time to first rendered text or image. Heavily influenced by TTFB and render-blocking resources. Fixing FCP often means fixing TTFB first, then removing render-blocking CSS and scripts.
Speed Index — how quickly the page visually fills in above the fold. Correlates with FCP and LCP but focuses on the progression of visual rendering rather than any single element's load time.
Why Your Score Varies
Lighthouse scores on the same page without code changes can vary by ±5–10 points between runs. This is expected, not a bug:
- CPU throttling variance — Lighthouse applies a 4× CPU slowdown, but the actual CPU load on the test machine at the moment of the run affects results
- Network simulation variance — the simulated 4G connection is not perfectly reproducible
- JavaScript execution timing — especially for hydration-heavy React/Next.js apps, minor timing differences in when scripts execute compound into score differences
Practical implication: don't optimise for single-point improvements. Work on issues that move scores by 10+ points. Run Lighthouse 3 times and take the median before concluding anything about a change's impact.
Field Data vs Lab Data
If your PSI field data is significantly worse than your lab score, the likely causes are:
- Real users have browser extensions, service workers, and warm caches that affect timing differently from a clean lab environment
- Your traffic skews mobile — Lighthouse's mobile simulation uses a mid-tier device benchmark; many real users have lower-end hardware
- CDN edge caches aren't warm for less-visited pages — first-visit latency is higher than lab tests account for
- Geographic distribution — users far from your origin server experience higher latency than a lab test run near your CDN
Core Web Vitals are based on field data (CrUX), not lab data. A passing CWV rating requires real users at P75 to be in the "Good" range. A 95 Lighthouse score in lab with poor field data will not improve CWV rankings.
TTFB — The Root Cause Lighthouse Doesn't Score
Time to First Byte is not one of the five Lighthouse metrics and does not directly contribute to the score. But it underlies many LCP failures. A server that takes 800ms to respond will push LCP out by at least 800ms regardless of how optimised the rendering pipeline is.
TTFB thresholds: <200ms = Good, 200–600ms = Acceptable, 600ms–1s = Investigate, >1s = Problem.
High TTFB causes: no server-side caching (every request hits the database), slow database queries, server located far from users without a CDN, PHP/Node process overloaded under concurrent load.
The Page Speed Inspector measures TTFB as a separate metric alongside DNS, TCP, and TLS breakdown — useful for isolating whether slowness is network-side (long DNS or TCP handshake) or server-side (fast connect, slow response).
What to Fix First
Priority order for the biggest score improvements per unit of effort:
- TTFB >600ms — fix server response before anything else; slow TTFB cascades into every rendering metric
- Render-blocking resources — scripts and stylesheets that delay HTML parse; add
deferorasyncto non-critical scripts; load non-critical CSS asynchronously - LCP image not preloaded — add
<link rel="preload" as="image">andfetchpriority="high"on the hero image - Images missing width/height — the primary cause of CLS; always add explicit dimensions to
<img>tags - Third-party scripts — audit and remove unused chat widgets, A/B testing tools, and social embeds; each adds TBT
- Large JS bundles — code split, lazy load below-fold routes, remove unused dependencies
Start with the Page Speed Inspector — it measures TTFB, compression, cache policy, and 12+ HTML checks (render-blocking resources, images missing dimensions, lazy loading). This gives you the server-side and HTML-layer picture before you open Lighthouse and get into rendering-layer analysis.
Check Your Page's Speed Metrics
Free, no signup. The Page Speed Inspector measures TTFB, DNS, TCP, TLS, compression, and cache headers — showing exactly where time is lost before the browser starts rendering.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.