Core Web Vitals Audit: How to Check LCP, INP, and CLS Before Launch

A page can feel fast on a developer's laptop and still be slow for the people who use it.

That gap is exactly why Core Web Vitals need more than one test. A clean Lighthouse run is useful, but it does not prove that real visitors get the same experience. A poor field result is important, but it does not tell you which image, script, component, or interaction should be fixed first.

A useful Core Web Vitals audit connects three things:

Real-user evidence from the field
Repeatable diagnostics from the lab
The actual page element or interaction causing the delay or instability

This guide explains how to audit Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift before launch, after a redesign, or while investigating a performance regression.

What Core Web Vitals measure

Core Web Vitals describe three different parts of the user experience.

**Largest Contentful Paint (LCP)** measures loading performance. It asks how quickly the main visible content appears.
**Interaction to Next Paint (INP)** measures responsiveness. It asks how quickly the page gives visible feedback after a user interacts with it.
**Cumulative Layout Shift (CLS)** measures visual stability. It asks how much visible content moves unexpectedly while the page is in use.

The current good thresholds are:

LCP at or below 2.5 seconds
INP at or below 200 milliseconds
CLS at or below 0.1

These thresholds are evaluated at the 75th percentile in field data. In practical terms, the target is not one unusually fast visit. At least three out of four visits should meet the good threshold.

Start by separating field data from lab data

The most common mistake in a performance audit is treating every number as if it measured the same thing.

It does not.

**Field data** comes from real users. PageSpeed Insights can surface Chrome User Experience Report data for a URL or, when URL-level data is insufficient, for the origin. It reflects a rolling 28-day period across real devices, connections, locations, and visits.

**Lab data** comes from a controlled test. Lighthouse loads the page with a defined device and network profile. This makes the test repeatable enough for debugging and comparison, but it remains a simulation.

**Browser-observed data** describes the page open in your current browser session. It can help you inspect a local build, staging page, authenticated flow, or interaction. It is useful evidence, but it is not the same as official CrUX field data.

Each source answers a different question:

Field data: Are real visitors having a good experience?
Lab data: What is likely slowing this test run?
Browser observation: What happened in this session on this page?

A mature audit keeps those answers separate.

Why a new page may have no field data

Field data needs enough eligible visits. A new page, low-traffic URL, private preview, or staging environment may not have enough samples for URL-level reporting.

When that happens, a tool may show origin-level data or no field data at all. Neither result means the page is fast.

Origin data describes the broader site. It can reveal a template, platform, or device problem, but it may hide an issue unique to the page you are auditing. No field data simply means you need to rely on lab tests, browser observation, and performance budgets until real-user evidence becomes available.

Do not postpone obvious fixes because the field report is empty. A five-megabyte hero image is still a launch risk even if the page has not collected enough visits to produce a red LCP result.

Run mobile and desktop tests separately

Mobile and desktop users do not experience the same page under the same conditions.

They may receive different image sizes, navigation patterns, components, ads, and JavaScript behavior. Mobile devices also tend to have slower processors and less reliable networks. A strong desktop result can therefore coexist with a poor mobile experience.

Run both strategies and keep the results separate. For most public websites, investigate the mobile result first when it is materially worse, but do not assume every mobile problem is caused by the network. Main-thread JavaScript, hydration, expensive rendering, and third-party scripts can be just as important.

Repeat a lab test when the result is surprising. One run can be affected by test conditions. Look for a pattern across several runs rather than optimizing around a single outlier.

Audit LCP: find the main content element

LCP is often described as a speed metric, but the first diagnostic question is more concrete:

```txt Which element became the Largest Contentful Paint? ```

On a typical page, the LCP element may be:

a hero image
a product image
a large heading
a text block
a video poster
a background image

Once you know the element, trace the path required to display it.

For an image, check whether the browser discovers it early, whether it is oversized, whether it uses an efficient format, and whether the page accidentally lazy-loads it. Also check whether CSS, fonts, client-side rendering, or a redirect delays the request.

For a text element, check server response time, render-blocking styles, web-font behavior, and whether JavaScript delays the content from appearing.

Common LCP causes include:

slow server response
a large or poorly compressed hero image
an important image discovered late
lazy loading applied above the fold
render-blocking CSS
client-side rendering that withholds the main content
a long critical request chain
slow font delivery
a consent tool, experiment, or tag delaying rendering

The fix depends on the element. Compressing every image will not solve an LCP heading delayed by JavaScript. Removing JavaScript will not fix a huge hero image downloaded at the wrong size.

Prioritize the LCP request

When the LCP element is an image, make it easy for the browser to discover and prioritize.

The image should normally appear in the initial HTML, use an appropriate responsive source, and avoid lazy loading when it is immediately visible. It should also reserve its dimensions to prevent layout shift.

Preloading can help when the browser would otherwise discover the image late, but it should be used carefully. Preloading too many resources creates competition and can make the critical path worse.

The goal is not to mark everything as high priority. The goal is to make the one or two resources that define the first meaningful view arrive early.

Audit INP: test real interactions

INP cannot be understood by staring at the page during initial load. You need to interact with it.

Test the actions people actually use:

open the mobile navigation
expand an accordion
switch a tab
filter a product list
type into search
change a quantity
open a modal
submit a form
select a date
add an item to a cart

INP measures the delay from an interaction until the next visual update. A page can load quickly and still feel unresponsive because the main thread is busy when a visitor taps or types.

Common INP causes include:

long JavaScript tasks
large framework updates after input
expensive event handlers
synchronous third-party code
rendering too many list items
repeated style and layout calculations
heavy client-side validation
hydration work competing with early interactions

Do not test only the easiest button. Find the slowest important interaction in the real user journey.

Fix the work that blocks feedback

An interaction feels slow when the browser cannot quickly acknowledge it. The page may be calculating, parsing, rendering, or waiting for synchronous code before it can paint the result.

Useful fixes often include:

breaking long tasks into smaller units
reducing unnecessary JavaScript
postponing non-critical work
rendering fewer nodes at once
simplifying component updates
avoiding repeated layout reads and writes
giving immediate visual feedback before slower work completes
moving suitable computation away from the main thread

The best fix is not always making the entire operation finish immediately. Sometimes the right improvement is to show a pressed state, spinner, optimistic update, or partial result quickly so the user knows the interaction succeeded.

Audit CLS: watch the page over time

CLS problems are visual and often intermittent. The page may look stable during a quick screenshot but shift after a font loads, an ad appears, a banner opens, a recommendation widget renders, or a responsive image receives its final dimensions.

Scroll through the full page and wait for delayed content. Repeat the test at common mobile and desktop widths. Interact with menus, consent banners, filters, carousels, and forms.

Common CLS causes include:

images without reserved dimensions
embeds or iframes without stable containers
banners inserted above existing content
ads that change size after loading
web-font swaps that significantly change text dimensions
late CSS
components that render placeholders at the wrong height
animations that move layout instead of using visual transforms

A useful CLS audit identifies both the element that moved and the element that caused the movement. They are not always the same. A paragraph may shift because an image above it had no reserved space.

Reserve space before content arrives

The most reliable CLS strategy is to decide the layout before asynchronous content finishes loading.

Set image dimensions or aspect ratios. Give embeds, video players, ad slots, and dynamic modules predictable containers. Make placeholders resemble the final component. Avoid inserting notices above content unless the layout already accounts for them.

For web fonts, choose fallback fonts and font-loading behavior that minimize large changes in line length and block height. For animations, prefer transforms and opacity when possible because they do not reflow the document in the same way as changing layout properties.

Read the whole report, not only the score

The Lighthouse performance score is a useful summary, but it is not the launch decision by itself.

Read the individual metrics and diagnostics. Look at the LCP element, resource sizes, request chains, unused JavaScript, main-thread work, image delivery, layout-shift sources, and the opportunities with the largest realistic impact.

A score can move between runs even when the page has not changed. A score can also improve while an important user interaction remains slow. The audit should be based on the evidence behind the score.

Treat opportunities as leads, not automatic requirements. A large estimated saving deserves investigation, but the recommended change still has to make sense for the page and its users.

Compare against the right baseline

Performance becomes easier to manage when every important change has a before-and-after comparison.

Before a redesign, campaign launch, analytics change, or large dependency update, save a baseline for the same URL and strategy. After deployment, run the same tests again and compare:

performance score
LCP, INP, and CLS where available
total transfer size
important resource groups
the LCP element
top diagnostics and opportunities
field-data source: URL or origin

Do not compare a desktop test with a mobile test or origin-level field data with URL-level data as if they were equivalent. Keep the method consistent enough that the difference means something.

Turn findings into launch priorities

Core Web Vitals findings should enter the same priority system as the rest of launch QA.

**Fix before launch** when the page has a severe regression, the primary content loads unreasonably late, an essential interaction repeatedly freezes, or layout movement makes the page difficult or unsafe to use.

**Fix soon** when a metric misses the good threshold, a large opportunity has a clear solution, or mobile performance is substantially worse than the existing production baseline.

**Monitor** when the result is close to a threshold, field and lab data disagree, the page lacks enough field data, or the remaining work needs real-user evidence to prioritize safely.

Avoid delaying a release to chase a perfect score with low-impact changes. Also avoid dismissing a bad experience because performance is only one part of SEO. The right decision considers user impact, business-critical flows, regression size, and the effort required to fix the cause.

A practical Crowra performance audit workflow

Open the final public URL in Chrome and scan it with Crowra. In the Technical tab, run PageSpeed for mobile and desktop. Keep the PageSpeed field data, Lighthouse lab metrics, and browser-observed timing labeled as separate sources.

Start with mobile. Check whether field data is available and whether it represents the URL or the origin. Review LCP, INP, and CLS ratings, then use the lab metrics and opportunities to investigate the likely cause. Compare the resource breakdown with the visible page so you can connect large image, script, font, or stylesheet totals to actual components.

For a local, private, or staging URL, Google PageSpeed cannot run against the page. Use browser-observed signals and local developer tools during implementation, then repeat the PageSpeed check on the final public URL after deployment.

If the release includes image changes, pair the performance review with an image SEO audit. If it includes a new template or broad navigation change, sample several representative URLs instead of treating one page as proof that the entire site is healthy.

Crowra helps organize the page-level evidence and the handoff. It does not replace continuous real-user monitoring, the Search Console Core Web Vitals report, or deep profiling in Chrome DevTools when the problem needs code-level diagnosis.

Core Web Vitals audit checklist

Before launch, confirm the following:

Mobile and desktop tests were run separately.
Field data and lab data were not treated as interchangeable.
The field result identifies whether it represents the URL or the origin.
Missing field data was not interpreted as a passing result.
The LCP element was identified.
The LCP resource is discoverable, appropriately sized, and prioritized.
Important images reserve space and avoid accidental lazy loading above the fold.
Real navigation, search, form, filter, and purchase interactions were tested.
Long tasks or heavy updates do not delay visible interaction feedback.
The page was observed for delayed layout shifts.
Images, embeds, ads, banners, and dynamic modules reserve stable space.
Mobile performance was compared with the existing production baseline.
High-impact findings have an owner and a clear next action.
The final public page will be tested again after deployment.

The purpose of a Core Web Vitals audit is not to make every number green for a screenshot. It is to find where loading, interaction, or layout behavior creates friction for real people, fix the causes with the greatest impact, and launch with evidence instead of assumptions.