Core Web Vitals: How Google measures performance

10 min read

The site loads fast on your machine. The Lighthouse score looks fine locally. You deploy. Weeks pass. Traffic is flat. Rankings do not move. Nothing in the logs explains it. The site works. Google has a different opinion.

Core Web Vitals is how Google measures that opinion. Not whether your site exists, not whether the content is good. Whether it actually feels fast to a real user on a real device on a real network. Google uses these measurements as a direct ranking signal. A site that loads slowly, shifts its layout around, or takes too long to respond ranks lower. Not as a penalty. As a consequence.

Open PageSpeed Insights, drop your URL in, and run the report. Switch the tab to Mobile before you read anything. Desktop scores are almost always better and almost always misleading. Most of your users are on a phone on a 4G connection. That is what Google measures. That is what needs fixing.

Largest Contentful Paint

LCP measures how long the main content takes to appear. Not the spinner. Not the skeleton. Not the navigation bar. The actual thing the user came to see. A heading, a hero image, a block of body text. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Most sites sit quietly in between and wonder why they are not ranking.

Where to look in PageSpeed. Scroll to Diagnostics and find "Largest Contentful Paint element." It tells you exactly which element Google is timing. Once you know the element, the cause becomes obvious.

Causes

  • Unoptimized images. The LCP element is almost always an image. Images that are not compressed, not sized correctly, or served in an outdated format like JPEG instead of WebP take longer to download. A 2MB hero image on a mobile connection can push LCP past 5 seconds on its own.
  • No preloading. The browser discovers the LCP image late, after it has already parsed the HTML and CSS. By the time it starts downloading the image, time has already been lost.
  • Render-blocking resources. Scripts and stylesheets loaded in the wrong order block the browser from rendering anything until they finish. The page sits blank while JavaScript that could have waited is being downloaded and executed.
  • Slow server response. Everything is delayed if the server takes too long to respond in the first place. The report calls this Time to First Byte. If that number is high, LCP will be high regardless of what else you fix.
  • Missing caching. Static assets fetched on every request. Dynamic responses regenerated without an HTTP cache layer. Both add latency that compounds across the page.

Fixes

  • Compress and resize images. Serve them in modern formats like WebP or AVIF. Match the image dimensions to how large it actually appears on screen.
  • Preload the LCP image. Add a <link rel="preload"> tag in the document head so the browser starts downloading it as early as possible.
  • Defer scripts that do not need to run immediately. Use defer or async on script tags. Load third-party scripts after the page content is visible.
  • Cache responses that do not change on every request. Use a CDN to serve assets from a location closer to the user.

What not to do

  • Do not lazy-load the LCP image. The browser will defer loading the very element that defines LCP.
  • Do not measure LCP only on your local dev server. Local fonts, scripts, and database calls all behave differently in production.
  • Do not optimize images that are not the LCP element. PageSpeed identifies the one that matters. Start there.
  • Do not assume the LCP element stays the same across pages. The product page may load a hero image. The article page may load a headline. Test each template.

Cumulative Layout Shift

CLS measures visual stability. How much the page moves while it loads. An image that pushes the paragraph below it down when it finally renders. A font swap that reflows an entire heading. A banner that slides the content sideways as it appears. Each of these is a shift. CLS adds them all up into a single score. Under 0.1 is good. Above 0.25 is poor.

Where to look in PageSpeed. Find "Avoid large layout shifts" in the Diagnostics section. It lists every element that caused a shift with its individual contribution to the total score. Start with the highest contributor.

Causes

  • Images without declared dimensions. When an image has no width or height set, the browser collapses its container to zero while the image loads. When the image arrives, the browser has to calculate the space it needs and push everything below it down. That push is a shift.
  • Font swaps. The browser renders text using a fallback font while the custom font loads. When the custom font arrives, different character widths cause the text to reflow. Everything below the reflowed text moves down.
  • Dynamically injected content. Ads, banners, cookie notices, and any other content inserted into the page after it loads can push existing content out of place.
  • Embeds without reserved space. Iframes, video players, and social embeds that have no declared size collapse to zero and expand when they load, causing the same shift as images without dimensions.

Fixes

  • Always set explicit width and height on images. The browser uses these to reserve space before the image loads, so nothing shifts when it arrives.
  • Use font-display: optional in your font CSS. The browser uses the fallback font when the custom font is not cached, skipping the swap entirely. Alternatively, preload fonts so they are available before first paint.
  • Reserve space for ads and dynamic content with a container that has a minimum height. Even an empty placeholder holds the layout in place.
  • Give iframes and video embeds a fixed aspect ratio wrapper so the browser knows how much space to allocate before the content loads.

What not to do

  • Do not animate top, left, width, or height. These properties trigger layout. Use transform and opacity instead. They move and fade without shifting surrounding content.
  • Do not test CLS only on a fast network. Slow networks reveal shifts that fast networks hide by loading everything before first paint.
  • Do not treat the cookie banner as harmless. Banners that appear after first paint and push the page down are some of the worst CLS offenders.
  • Do not use placeholder content that occupies different space than the real content. The shift happens the moment real content replaces it.

Interaction to Next Paint

INP replaced First Input Delay in 2024 and measures something more complete. Not just the first click, but every interaction. Clicks, taps, keypresses. How long the page takes to visually respond to each one. Under 200 milliseconds is good. Above 500 milliseconds is poor. This is the metric most sites struggle with silently. The page loaded quickly. But it feels sluggish. Users cannot place why. INP is why.

Where to look in PageSpeed. Find "Reduce JavaScript execution time" and "Minimize main-thread work" in the Diagnostics section. These break down how long the browser spent executing scripts and which ones took the longest.

Causes

  • Long tasks blocking the main thread. JavaScript runs on a single thread. When a long task is running, the browser cannot respond to user input at the same time. The user clicks something. Nothing happens for half a second. Then it responds. That gap is INP.
  • Too much JavaScript running at once. Large bundles that all execute immediately on page load leave the browser busy for several seconds after the page appears. Interactions during this window feel unresponsive.
  • Heavy synchronous work in event handlers. A click handler that does too much before returning control to the browser delays the visual response. The user does not see feedback until the handler finishes.
  • Third-party scripts on the main thread. Analytics, chat widgets, ad scripts, and tracking pixels often run expensive code on the main thread without the developer choosing when or how.

Fixes

  • Break up long tasks into smaller chunks. Use setTimeout with zero delay to yield back to the browser between pieces of work, giving it a chance to respond to input in between.
  • Reduce how much JavaScript runs on page load. Split your bundle and load only what is needed for the current page. Defer everything else until after the page is interactive.
  • Move expensive work off the main thread using Web Workers. Anything that does not need to touch the DOM, like data processing, parsing, or calculations, can run in a worker without blocking interaction.
  • Load third-party scripts with the async attribute or defer them until after the page is interactive. Audit every third-party script on your page and remove any that cannot justify their cost.
  • Keep event handlers lean. Return visual feedback immediately, then do the heavy work after.

What not to do

  • Do not measure INP in the Lighthouse lab tab. INP is calculated from real user interactions over time. Lab tools cannot replicate it.
  • Do not assume React, Vue, or Svelte are inherently fast. Component renders, state updates, and effects all block the main thread.
  • Do not run synchronous analytics or tracking calls inside click handlers. The first thing the user does is the worst time to ship a beacon.
  • Do not treat INP as something to fix later. By the time field data shows it, users have already left.

Related metrics in PageSpeed

PageSpeed shows other measurements alongside the Core Web Vitals. These are not direct ranking signals, but they help diagnose why a Core Web Vital is failing.

  • First Contentful Paint (FCP). When the first pixel of any content appears on screen. A precursor to LCP. If FCP is high, LCP will be high too. Improving FCP usually improves LCP as a side effect.
  • Time to First Byte (TTFB). How long the server takes to respond to the request. The starting point of every other metric. A slow TTFB makes every downstream fix less effective.
  • Total Blocking Time (TBT). A lab measurement of how long the main thread was blocked during page load. The closest lab equivalent to INP. Use it to reproduce INP issues in a controlled environment.
  • Speed Index. How quickly visual content appears during page load. Useful for catching pages that pass LCP but still feel slow because everything after the largest element loads in late.

Fix the Core Web Vital first. The supporting metrics usually improve as a side effect of the same fix.

PageSpeed scores

PageSpeed shows separate scores at the top of every report. Each is its own audit with its own concerns. Only one of them affects search ranking directly.

  • Performance. Contains the Core Web Vitals. This is what affects search ranking and what this article focuses on. A poor Performance score on mobile is the most common reason a site that feels fine to its developer ranks badly.
  • Accessibility. A WCAG-based audit covering color contrast, ARIA usage, alt text, keyboard navigation, and semantic HTML. Important for real users on assistive technology. Not a direct ranking signal, but semantic structure helps crawlers understand the page.
  • Best Practices. A catch-all for security headers, JavaScript console errors, deprecated APIs, and modern browser features. Not a ranking signal. Most failures here are real bugs worth fixing regardless.
  • SEO. Basic on-page checks like meta tags, canonical URLs, viewport configuration, and crawlability. A starting point, not a full SEO audit. A perfect score here does not mean the site is well-optimized for search.

Performance is the score that affects ranking. The others matter for users, code quality, and discoverability, but they sit outside the ranking signal Google uses.

Field data versus lab data

The report has two sections at the top. Field data comes from real visitors, collected through the Chrome User Experience Report over the past 28 days. Lab data comes from a controlled test run in a simulated environment. Google uses field data for ranking. You use lab data to debug.

These two numbers are often far apart. Lab data runs on a standardized connection in a clean environment. Field data reflects real users on real devices across real network conditions. If your field data is poor but your lab data looks fine, the gap is real-world conditions the lab cannot simulate. A user on a low-end Android device on a congested network will see a very different page than your MacBook on a fiber connection.

Always read field data first to understand what is actually happening. Use lab data to reproduce and fix what you found.

What the build process will not tell you

No test fails because LCP is 3.8 seconds. No warning appears because a font swap is causing layout shift. No error is thrown because a third-party script is blocking every interaction. The site deploys, it runs, and the gap between how it feels on your machine and how it feels to someone on a mid-range phone stays invisible until you go looking for it.

PageSpeed Insights is where it stops being invisible. Run it on mobile. Read the field data. Work through the Diagnostics. The problems are listed. The causes are documented. The fixes are specific. Nothing here requires a rewrite. It requires attention to a layer that most builds never check.