Core Web Vitals Explained - LCP, INP and CLS

Core Web Vitals are Google's attempt to put numbers on something users feel instinctively: whether a page is fast, responsive and stable. They are a set of three metrics that form part of Google's page experience signals, and they are measured against real visitors, not just lab tests.

The three current metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. One important update to know: in March 2024, Interaction to Next Paint (INP) officially replaced First Input Delay (FID) as the responsiveness metric. If you are reading older advice that mentions FID, it is out of date.

Why Core Web Vitals matter

Core Web Vitals are a ranking signal, though a modest one. Content relevance and quality still dominate. Where these metrics earn their keep is the user experience itself: a page that loads quickly, responds promptly and does not jump around keeps people engaged, while a slow or unstable one drives them away regardless of how good the content is.

Treat them as a quality baseline rather than a magic ranking lever. Hitting the thresholds will not catapult a weak page to the top, but failing them can quietly cost you engagement and conversions.

Largest Contentful Paint (LCP) - loading

LCP measures how long it takes for the largest visible element in the viewport to render. That is usually a hero image, a large block of text, or a video poster. In practical terms, it is when the page looks loaded to the visitor.

Thresholds:

• Good: 2.5 seconds or less
• Needs improvement: up to 4 seconds
• Poor: over 4 seconds

How to improve LCP

• Optimise and properly size images, and serve modern formats such as WebP or AVIF.
• Use a content delivery network so assets load from a server near the user.
• Improve server response time and enable caching.
• Preload the LCP image or critical resources so the browser fetches them early.
• Remove or defer render-blocking CSS and JavaScript that delays the main content.
• Avoid lazy-loading the LCP element itself, which is a common accidental cause of slow LCP.

Interaction to Next Paint (INP) - responsiveness

INP measures how quickly the page responds to user interactions across the whole visit - clicks, taps and key presses. Rather than timing a single interaction, it assesses the latency of interactions throughout the session and reports a representative value. A low INP means the page feels snappy when people interact with it.

Thresholds:

• Good: 200 milliseconds or less
• Needs improvement: up to 500 milliseconds
• Poor: over 500 milliseconds

How to improve INP

• Reduce and break up long JavaScript tasks that block the main thread, so the browser can respond to input quickly.
• Defer non-essential scripts and load third-party code carefully, since analytics, chat widgets and ad scripts are frequent culprits.
• Minimise the work done in event handlers, and yield back to the main thread for heavy operations.
• Avoid large, complex DOM structures that make rendering and updates expensive.
• Audit third-party scripts ruthlessly. Each one you add can degrade responsiveness.

INP tends to be the hardest of the three to fix because it usually comes down to how much JavaScript runs and when. There is rarely a single switch; it is incremental work.

Cumulative Layout Shift (CLS) - visual stability

CLS measures how much the page layout shifts unexpectedly while it loads. You have experienced poor CLS if you have gone to tap a button and an ad loaded in, pushing it down so you tapped the wrong thing. CLS is a score rather than a time measurement.

Thresholds:

• Good: 0.1 or less
• Needs improvement: up to 0.25
• Poor: over 0.25

How to improve CLS

• Always set explicit width and height attributes (or CSS aspect-ratio) on images and video so the browser reserves space before they load.
• Reserve space for ads, embeds and iframes rather than letting them push content around when they arrive.
• Avoid inserting content above existing content unless it is in response to a user action.
• Use the font-display strategy carefully and preload key web fonts to reduce layout shifts caused by font swapping.
• Apply transformations with CSS transforms rather than properties that trigger layout changes.

How to diagnose your Core Web Vitals

There are two kinds of data, and the difference matters.

Field data comes from real users via the Chrome User Experience Report. This is what Google actually uses to assess your pages, so it is the version that counts.

Lab data comes from a controlled test in a simulated environment. It is useful for debugging because it is repeatable, but it will not always match what real visitors experience.

Tools to use:

• PageSpeed Insights - shows both field data (if enough real-user data exists for the page or origin) and lab data, along with specific diagnostics and opportunities. The best starting point for a single URL.
• Search Console Core Web Vitals report - groups your URLs by status (good, needs improvement, poor) across the whole site using field data. The best way to see scale and track progress.
• Chrome DevTools and Lighthouse - run lab tests locally while you develop and debug fixes.
• The Web Vitals JavaScript library - lets you measure these metrics on your own site for your own analytics.

A sensible order of work

Start with field data in Search Console to find which page templates are failing and on which metric. Group your fixes by template rather than individual pages, since a homepage fix often resolves the issue across thousands of similar pages.

Tackle LCP and CLS first, as they tend to have clearer, more mechanical fixes - image sizing, reserved space, preloading. Then work on INP, which usually means a longer effort to reduce and tame JavaScript.

After making changes, remember that field data updates on a rolling window of around 28 days, so the report will take a few weeks to reflect your improvements. Use lab tools to confirm a fix works immediately, then watch field data catch up.

The bottom line

Core Web Vitals reward sites that respect the visitor's time and attention. LCP is about loading quickly, INP about responding promptly, and CLS about not moving things around unexpectedly. Aim for 2.5 seconds, 200 milliseconds and 0.1 respectively, measured on real users, and you will have a site that feels good to use and meets Google's bar.

If your Core Web Vitals are stuck in the orange or red and you are not sure where to start, Control Tower can diagnose the underlying causes and put a practical plan together to fix them.