Page Speed Optimization: Core Web Vitals Made Simple

Page speed is the rare SEO factor users would beg you to fix even if Google didn't exist: every second of load time bleeds conversions, and the ranking system's speed signals merely formalise what visitors already vote with their back buttons. It's also the most over-tooled topic in the field — endless metrics, scores and acronyms obscuring the fact that five fixes produce most of the result on most sites. This guide names the metrics that matter, the five fixes, and the workflow.

The metrics that matter: Core Web Vitals

Google's speed signal is built on three field measurements — real-user data, not lab simulations:

• LCP (Largest Contentful Paint) — when the main content becomes visible. Target: under 2.5s. The "is it loading?" metric, and the one most sites fail.
• INP (Interaction to Next Paint) — how fast the page responds when users click and type. Target: under 200ms. The "is it working?" metric; JavaScript weight is nearly always the culprit.
• CLS (Cumulative Layout Shift) — how much the page jumps around while loading. Target: under 0.1. The "did the button move as I tapped it?" metric; unsized images and injected banners cause it.

Two readings to internalise: field beats lab — PageSpeed Insights' top section (real Chrome-user data, when your traffic qualifies) is what Google uses; the Lighthouse score below it is a diagnostic simulation, useful for finding causes, not a ranking input. Chasing a lab score of 100 is decoration. And speed is a threshold factor, not a ladder — Google distinguishes good from poor experiences; it doesn't award positions per shaved millisecond. Out of the red, into the green, then reinvest effort in content and authority — the factors that actually ladder.

The five fixes that do most of the work

1. Images — the #1 cause of slow LCP everywhere: serve modern formats (WebP/AVIF), size to the actual display dimensions, compress, lazy-load below-the-fold only (lazy-loading the LCP image itself delays it — the classic own goal), and declare width/height so nothing shifts (that's half of CLS fixed too). The full treatment is in the image SEO guide.
2. JavaScript weight — the #1 cause of poor INP: audit third-party scripts (every tag manager tenant, chat widget and tracker bills the main thread), defer what isn't critical, and remove what nobody remembers adding. The cheapest speed win on most sites is deletion.
3. Caching + CDN — cache pages and assets at the server, serve static files from a CDN close to users; on WordPress-class stacks a caching plugin plus a CDN routinely halves load times in an afternoon.
4. Server response (TTFB) — if the HTML itself takes over ~800ms to start arriving, nothing downstream can save you: upgrade hosting, add server-side caching, cut database query weight. Slow servers also depress crawl rate — one fix, two systems.
5. Render-blocking resources — inline the critical CSS, defer the rest, load fonts with font-display: swap, and drop preloads for the LCP image. This is the "first paint" polish after the big four.

The workflow

Measure in PageSpeed Insights (field data first), fix the named LCP element and heaviest scripts it identifies, verify in Search Console's Core Web Vitals report — which tracks real users sitewide and groups problem URLs by template, so one template fix clears hundreds of URLs at once. Recheck quarterly per the audit: speed regresses by accretion — every added widget, tracker and unoptimised hero image is a small withdrawal, and the audit is how you notice before users do.

Frequently asked questions

How much will fixing Core Web Vitals improve my rankings?

Modestly and mostly at margins — speed is a tiebreaker among relevant, authoritative pages, not a substitute for being one. The reliable wins are indirect: lower bounce, higher conversion, faster crawling. Sites expecting a speed fix to leapfrog stronger competitors are budgeting against the wrong factor — the gap is usually authority.

My Lighthouse score is 55 but field data is green. Do I have a problem?

No — field data is the verdict; the lab score is a stress test under simulated slow hardware. Read the lab diagnostics for improvement ideas, but green field metrics mean real users are fine, and so is Google.

What's the fastest single win for a slow site?

Almost always the LCP image: properly sized, compressed, modern-format, not lazy-loaded, ideally preloaded. Second: deleting third-party scripts. Both are afternoon jobs. Speed is plumbing — fix it, verify it, then return to the work that compounds: content worth ranking and links that vouch for it (our department).