A Developer’s guide to mastering Core Web Vitals and Conquering INP

For years, “page speed” was the primary focus of web performance. But speed is one-dimensional. A page can load instantly and still feel clunky, unresponsive, and frustrating to use. This is why Google shifted its focus to Core Web Vitals (CWV), a set of metrics designed to measure the true user experience of a webpage.

This guide will go beyond the surface-level scores of 1-100. We will provide a developer-focused framework to diagnose and fix the root causes of poor Core Web Vitals, with a special emphasis on the most challenging and important metric for modern, interactive websites – Interaction to Next Paint (INP).

We will explore the three pillars of user experience as defined by Google:

• LCP (Largest Contentful Paint) – Perceived loading performance.
• INP (Interaction to Next Paint) – Runtime responsiveness and interactivity.
• CLS (Cumulative Layout Shift) – Visual stability.

The Core Web Vitals toolkit for accurate measurement

Before you can fix a problem, you must measure it accurately. Relying on a single tool or one type of data can be misleading.

Lab Data vs. Field Data – This is the most important distinction to understand.

• Lab data – this is data collected in a controlled environment, like running a Lighthouse test in Chrome DevTools. It’s perfect for debugging because it’s consistent and repeatable.
• Field data – this is real-world data collected from actual users who visit your site (also known as Real User Monitoring or RUM). This data, compiled in the Chrome User Experience (CrUX) Report, is what Google actually uses for ranking purposes. Your site’s performance can vary dramatically depending on a user’s device, network, and location.

Your essential tools –

• PageSpeed Insights – the best starting point. It provides both Field Data from the CrUX report (if your site has enough traffic) and a Lab Data test from Lighthouse.
• Google Search Console – the Core Web Vitals report gives you a site-wide overview of which URL groups are “Good,” “Need Improvement,” or “Poor,” based on Field Data.
• Chrome DevTools – the Performance panel is your most powerful tool for deep-dive debugging of Lab Data. It allows you to record a page load and see exactly what is happening on the main thread.
• Web Vitals Extension – a Chrome extension that provides real-time CWV metrics as you browse a site, helping you quickly spot issues.

A deep dive on INP

INP officially replaced First Input Delay (FID) as the core interactivity metric in March 2024. While FID only measured the delay before an interaction started, INP measures the entire duration of an interaction, making it a far more comprehensive gauge of a site’s responsiveness.

What INP really measures – it measures the time from when a user performs an action (like a click, tap, or key press) until the next frame is painted on the screen, showing a visual response. This latency is composed of three parts:

1. Input Delay – the time the browser has to wait before it can even begin processing the event, usually because the main thread is busy with another task.
2. Processing Time – the time it takes to execute the code in your event handlers (e.g., the JavaScript that runs when a button is clicked).
3. Presentation Delay – the time it takes for the browser to render the visual changes to the screen after the code has been executed.

A “good” INP is considered to be 200 milliseconds or less. Anything over 500ms is “poor.”

Common causes of poor INP

Nearly all INP issues stem from one central problem: a busy main thread. The main thread is like a single-lane highway in your browser; it’s where the browser does most of its work, including parsing HTML, executing JavaScript, and handling user interactions. If a long task is blocking that highway, nothing else can get through.

The main culprits –

• Long tasks – any single piece of JavaScript that takes more than 50 milliseconds to run is considered a “long task.” These tasks block the main thread, delaying the browser’s ability to respond to user input.
• Complex and bloated JavaScript – large JavaScript files, especially from frameworks or third-party scripts, can create numerous long tasks during page load and during user interactions.
• Third-party scripts – analytics scripts, ad network tags, and chat widgets are notorious for running heavy JavaScript on the main thread, often outside of your direct control.
• Large DOM size – \when a user interacts with a page, the browser may need to recalculate styles and layouts for many elements. A large and complex DOM (Document Object Model) makes this process much slower.

How to fix poor INP

Fixing INP is all about making your website do less work on the main thread, or breaking that work up into smaller pieces.

Strategy 1. Break up long tasks – The most effective way to improve INP is to ensure no single script monopolizes the main thread.

• How to do it – instead of running one large, monolithic function, refactor your code to yield to the main thread frequently. You can achieve this by calling smaller functions with setTimeout(..., 0). This gives the browser a chance to pause, handle any pending user interactions, and then resume its work. More modern APIs like requestIdleCallback can also help schedule non-essential work.

Strategy 2. Optimize event handlers – The code that runs when a user clicks or taps must be extremely fast.

• How to do it – keep your event listeners lean. If a click needs to trigger a complex operation, do only the absolute minimum work (like showing a spinner) inside the main event handler, and defer the heavy lifting with a setTimeout.

Strategy 3. Audit and defer third-party scripts – You cannot optimize what you don’t measure.

• How to do it – use the Performance panel in Chrome DevTools to identify which scripts are consuming the most main-thread time. Question the value of every third-party script. Load non-essential scripts with the async or defer attributes, and consider lazy-loading heavy components like chat widgets only after the user first interacts with the page.

Strategy 4. Reduce DOM complexity – A simpler page is a faster page.

• How to do it – avoid deeply nested HTML elements. If you have a long, single-page application, use techniques like virtualization or content-visibility to render only what is currently in the user’s viewport.

Optimizing LCP and CLS – The other two pillars

While INP is often the hardest to fix, you cannot ignore the other Core Web Vitals.

Fixing LCP

LCP measures how long it takes for the largest image or text block within the viewport to become visible. A “good” LCP is 2.5 seconds or less.

Common causes – Slow server response times, render-blocking CSS and JavaScript, and slow-loading resources (images, videos, fonts). Key fixes –

• Use a high-quality host and a Content Delivery Network (CDN) to reduce server response time (TTFB).
• Optimize your images by compressing them and serving them in modern formats like WebP or AVIF.
• Preload critical resources like your hero image or primary webfont using <link rel="preload">.
• Avoid loading large CSS or JavaScript files in the <head> of your document that are not needed for rendering the initial viewport.

Fixing CLS (Cumulative Layout Shift)

CLS measures the visual stability of a page. It quantifies how much unexpected layout shifts occur as the page loads. A “good” CLS score is 0.1 or less.

Common causes – Images or ads loading without reserved space, webfonts causing a flash of different-sized text, or content being dynamically injected above existing content. Key fixes –

• Always include width and height attributes on your <img> and <video> tags.
• When loading ads or other embeds, reserve space for them in your layout to prevent them from pushing content down when they load.
• Use font-display: swap in your @font-face rules and preload your key webfonts to minimize shifting during the font loading process.