Core Web Vitals: The Complete Guide to LCP, CLS, and INP

Tired of chasing arbitrary performance scores? This is the no-fluff core web vitals guide for technical SEOs. We dissect LCP, CLS, and INP with actionable advice.

What Are Core Web Vitals and Why Should You Pretend to Care?

Let’s get this out of the way: Core Web Vitals (CWV) are a set of specific metrics Google uses to measure a page’s overall user experience. This core web vitals guide is your map through the jargon, focusing on what actually moves the needle, not just what makes a report look green.

Google folded these metrics into its ‘Page Experience’ ranking signals. While not the silver bullet some claim, ignoring them is a bad look, especially when your competitors are paying attention. A poor user experience is a poor user experience, regardless of what Google’s bots think.

The trio of metrics consists of Largest Contentful Paint (LCP) for loading performance, Cumulative Layout Shift (CLS) for visual stability, and the newest member, Interaction to Next Paint (INP), for interactivity. INP officially replaced First Input Delay (FID) in March 2024, so if your old reports still mention FID, it’s time to update your bookmarks and your brain.

Largest Contentful Paint (LCP): Your Page’s Grand Entrance

Largest Contentful Paint measures how long it takes for the largest image or text block to become visible within the viewport. In layman’s terms, it’s the ‘wow, this page is actually loading’ moment for a user. Google says you should aim for an LCP of 2.5 seconds or less.

The ‘largest’ element is often a hero image, a video poster, or the main H1 heading. Poor LCP is a direct result of something blocking or slowing down this critical resource. The usual suspects are slow server response times (TTFB), render-blocking CSS and JavaScript, and unoptimized, chunky media files.

Fixing LCP is about clearing the runway for your most important content. Start by optimizing your server’s Time to First Byte (TTFB). Then, hunt down render-blocking resources and defer anything that isn’t absolutely critical for the initial paint. Finally, for the love of bandwidth, compress your images and use modern formats like WebP or AVIF.

You can give the browser a heads-up to fetch your LCP element sooner using `rel=”preload”`. This is especially useful for a hero image that’s discovered late by the browser (e.g., defined in a CSS background-image property).

<link rel="preload" fetchpriority="high" as="image" href="/path/to/your/hero-image.webp" type="image/webp">

Cumulative Layout Shift (CLS): Stop Moving My Damn Button

Cumulative Layout Shift measures visual stability. It quantifies how much unexpected movement occurs on your page as it loads. We’ve all been there: you go to tap a button, and just as your finger lands, an ad loads above it, shifting the entire layout and causing you to click something else. It’s infuriating, and Google rightly penalizes it.

Your target CLS score should be 0.1 or less. Anything higher indicates a jumpy, unpredictable experience for users. The most common culprits are predictable and entirely fixable.

Here’s a shortlist of things that will wreck your CLS score:

• Images and videos without dimensions: Always specify `width` and `height` attributes. The browser can then reserve the correct amount of space while the media loads.
• Ads, embeds, and iframes without reserved space: Just like images, these elements need a container with fixed dimensions to prevent them from pushing content around when they render.
• Dynamically injected content: If you’re using JavaScript to insert a banner or a newsletter signup form above existing content, you’re doing it wrong. Reserve the space first.
• Web fonts causing FOIT/FOUT: A Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT) can cause significant layout shifts when the custom font finally loads and reflows the text. Preload your fonts and use the `font-display` CSS property wisely.

Interaction to Next Paint (INP): The New Speed King on the Block

Interaction to Next Paint is the successor to FID. While FID only measured the delay of the *first* interaction, INP looks at the latency of *all* user interactions throughout the page’s lifecycle. It measures the time from when a user clicks, taps, or types until the next visual change (the ‘next paint’) happens on screen.

Essentially, INP answers the question: ‘When I click this thing, does the site feel responsive or sluggish?’ A good INP is under 200 milliseconds. Anything over 500ms is considered poor and creates a frustrating, janky experience.

The primary cause of poor INP is a busy main thread, almost always due to excessive JavaScript. Long-running scripts, complex event handlers, and heavy third-party code can block the main thread, delaying the browser’s ability to respond to user input. Other causes include a large, complex DOM and overly complicated CSS selectors that are expensive to compute.

To improve INP, you must become a JavaScript detective. Use the Performance profiler in Chrome DevTools to find ‘Long Tasks’. Break these tasks into smaller chunks using `setTimeout` or `requestIdleCallback` to yield back to the main thread, allowing it to handle user input.

How to Measure and Audit: Your Core Web Vitals Guide to Tooling

You can’t fix what you can’t measure. CWV data comes in two flavors: Lab Data and Field Data. Lab data is simulated in a controlled environment (like Lighthouse), while Field data (also called Real User Monitoring or RUM) is collected from actual users visiting your site.

You need both. Lab data is great for debugging during development, but Field data tells you what your real users are actually experiencing. Google uses Field data from the Chrome User Experience (CrUX) Report for ranking.

Your primary tools are Google’s PageSpeed Insights, which provides both Lab and Field data, and the Core Web Vitals report in Google Search Console. For a deeper dive, Chrome DevTools’ Lighthouse and Performance panels are indispensable. Check out our deep dive on how to properly use PageSpeed Insights.

Auditing these metrics one URL at a time is a fool’s errand. To do this at scale, you need a crawler. ScreamingCAT can connect to the PageSpeed Insights API, allowing you to pull CWV data for thousands of URLs in a single crawl. This lets you quickly identify problematic templates or site sections, which is a crucial first step in any technical SEO audit.

Beyond the Metrics: A Pragmatic Approach to Optimization

Chasing a perfect score of 100 on PageSpeed Insights can be a waste of time and resources. The goal isn’t to get all green lights; the goal is to provide a fast, stable, and responsive experience for your users. The metrics are a proxy for that experience, not the experience itself.

Prioritize your efforts. Use your scaled crawl data from ScreamingCAT to find the low-hanging fruit. Are all your blog posts suffering from poor LCP because of an unoptimized hero image template? Fix the template. Is your CLS terrible on product pages due to a third-party reviews widget? Find a better widget or reserve space for the current one.

Don’t let performance optimization happen in a vacuum. It should be tied to business goals. A faster, more responsive site often leads to higher conversion rates and lower bounce rates. If you’re working on a platform like WordPress, many of these fixes can be implemented with a combination of smart plugin choices and a good caching strategy. We’ve written a whole guide on how to speed up WordPress.

Ultimately, this core web vitals guide should serve as a framework, not a bible. Use the data, find the problems, fix them systematically, and always, always focus on the actual human on the other side of the screen. A good experience is good SEO.

The goal isn’t to get all green lights; the goal is to provide a fast, stable, and responsive experience for your users. The metrics are a proxy for that experience, not the experience itself.

ScreamingCAT