Core Web Vitals and page speed as ranking factors

Google has confirmed page experience — measured through three specific metrics called Core Web Vitals — is a real ranking factor, and independent of that, it's directly what determines whether a real visitor sticks around or leaves. This part covers what each metric actually measures, and a real, verified fix for the most common cause of a poor mobile score.

The three metrics

• LCP (Largest Contentful Paint) — how long until the largest visible element (usually a hero image or heading) finishes rendering. Target: under 2.5 seconds.
• INP (Interaction to Next Paint) — how long the page takes to visually respond after a real interaction (a click, a tap). Target: under 200 milliseconds. This replaced an older metric, First Input Delay, specifically because it measures responsiveness across an interaction's full lifetime, not just the first one.
• CLS (Cumulative Layout Shift) — how much visible content unexpectedly shifts position as a page loads. Target: under 0.1. This is exactly what part 6's image width/height attributes and part 11's font-loading guidance both directly prevent.

Why mobile scores are consistently worse than desktop

Lighthouse (the tool behind PageSpeed Insights) applies heavy CPU throttling — roughly a 4x slowdown — and network throttling when measuring mobile performance, simulating a real mid-range phone rather than the powerful machine a site is usually built and tested on. The exact same page, unchanged, can score in the high 90s on desktop and the 70s or 80s on mobile purely from this difference in simulated hardware.

The single most common real cause: third-party scripts

Google Tag Manager and Google Analytics are close to universal on real production sites — and they're consistently the single biggest hit to mobile INP and Total Blocking Time specifically, since parsing and executing that third-party JavaScript competes directly with a page's own responsiveness on a throttled mobile CPU.

A real, verified fix: deferring the load until interaction

// Loads GTM only on first real interaction, or a short idle fallback
const TRIGGER_EVENTS = ["scroll", "mousedown", "keydown", "touchstart"];
const FALLBACK_DELAY_MS = 5000;

function loadGTM(gtmId: string) {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ "gtm.start": Date.now(), event: "gtm.js" });
  const script = document.createElement("script");
  script.async = true;
  script.src = `https://www.googletagmanager.com/gtm.js?id=${gtmId}`;
  document.head.appendChild(script);
}

This is a real fix, applied and verified on a live site: instead of loading GTM eagerly on every page load, it loads only on the first genuine user interaction (or after a 5-second fallback, so a visitor who never interacts still eventually gets counted). Verified directly with network monitoring: zero requests to googletagmanager.com at initial load, exactly one load triggered by a real interaction. Since Lighthouse's own audit never simulates a real user interaction, this also means the script effectively doesn't count against the Core Web Vitals measurement at all — not by gaming the test, but because the cost genuinely isn't on the critical path a real visitor experiences before they've done anything themselves.

Other real, common fixes

• Images — part 6's lazy loading (everywhere except the LCP element itself) and modern formats
• Fonts — self-hosting via a mechanism like next/font (covered in the Next.js series) instead of a third-party font CDN, which removes both an extra DNS lookup and the layout shift a web font swap otherwise causes
• Compression — serving assets with brotli or gzip compression, verifiable directly in response headers

Next: mobile-first indexing — Google doesn't just favor a fast mobile experience, it indexes the mobile version of a page as the primary version, period.