Speed testing tools measure different things. Lighthouse runs a simulated lab test using a throttled connection. Google's CrWUX (Chrome User Experience Report) collects real-world field data from Chrome users. The two often disagree — a site can score 95 on Lighthouse and still have poor field data because real users are on slower devices in more varied conditions. Understanding this distinction prevents you from optimising for the wrong number.
Key Takeaways
- Core Web Vitals (LCP, CLS, INP) are Google's ranking signals — lab score improvements don't move rankings; field data improvements do
- TTFB is the root cause of many downstream metric problems — fix server response time before tackling render-blocking resources
- LCP is the most impactful Core Web Vital to optimise: preload the LCP image, remove lazy loading from the above-fold hero image
- CLS is often caused by images without width/height attributes, font swaps, and dynamically injected banners — these are quick wins
- Lighthouse score is not a ranking signal — it's a diagnostic tool. Field LCP, INP, and CLS in CrUX are what Google measures
The Metrics That Actually Affect Rankings
Google confirmed in 2021 that Core Web Vitals are a ranking signal (Page Experience update). Three metrics constitute Core Web Vitals:
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | How fast the largest visible element renders | ≤ 2.5s | 2.5–4s | > 4s |
| CLS — Cumulative Layout Shift | How much page content shifts unexpectedly | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| INP — Interaction to Next Paint | Responsiveness to user interactions | ≤ 200ms | 200–500ms | > 500ms |
These three are measured using field data (real user sessions) — not lab tests. Lighthouse can approximate them, but only CrUX field data matters for the ranking signal.
The Supporting Metrics (Diagnostic, Not Ranking)
These metrics don't directly affect rankings but diagnose the root causes of poor Core Web Vitals:
| Metric | Good threshold | What it diagnoses |
|---|---|---|
| TTFB — Time to First Byte | ≤ 800ms | Server response time, CDN effectiveness, slow databases |
| FCP — First Contentful Paint | ≤ 1.8s | Render-blocking CSS/JS, slow TTFB, font loading |
| TBT — Total Blocking Time | ≤ 200ms | Long JavaScript tasks blocking the main thread |
| SI — Speed Index | ≤ 3.4s | Visual completeness over time; render-blocking resources |
TTFB: The Root Cause Metric
TTFB is the time from request sent to first byte received from the server. A slow TTFB cascades into slow FCP and slow LCP because rendering can't start until the browser receives HTML. Fix TTFB before attacking render-blocking resources — there's no point optimising resource loading if the HTML itself is slow.
Common TTFB causes and fixes:
- No CDN — origin server is geographically distant from users. Fix: add a CDN (Cloudflare, Fastly, CloudFront). Reduces TTFB by 100–400ms for global audiences.
- Slow database queries — server-side rendering blocks on slow queries. Fix: add query indexes, paginate results, cache expensive lookups.
- No page-level cache — dynamic pages regenerated on every request. Fix: add server-side caching (Redis, Varnish, or full-page cache in your CMS).
- Unoptimised PHP/Python/Node — application-level bottlenecks. Fix: profile the request path; look for N+1 query patterns.
LCP: The Most Impactful Fix
LCP is almost always an image — the hero photo, product image, or above-fold banner. The most common causes of slow LCP:
- LCP image is lazy-loaded —
loading="lazy"on the hero image tells the browser to defer it. Remove this attribute from above-fold images. - No preload hint — browser discovers the LCP image late (after parsing HTML and CSS). Fix:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high"> - Oversized image file — 1.2MB JPEG for an image displayed at 400px wide. Fix: use WebP, correct dimensions, srcset.
- Slow TTFB — image can't start loading until HTML arrives. Fix TTFB first.
CLS: Easy Wins
CLS measures unexpected layout shifts. Most CLS issues are quick fixes:
- Images without width/height attributes — browser doesn't know the dimensions until the image loads, so it can't reserve space. Add explicit
widthandheightto every<img>tag. - Font swap (FOUT) — system font is replaced by the web font, causing text reflow. Fix: add
font-display: optionalorswapwith sufficient fallback metrics. - Ads and banners injected after load — elements that appear above content push everything down. Reserve space for ads and banners with a min-height container.
- Dynamically injected content — cookie banners, chat widgets appearing above the page. Fix: inject below content or reserve space.
Using the Page Speed Inspector
ByteWaveNetwork's Page Speed Inspector measures server-side timing (DNS, TCP, TLS, TTFB, download) and analyses 12+ HTML checks from the same page fetch — including render-blocking resources, images missing dimensions, lazy-load candidates, compression, and cache policy. Unlike Lighthouse, it runs from the server and measures what your server actually delivers, not a simulated lab environment.
Test Your Website Speed Free
DNS, TCP, TLS, TTFB, and 12+ HTML checks — measures render-blocking resources, compression, caching, and image optimisation in one server-side test.
Try 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.