OneWebDesk

Core Web Vitals (LCP, CLS, INP) Improvement Checklist

What LCP, CLS and INP measure, and a practical checklist to improve each score.

Core Web Vitals are the three field metrics Google uses as a ranking signal. They measure how fast the page paints its main content (LCP), how little the layout jumps around (CLS), and how quickly the page responds to clicks and taps (INP). Critically, these are graded from real-visitor Chrome data (CrUX) at the 75th percentile, not from a one-off Lighthouse run. In practice that means even your slower visitors—the worst one in four—need a good experience for you to pass.

This guide walks each metric as definition → threshold → an actionable checklist, ordered so the highest-impact fixes come first even if you barely touch code. To turn your current state into numbers first, start with page weight analysis and response-time measurement.

Thresholds at a glance

Google buckets each metric into Good / Needs Improvement / Poor. You want to land in the “Good” range to get a positive search signal.

MetricMeasuresGoodNeeds workPoor
LCPLoading (largest paint)≤ 2.5s2.5–4.0s> 4.0s
CLSVisual stability (shift)≤ 0.10.1–0.25> 0.25
INPResponsiveness (input lag)≤ 200ms200–500ms> 500ms

Improving LCP — paint the biggest element under 2.5s

LCP (Largest Contentful Paint) marks when the largest element in the viewport—usually a hero image or a big headline—finishes rendering. A slow LCP almost always traces back to one of three culprits: a slow server response (TTFB), a heavy hero image, or render-blocking resources.

  • Cut server TTFB first. If the first byte of HTML is late, everything downstream slips. Add caching, a CDN and static generation, and check where you stand with response-time measurement. Aim for TTFB under 0.8s.
  • Optimize the hero image. If your LCP element is an image, resize it to the displayed dimensions and serve WebP/AVIF. Not sure which format wins? Use the image format recommender.
  • Prioritize and preconnect. Give the LCP image fetchpriority="high"and never put loading="lazy" on it. Open connections early with<link rel="preconnect"> for third-party origins.
  • Remove render-blocking work. Inline or preload critical CSS and fonts and defer large scripts so the first paint path stays light. Track total bytes with page weight analysis.

Worked example: a blog sat at 4.3s LCP (Poor) because its hero JPG weighed 1.8MB. Resizing it to 1200px wide and converting to AVIF dropped it to 210KB; adding fetchpriority="high"pushed LCP down to 2.1s (Good). Swapping a single image moved it up two buckets.

Improving CLS — stop the page from jumping

CLS (Cumulative Layout Shift) accumulates how much elements move unexpectedly while the page loads. It is the metric behind that moment when an ad pops in just as you tap a button and you hit the wrong thing. Think of it as user frustration expressed as a number.

  1. Set dimensions on media. Always give images and videos width/heightattributes or a CSS aspect-ratio so the browser reserves the box up front. This alone often halves a bad CLS.
  2. Reserve space for ads and embeds.Give banner and iframe slots a min-height so content below them doesn't get shoved down when they load.
  3. Tame font swaps. Pair font-display: swap with size-adjustso the fallback font matches metrics and lines don't reflow when the web font arrives. Preload the critical font.
  4. Never inject above existing content.Don't splice notification or cookie bars above the body—overlay them at the top/bottom or reserve their space from the start.

Improving INP — respond to taps instantly

INP (Interaction to Next Paint) replaced FID in 2024. It captures the near-worst response delay across every click, tap and keypress over the page's lifetime. The cause is almost always a long task that monopolizes the main thread: when JavaScript runs for more than 50ms in one block, input is stuck waiting behind it.

  • Break up long tasks. Split heavy functions with setTimeout orscheduler.yield() so the browser can service input between chunks. Keep any single task under 50ms.
  • Ship less JavaScript. Drop unused libraries and code-split so the first view only loads what it needs. Inspect bundle size with page weight analysis.
  • Move heavy work off-thread. Sort, parse and crunch data in a Web Worker so the main thread stays free for input handling.
  • Keep handlers light. In a click handler give instant visual feedback and defer the heavy follow-up to the next frame so the UI updates first.

The three metrics are intertwined: trimming heavy assets improves LCP and INP together, and reserving space stabilizes CLS. A fast starting point is to baseline with page weight and response time, then sort out images with the format recommender.

Frequently asked questions

Are Core Web Vitals a lab score or real-user data?
The values used for ranking come from real-user field data (CrUX), specifically the 75th percentile over a rolling 28 days. Lab tools like Lighthouse are great for debugging, but ranking is judged on what actual visitors experience.
What happened to FID?
First Input Delay was officially replaced by INP in March 2024. INP is stricter and more realistic because it looks at interaction latency across the whole page lifetime, not just the first interaction.
Which metric should I fix first?
LCP is the most commonly failed bucket, so starting with the hero image and server response is usually the most efficient. Then tackle CLS (set dimensions) and INP (split long tasks) for big wins with modest effort.
Can changing only images help?
Yes. Resizing an oversized hero image and converting it to WebP/AVIF frequently moves LCP up a bucket or two. Setting width/height at the same time also improves CLS.
Will passing instantly boost my rankings?
Core Web Vitals are one signal among many and act more like a tiebreaker between comparable pages. Content quality comes first, but good scores reduce bounce and help indirectly too.

Tools to use with this guide