Understanding Core Web Vitals: What They Are and How to Improve Them

Core Web Vitals are a set of three performance metrics that Google uses to measure how users experience your web pages. They focus on loading speed, interactivity, and visual stability, three dimensions that collectively determine whether a page feels fast, responsive, and polished or sluggish, unresponsive, and jarring.

Since June 2021, Core Web Vitals have been part of Google's ranking signals. Pages that meet the recommended thresholds have a measurable advantage in search results over pages that don't. But beyond SEO, these metrics capture something more fundamental: whether your visitors have a good experience.

This guide explains each metric in plain language, covers the scoring thresholds, and provides practical steps to improve each one.

Largest Contentful Paint (LCP)

What It Measures

LCP measures how long it takes for the largest visible element in the viewport to fully render. This is typically a hero image, a large text block, or a background video. It represents the moment when the visitor perceives the page as having loaded its main content.

Why It Matters

LCP is the metric that most closely corresponds to the user's perception of load speed. A page might start rendering quickly with a blank header and navigation, but if the hero image takes four seconds to appear, the visitor's experience feels slow. LCP captures that reality. To understand why even small speed gains matter, see why page speed matters more than you think.

The Thresholds

• Good: 2.5 seconds or less
• Needs Improvement: Between 2.5 and 4.0 seconds
• Poor: More than 4.0 seconds

Google evaluates LCP at the 75th percentile of page loads. This means 75 percent of your visitors need to experience an LCP of 2.5 seconds or less for your page to score "Good."

How to Improve LCP

Optimize the largest element. Identify what your LCP element is (use Chrome DevTools or PageSpeed Insights) and make it load faster. If it's an image, compress it, serve it in WebP or AVIF format, and use responsive sizing. If it's a text block, ensure fonts load quickly.

Eliminate render-blocking resources. CSS and JavaScript that must be downloaded before the browser can paint the page directly delay LCP. Inline critical CSS, defer non-essential JavaScript, and move third-party scripts below the fold.

Use preload for critical assets. If your LCP element is an image, add <link rel="preload" as="image" href="hero.webp"> to your document head so the browser starts fetching it immediately.

Improve server response time. A slow Time to First Byte (TTFB) delays everything that follows. Use a CDN, optimize server-side rendering, and implement caching at the server level.

Avoid lazy loading LCP elements. Lazy loading is great for below-the-fold images, but applying it to your hero image delays LCP. The largest visible element should load eagerly.

Interaction to Next Paint (INP)

What It Measures

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. While FID only measured the delay before the browser began processing the first interaction, INP measures the responsiveness of all interactions throughout the entire page visit and reports the worst one (with some statistical smoothing).

An interaction includes clicks, taps, and keyboard inputs. INP measures the total time from when the user interacts to when the browser renders the visual response.

Why It Matters

FID had a significant blind spot: it only captured the first interaction and only measured input delay, not processing time or rendering time. A page could score well on FID but still feel unresponsive during subsequent interactions. INP addresses this by evaluating the full lifecycle of interactions across the entire visit.

The Thresholds

• Good: 200 milliseconds or less
• Needs Improvement: Between 200 and 500 milliseconds
• Poor: More than 500 milliseconds

How to Improve INP

Reduce JavaScript execution time. Long-running JavaScript tasks block the main thread, preventing the browser from responding to user input. Break large tasks into smaller chunks using requestAnimationFrame, setTimeout, or the scheduler.yield() API.

Minimize main thread work. The browser's main thread handles both JavaScript execution and rendering. Heavy computation, excessive DOM manipulation, and synchronous layout calculations all compete with interaction processing. Use web workers for computationally intensive tasks.

Reduce DOM size. Pages with thousands of DOM nodes require more time to update and render. Keep your DOM lean. A document with fewer than 1,400 nodes is generally considered healthy.

Debounce rapid interactions. Input handlers that fire on every keystroke or scroll event can overwhelm the main thread. Use debouncing or throttling to limit how frequently these handlers execute.

Avoid layout thrashing. Reading a layout property (like offsetHeight) and then immediately writing to the DOM forces the browser to recalculate layout synchronously. Batch your reads and writes to avoid this pattern.

Cumulative Layout Shift (CLS)

What It Measures

CLS quantifies how much the visible content shifts around during the page's lifecycle. If you've ever started reading a paragraph only to have it jump down the page when an image loads above it, or tried to tap a button only to have an ad push it out of the way, you've experienced layout shift.

CLS assigns a score based on the size of the shifted area and the distance it moved. The score accumulates across the session, with Google using a windowing approach that captures the worst burst of shifts.

Why It Matters

Layout shifts are one of the most frustrating user experiences on the web. They cause misclicks, lost reading position, and a general sense that the page is unstable. On mobile devices, where screens are smaller and tap targets are tighter, the impact is amplified. For more on building for small screens, see our mobile-first design guide.

The Thresholds

• Good: 0.1 or less
• Needs Improvement: Between 0.1 and 0.25
• Poor: More than 0.25

How to Improve CLS

Always set dimensions on images and videos. Include width and height attributes on every <img> and <video> element. This allows the browser to reserve the correct space before the asset loads. Modern CSS can handle this with aspect-ratio as well.

Reserve space for ads and embeds. If your page includes ad slots, embedded widgets, or dynamically loaded content, use CSS to define a minimum height for those containers. This prevents the surrounding content from shifting when the embed loads.

Avoid inserting content above existing content. Dynamically injecting a banner, notification, or consent dialog above the main content pushes everything down. If you must add elements, insert them below the current viewport or use an overlay that doesn't displace content.

Use font-display: swap carefully. While font-display: swap improves LCP by showing fallback text immediately, it can cause a layout shift when the custom font loads and text reflows. Minimize this by choosing a fallback font with similar metrics or by using the CSS size-adjust property.

Animate with transforms, not layout properties. If you need to animate the position or size of an element, use CSS transform instead of properties like top, left, width, or height. Transforms don't trigger layout recalculations.

How Core Web Vitals Affect Rankings

Google has confirmed that Core Web Vitals are a ranking signal within its broader page experience system. However, it's important to understand the nuance. Content relevance still matters more than performance. A highly relevant page with mediocre Core Web Vitals will generally outrank an irrelevant page with perfect scores.

Where Core Web Vitals make the biggest difference is in competitive queries where multiple pages offer similar content quality. In those tiebreaker scenarios, the page with better performance metrics has an edge. Think of it as a tiebreaker rather than a primary ranking factor.

That said, the indirect effects of good Core Web Vitals (lower bounce rates, higher engagement, better conversion rates) feed back into signals that do heavily influence rankings. Performance improvements create a virtuous cycle. For practical SEO tactics that complement your Core Web Vitals work, read our guide on how to improve your landing page SEO.

Measuring Your Core Web Vitals

You can measure Core Web Vitals through two types of data:

Lab data is collected in a controlled environment using tools like Lighthouse, Chrome DevTools, or WebPageTest. Lab data is useful for debugging specific issues because it's reproducible and detailed.

Field data is collected from real users visiting your site. The Chrome User Experience Report (CrUX), Google Search Console, and the web-vitals JavaScript library all provide field data. Field data reflects actual user experience across different devices, networks, and conditions.

Both types of data are valuable. Use lab data for diagnosis and field data for understanding real-world impact.

For a comprehensive view that goes beyond raw performance metrics, run your landing page through Grademypage. It evaluates Core Web Vitals alongside SEO, accessibility, and conversion-focused design elements, giving you a holistic score and a prioritized list of improvements.

Take Action

Core Web Vitals distill the complexity of web performance into three metrics that map directly to user experience: LCP for loading, INP for interactivity, and CLS for visual stability. Meeting the recommended thresholds for all three is achievable for most landing pages with focused effort.

Start by measuring where you stand today. Identify which metric is your weakest, and work through the optimization strategies outlined above. The improvements are often cumulative; fixing render-blocking resources, for example, can improve both LCP and INP simultaneously.

Paste your URL into Grademypage and get your score in under a minute. It's free, no account required.