Core Web Vitals: How to Measure and Fix LCP, INP & CLS

Each vital captures one dimension of experience, and each is assessed at the 75th percentile of page loads, meaning at least three-quarters of your real users must have a “good” experience for the page to pass. Averages hide exactly the users you're failing.

The nuances that change how you debug

• LCP tracks one element, usually the hero image or headline. Identify which element it is before optimizing anything; teams routinely speed up resources that aren't the LCP element.
• INP replaced FID in March 2024 and is much harder to pass: FID measured only the first interaction's input delay, while INP measures the full latency of effectively the worst interaction across the entire visit, clicks, taps, and key presses included.
• CLS only counts unexpected shifts. Movement within 500ms of a user interaction is excluded, so a menu expanding on tap is fine; an ad pushing the paragraph you're reading is not.

The single most common CWV confusion: a team celebrates a 98 Lighthouse score while Search Console still reports failing URLs. Both are “right”, they measure different things.

• Field data (real-user monitoring) comes from the Chrome User Experience Report (CrUX): anonymized measurements from actual Chrome users over a trailing 28-day window. This is what the ranking signal uses. You see it in PageSpeed Insights' top panel, Search Console's Core Web Vitals report, and the CrUX API.
• Lab data comes from tools like Lighthouse and WebPageTest running a simulated load on throttled hardware. It's reproducible and rich in diagnostics, but it can't measure INP at all (no real interactions) and its conditions rarely match your real audience's devices and networks.

The workflow that follows: field data decides what's broken; lab data helps you find out why. Start from Search Console's CWV report to identify failing URL groups, confirm in PageSpeed Insights' CrUX panel, then use lab tools and DevTools traces to locate the cause. After deploying a fix, expect up to 28 days for the field window to fully reflect it.

LCP decomposes into four phases, server response (TTFB), resource load delay, resource load time, and render delay. Almost every failing LCP is dominated by one of these, and the fixes map cleanly:

1. Cut TTFB first. If the HTML takes 1.8s to arrive, no front-end trick can hit 2.5s. Cache rendered HTML at a CDN edge, tune slow server work, and eliminate redirect chains. Target TTFB under ~800ms, ideally far less.
2. Make the LCP resource discoverable immediately. The browser should learn about the hero image from the initial HTML, not after CSS or JavaScript executes. Background-image CSS heroes and client-side-rendered heroes are classic late-discovery failures.
3. Prioritize it explicitly. Preload the hero and mark it high priority; never lazy-load the LCP element (lazy-loading above-the-fold images is one of the most common self-inflicted LCP wounds).
4. Shrink it. Serve modern formats (AVIF/WebP) at the actual rendered size via responsive images, from a CDN close to users.
5. Unblock rendering. Inline critical CSS, defer non-critical scripts, and use font-display: swap so text-based LCP elements don't wait on webfonts.

<!-- Discoverable, prioritized, never lazy -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

<img src="/hero.avif" fetchpriority="high" decoding="async"
     width="1200" height="630" alt="Product dashboard">

Platform note: on template-driven platforms the same fixes apply but the levers differ, app scripts and theme bloat dominate on Shopify, plugins and unoptimized media on WordPress. We cover the platform-specific versions in our Shopify SEO guide and WordPress SEO guide.

INP is high when the browser's main thread is too busy to respond to the user. The cause is nearly always JavaScript: long tasks that block input handling, heavy event handlers, and excessive DOM updates after an interaction. The leverage points, in order:

1. Find the slow interactions in the field. Use RUM or the web-vitals library's attribution build to see which elements and scripts are behind your worst interactions, then reproduce them in DevTools' performance panel with CPU throttling on.
2. Break up long tasks. Any task over 50ms blocks interaction. Chunk big loops and defer non-visual work with scheduler.yield() or setTimeout so the browser can paint between chunks.
3. Do less on interaction. In the handler itself, do only what's needed to update the UI; push analytics, logging, and state syncing to after the next paint.
4. Ship less script. Audit third-party tags ruthlessly, tag managers accumulate scripts nobody owns, and code-split so pages load only the JavaScript they use.
5. Tame rendering cost. Huge DOM sizes and layout-triggering reads inside handlers inflate the “next paint” half of INP. Keep DOM under control and batch style reads/writes.

Layout shift has one root cause: content rendering without its space being reserved, then pushing everything else when it arrives. The fix is a discipline, not a trick, every late-arriving element gets its dimensions declared up front:

• Images and video: always set width and height attributes (or CSS aspect-ratio) so the browser reserves the box before the file loads.
• Ads and embeds: wrap them in fixed-size containers sized to the most common creative; an empty reserved slot is infinitely better than a shift.
• Dynamic content: never inject banners, notices, or recommendation units above content the user is already reading, insert below the viewport or in reserved space.
• Webfonts: use font-display: swap with metric-compatible fallback fonts (size-adjust) so the swap doesn't reflow the page.
• Animations: animate with transform, never with top/left/height, which trigger layout for everything nearby.

“Users forgive a page that loads in three seconds. They don't forgive tapping “Cancel” because the button moved under their thumb, and neither does the CLS score.”

Once all three metrics are green, protect them: add performance budgets to CI, re-run the checks whenever templates or tags change, and fold CWV review into your recurring SEO audit process alongside the rest of the technical SEO checklist. Regressions arrive with releases, not with algorithm updates.