Chapter 16 — Key Takeaways
A one-page reference. If you remember nothing else: fix speed for the human on the slow phone; take the ranking nudge as a bonus; never chase the score.
The one idea
Core Web Vitals measures how a page feels to real users — to load, to respond, and to hold still. It is a confirmed but modest ranking factor (a tiebreaker, not a trump card), so you fix it for users and revenue first, and treat the small ranking benefit as a side effect.
The three vitals (memorize this)
| Vital | Expands to | Measures ("the feel") | "Good" threshold | Usual culprit |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | Loading — is the main content there yet? | ≤ 2.5 s | Slow TTFB; heavy / lazy-loaded hero image |
| INP | Interaction to Next Paint | Responsiveness — does it react to a tap? | ≤ 200 ms | JavaScript hogging the main thread |
| CLS | Cumulative Layout Shift | Stability — does it hold still? | ≤ 0.1 | Unsized images; ads/banners with no reserved space |
(INP replaced First Input Delay as a Core Web Vital in March 2024. All three are measured from real users, at the 75th percentile, separately on mobile and desktop.)
Field vs. lab — the distinction that decides everything
| Field data | Lab data | |
|---|---|---|
| Source | Real users (CrUX — Chrome User Experience Report) | One synthetic test (Lighthouse) |
| The number | Pass/Fail assessment at the 75th percentile | The 0-to-100 performance score |
| Job | What Google ranks on; "are real users okay?" | Diagnosis — "what should I change?" |
| Catch | Needs enough traffic ("insufficient data" on low-traffic pages) | Can differ wildly from real users, either way |
PageSpeed Insights shows both — field data at the top (trust this for ranking), Lighthouse lab below (use for the fix list). The Search Console Core Web Vitals report shows field data grouped by page type.
Match the fix to the vital
| Fix | Helps most | Effort |
|---|---|---|
| Optimize images (format, size; don't lazy-load the hero) — see Ch 11 | LCP, CLS | Low–Med |
Explicit width/height (or aspect-ratio) + reserve space for late content |
CLS | Low |
| Page caching + a CDN (cuts TTFB) | LCP | Low–Med |
| Eliminate render-blocking (defer/async JS, inline critical CSS, minify) | LCP | Med |
| Reduce & defer JavaScript; drop unused plugins/third-party scripts | INP | Med–High |
A caching plugin or CDN helps LCP — but does nothing for CLS and little for INP. Diagnose the failing vital first, then reach for the matching fix. A fix aimed at the wrong metric is wasted effort.
Rules of thumb
- Users first, rankings second. A slow page loses customers now; that loss usually dwarfs any ranking effect. Fixing it is worth it even if rankings never move.
- Believe the field data for ranking; use the lab score only to find fixes.
- Aim for the threshold, not the maximum. Poor → good matters; good → perfect buys ~nothing for ranking.
- Never trade content, function, or E-E-A-T for speed. A faster but less useful page can rank worse.
- "Insufficient field data" is not a pass — it often means the page has too few visitors to even measure (a visibility problem, not a speed one).
The mental reframe
- Confirmed ≠ dominant. Core Web Vitals is a ranking factor (Page Experience update) and a modest tiebreaker — both true, both from Google. Read the whole sentence.
- A perfect score does not rank you #1. The "100" is a lab number Google doesn't rank on; ranking is a relative contest decided mostly by relevance, quality, and authority.
- Speed is a foundation you clear, not a mountain you summit.
What you can do today
Run your slowest important page through pagespeed.web.dev on the Mobile tab. Read the field data first: did Core Web Vitals pass or fail, and which vital is red? That is your problem. Then use the Lighthouse "Opportunities" for the specific fixes. One measured page is the start of your Strategy-File speed punch list.
Where this goes next
→ Chapter 17 takes on the rest of the phone-shaped reality: mobile-first indexing, content parity, tap targets, intrusive interstitials, and click-to-call — because your slow visitor is, above all, a mobile visitor, and Google indexes the phone version of your site.