Core Web Vitals for beginners: measure and improve LCP, INP and CLS

Core Web Vitals measure three parts of a website visit: how quickly its largest visible content appears, how promptly it responds to interaction, and whether the layout moves unexpectedly. The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Start by checking real-user results, then use a controlled browser recording to find the element, interaction or layout change behind the problem.

A page can look finished and still respond badly to a tap. It can react immediately while an advertisement pushes the paragraph you are reading down the screen. Those are different problems, and treating them as one generic speed score makes optimization harder than it needs to be.

The useful question is not simply whether your website is fast. It is which part of the visit is failing, for which visitors, and what evidence would show that your change helped.

Read the three metrics before reading the overall score

Google's Core Web Vitals threshold methodology uses separate targets for loading, responsiveness and visual stability. The thresholds below apply to the metric values, not to the colored Lighthouse performance score.

LCP follows the largest eligible image or text content visible in the viewport during loading. That might be a product photograph, an article heading or a prominent block of text. It is not the time when every image on the page has downloaded. A smaller logo appearing quickly does not compensate for the main content arriving late.

INP describes the delay between a qualifying interaction and the next visual update. Clicking, tapping and keyboard interaction count; merely scrolling is not the same kind of measurement. The reported value generally reflects the slowest interaction during the visit, with outlier handling on pages that receive many interactions. It includes waiting for the main thread, running event handlers and preparing the next frame.

CLS is a unitless score. It describes unexpected movement of visible content, accounting for how much of the viewport is affected and how far elements move. The metric uses the largest qualifying burst of shifts rather than adding every movement throughout an indefinitely long visit. Some movement following recent user input is excluded, but that does not make every interaction-triggered layout change harmless.

These distinctions explain why a single intervention rarely solves everything. Compressing a hero image can help loading, but it will not remove expensive JavaScript from a filter button. Reserving space for an embed can stabilize the layout without making the embed's script faster.

Understand what the 75th percentile tells you

Core Web Vitals assessments use the 75th percentile, usually written p75. Sort the recorded values from fastest to slowest: p75 marks the value at or below which roughly three quarters of the measured experiences fall. It is not the average, and it is not a measurement of your own latest visit.

Consider a purely illustrative set of visits where most people see a page quickly but a substantial minority wait much longer. The average can conceal that uneven experience. A percentile gives you a way to ask whether the target holds for a broad share of visitors, while still avoiding a judgment based entirely on a few extreme observations.

Mobile and desktop populations should be evaluated separately. A responsive design can use the same URL on both devices while serving different images, exposing different controls and running on different hardware. A good desktop result does not establish that mobile visitors receive the same experience.

For a complete three-metric assessment, the relevant p75 results must meet all three good thresholds. Missing measurements need separate treatment. In particular, a visit without a qualifying interaction does not generate an INP value. Do not enter zero in a spreadsheet to fill that gap: zero would imply a measured instant response.

Google's reporting tools also have their own data-sufficiency rules. PageSpeed Insights can assess LCP and CLS when sufficient INP data is unavailable. Read the report's actual assessment and its coverage rather than inventing the absent value or assuming that every tool uses identical display rules.

Separate a real-user report from a controlled test

Field data describes recorded visits. Lab data describes a controlled test. Both are useful, but they answer different questions.

The Chrome User Experience Report, or CrUX, aggregates eligible Chrome experiences. Its API presents a rolling 28-day collection period. PageSpeed Insights uses CrUX for its real-user section, while its lab section runs Lighthouse to examine a page under specified conditions. The two sections can legitimately disagree.

A lab run might load the homepage with no consent choice, no account session and no interaction. Your visitors may dismiss a banner, open navigation, filter a product list, scroll to an embedded video and return to a cached page. Those journeys expose work that a loading-only test never exercises.

The reverse can also happen. A constrained lab test can look worse than the experience of much of your audience. That is a reason to investigate the test conditions, not to discard the lab result. It can reveal a genuine bottleneck that becomes important on slower hardware or connections.

CrUX also does not represent every browser or every visitor. Pages need sufficient eligible traffic and must meet inclusion requirements. A missing report is a data-availability issue, not proof that the page is fast or slow. Google does not publish a universal visitor-count threshold that you can use to guarantee inclusion.

Use our field versus lab data guide when reports disagree. Before comparing numbers, write down the URL, device category, collection period and whether the result describes one URL or the entire origin.

Choose the report that matches your question

PageSpeed Insights is a useful starting point for a public URL. First inspect the real-user section, where available. Check whether it describes the requested page or falls back to the origin. An origin combines pages under the same scheme, hostname and port; it is not a diagnosis of every individual template.

Then inspect the lab section. Its diagnostics and insights suggest causes worth examining. They are not a list of independent score deductions, and their estimated savings should not be added together as a promised improvement. Several recommendations may address the same underlying delay.

Search Console helps you find groups of URLs with similar experience problems. A group-level issue is especially useful when a shared template affects many articles or products. Open representative URLs from the group and inspect their common implementation rather than assuming that editing one example resolves the entire group.

Chrome DevTools lets a developer investigate the actual sequence. Record the page load to inspect LCP. Record interactions to inspect responsiveness. Watch layout-shift events while reproducing late content, banners or embeds. Keep the recording conditions attached to your notes so another person can reproduce the finding.

Your own real-user monitoring, often called RUM, adds detail that aggregate reports cannot supply. It can associate a regression with a deployment or template, subject to the coverage and privacy choices in your implementation. Do not assume that your RUM results will exactly match CrUX: populations, browser APIs and measurement details can differ.

Diagnose slow LCP by following the resource

Begin by identifying the LCP element in the recording. Do this at the relevant viewport size. A large image on desktop may become a smaller image or a text block on mobile, so the resource you optimize must actually be the one determining the metric.

For an image-based LCP, inspect four stages: time before the first HTML response byte, delay before the image request starts, time downloading the image, and delay between download completion and rendering. A small file can still appear late if JavaScript inserts its URL only after the application initializes.

The first practical checks are straightforward. Is the image discoverable in the initial HTML? Is it incorrectly marked for lazy loading? Does its responsive configuration select an unnecessarily large file? Does a stylesheet or script prevent the browser from showing it after it arrives?

This illustrative markup gives an important image dimensions and a high fetch priority. The referenced image files must exist in your project.

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

The absence of loading="lazy" is intentional. fetchpriority is a scheduling hint, not a command that overrides every browser decision. Reserve it for genuinely important resources rather than assigning high priority to an entire gallery.

If HTML itself arrives late, image work cannot remove the delay before the browser discovers the page. Investigate server response time and TTFB, particularly redirects, cache misses and application work. If the image arrives promptly but remains invisible, investigate rendering and main-thread work instead.

Diagnose poor INP by reproducing a real interaction

Choose a specific action: opening a navigation drawer, selecting a product variant, submitting a search or expanding a long section. Record it after the page has loaded and while typical background scripts are active. A recording that contains no interaction cannot explain why a real interaction is slow.

The delay can happen before your handler runs. Another script may already occupy the main thread, leaving the input waiting. It can happen inside your handler, perhaps because a filter recalculates a large collection. It can also happen afterward, when the browser needs to style, lay out and paint a large update.

Treat those phases separately. Removing a redundant analytics callback will not solve an expensive layout operation. Shortening a handler will not remove the task that blocks it from starting. Your trace should identify which phase dominates before you choose a fix.

Reduce unnecessary work first. Then split work that does not need to complete before visual feedback. Yielding between chunks gives the browser opportunities to process other work; moving suitable non-DOM computation to a worker can keep it off the main thread. Neither technique excuses an algorithm that repeatedly processes data it does not need.

An ordinary Lighthouse navigation test uses Total Blocking Time as a useful lab indicator of main-thread blocking. TBT is not INP and cannot be entered in the INP field of a checker. Controlled interactive recordings can measure interaction latency; the limitation is the loading-only test, not all laboratory measurement.

Diagnose CLS by finding what caused the movement

The element that moved may be a victim rather than the cause. If a paragraph shifts downward, inspect what appeared above it. A newly inserted banner or an image without reserved dimensions may have changed the space available to the paragraph.

Start with images and video. Their dimensions or an appropriate aspect ratio let the browser reserve space before the media arrives. Then examine advertisements, embedded players, recommendation panels and other content that appears asynchronously. A placeholder needs a realistic size for each breakpoint, not just a decorative loading animation.

Fonts need attention too. A fallback font and a downloaded web font can use different character widths and vertical metrics. The swap can change line wrapping and move nearby content. Choose appropriate loading behavior and consider matching fallback metrics rather than assuming that showing text immediately eliminates all layout risk.

Do not solve a shift by making the page inaccessible. Fixed overlays can obscure content or controls, especially at narrow widths or enlarged text sizes. After changing a banner or slot, test keyboard navigation, zoom and the space available for the main task.

A reload-only recording can miss post-load shifts. Leave the recording running while you scroll, open the relevant controls and wait for the content that normally appears later. Compare the recorded movement with the field problem before deciding it has been fixed.

Build a small, repeatable measurement routine

Choose representative pages instead of testing only the homepage. Include an article, a category, a product page or another template that matters to your visitors. Record which shared components they use, such as navigation, fonts, advertising slots and consent controls.

Keep a baseline for each relevant device category. Save the report, the date, the tested version and the important metric values. Run comparable lab tests more than once under the same conditions. A favorable isolated result is not enough to distinguish an improvement from normal variation.

For a development project that already bundles the web-vitals package, this small diagnostic module logs the metrics that the browser reports. It is a local debugging example, not a complete analytics system.

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

Some callbacks reflect the lifecycle of the page or the interactions you perform. Do not expect three meaningful values immediately after opening a quiet tab. Production collection needs an endpoint, aggregation, sampling decisions and appropriate privacy controls; console output provides none of those.

After deployment, monitor for regressions and let the field collection window reflect new visits. A rolling window contains both earlier and later experiences until enough time has passed. Repeatedly running Lighthouse does not accelerate that process or populate missing CrUX traffic.

Put Core Web Vitals in the right SEO context

Google Search Central says Core Web Vitals are used by its ranking systems, while also explaining that good report results do not guarantee high rankings. Relevance, useful content and other aspects of page experience still matter. There is no documented conversion from a Lighthouse score increase to a ranking-position increase.

This makes prioritization more practical. If visitors cannot use a filter, fix the filter because it obstructs their task. If a prominent image loads late across a widely used template, address the shared cause. Avoid spending the entire budget moving an already strong synthetic score by one point while important content remains difficult to find or use.

Turn the first finding into a specific change

Pick one representative URL and one failing metric. Write down the observed cause, the proposed change and the evidence you will compare afterward. That creates a bounded task another developer can implement and another reviewer can assess.

Use the Core Web Vitals checker to classify measured values, keeping their source and units intact. Use the performance checklist to track implementation work. The wider Core Web Vitals guides provide the next diagnostic branch once you know which part of the visit needs attention.