Core Web Vitals: Measure and Improve LCP, INP, CLS (2026)

Core Web Vitals are not just about speed; they’re about user perceived performance, and the most surprising metric is the one that measures interaction, not just loading.

Let’s see what this looks like in practice. Imagine a user clicking a "buy now" button on an e-commerce site.

User Action: Clicks "buy now" button.

System Response (Ideal):

1. Browser receives click event.
2. JavaScript event listener fires immediately.
3. Frontend JS validates form data, perhaps shows a spinner.
4. AJAX request is sent to the backend.
5. Backend processes order, updates database.
6. Backend sends success response.
7. Frontend JS updates UI (e.g., "Order Placed!").

User Experience (Ideal): Instantaneous feedback. The button press feels responsive.

Now, let’s look at how Core Web Vitals measure this.

Largest Contentful Paint (LCP) measures when the largest content element (like a hero image or a large text block) within the viewport becomes visible. It’s about loading.

• What it measures: Time from when the page starts loading to when the largest content element is rendered.
• Why it matters: Users want to see that the page is actually loading something meaningful quickly. A slow LCP means users are staring at a blank or incomplete page.
• How to improve:
  • Optimize server response time: Aim for < 200ms TTFB. Use Cache-Control headers effectively.
  • Reduce render-blocking resources: Defer non-critical CSS and JavaScript. Inline critical CSS.
  • Optimize image and media loading: Use modern image formats (WebP, AVIF), lazy loading for off-screen images, and responsive images (<picture>, srcset).
  • Use a Content Delivery Network (CDN): Serves assets from a location geographically closer to the user.

Interaction to Next Paint (INP), which is replacing First Input Delay (FID), measures the latency of all interactions a user has with a page. It’s about responsiveness.

• What it measures: The time from a user’s interaction (like a click, tap, or key press) to the moment the browser visually updates to respond to that interaction. INP is the longest of these interaction delays throughout the page’s lifecycle.
• Why it matters: A fast-loading page is useless if it doesn’t respond to user input. A slow INP means the page feels sluggish and janky.
• How to improve:
  • Break up long JavaScript tasks: JavaScript tasks that take longer than 50ms can block the main thread, delaying responses. Use setTimeout, requestIdleCallback, or async operations.
  • Optimize third-party scripts: These often run on the main thread and can be a major source of INP issues. Audit and defer or remove non-essential ones.
  • Reduce DOM manipulation: Frequent or complex DOM updates can be costly. Batch updates where possible.
  • Use Web Workers: Offload computationally intensive tasks from the main thread.
  • Efficiently load and process data: For dynamic content, ensure data fetching and rendering are optimized.

Cumulative Layout Shift (CLS) measures unexpected shifts in content during the page’s load. It’s about visual stability.

• What it measures: A score indicating how much "surprise" layout shift occurs on the page. A shift happens when a visible element moves from one rendered frame to another.
• Why it matters: Users hate when content jumps around as they’re trying to read or interact with it, leading to accidental clicks or lost focus.
• How to improve:
  • Specify dimensions for images and video embeds: Always include width and height attributes on your media elements, or use CSS aspect-ratio. This reserves space before the content loads.
  • Avoid inserting content dynamically above existing content: Unless it’s in response to a user interaction.
  • Use CSS transform animations: These are often more performant and less likely to cause layout shifts than animating properties like height or width.
  • Preload key assets: Ensure critical fonts or images load quickly to prevent them from shifting content later.

Here’s a look at a typical configuration for how these might be monitored using a real-world tool, showing example thresholds:

{
  "thresholds": {
    "lcp": {
      "good": 2500,
      "needs_improvement": 4000
    },
    "inp": {
      "good": 100,
      "needs_improvement": 200
    },
    "cls": {
      "good": 0.1,
      "needs_improvement": 0.25
    }
  },
  "metrics": [
    "lcp",
    "inp",
    "cls"
  ]
}

The most impactful way to improve INP often involves understanding the main thread’s workload at the exact moment of user interaction. This isn’t just about how much JavaScript is running, but when it’s running and what it’s doing. A seemingly small piece of code that executes during a critical user interaction, especially if it’s synchronous and blocking, can have a disproportionately large impact on INP.

Once you’ve optimized LCP, INP, and CLS, the next hurdle is often ensuring consistent performance across different network conditions and device capabilities, which leads into understanding the nuances of field data collection and lab testing tools.