Tutorial · performance · Published 2026-08-16 · 4 min read
An LCP, INP and CLS audit procedure
Audit LCP, INP and CLS in a repeatable procedure: field data first, per metric checks, and a re-run to verify the fix list.
Field first, lab second
The audit starts with real-user data because lab tools simulate one connection while field data reflects real users. Open the URL in PageSpeed Insights and record the 75th percentile LCP, INP, and CLS from the field report, plus the CrUX origin where the page does not yet have enough data. Record the baseline, because the whole audit is measured against it.
Use the same page that matters: the homepage, or the first money page of a campaign. The Core Web Vitals basics article explains the thresholds and the p75 logic, so this procedure assumes you know to compare like for like.
Replay the load, not the screenshot
Open the page in DevTools with the network throttled to Fast 3G or the lab preset, and reload once to warm browser caches before the measurement run. Then:
- Record the waterfall and note the LCP resource and its load start and finish times.
- Run Lighthouse from the same URL and note the three LCP/INP/CLS hints with their estimated savings.
- Open the Performance panel and capture a trace of a click on a header control (for INP).
- Toggle device toolbar and resize to a narrow viewport (CLS often differs between views).
The audit stays in the DevTools until you have all four: LCP resource, INP long task, CLS item, and layout shift.
Check the LCP resource
The LCP guide has the full playbook; the audit confirms three things:
- Is the LCP element text or image? If the text is the LCP, the bottleneck is usually CSS or the document; if it is an image, the image is the bottleneck.
- Is the LCP resource the biggest render (hero) and small enough? A hero bigger than 200 KB at render size is the most repeatable single win.
- Is it hinted or preloaded? The preload hero and preconnect checks apply.
If the LCP resource starts late in the waterfall, fix the document chain first (render-blocking CSS/JS) and only then attack the file weight.
Check INP from a trace
INP is a main thread metric, so the check is a click handler trace. Click a control and read the "tasks" column:
| Signal | Meaning |
|---|---|
| A long task (50ms plus) before the response | Main thread busy, likely a heavy script |
| The handler itself is long | The control logic is heavy, split or debounce it |
| A read/gap with no task | User event waited on another script |
The INP guide maps the traces to fixes: reduce the script weight, break long tasks, and keep listeners light. When a site feels slow but LCP is great, INP is almost always the story, and the trace is the giveaway.
CLS items
CLS is positional, so walk the page after the load and spot the shifting elements. The check:
- Images whose dimensions are absent (blanks shift on the load).
- Fonts that swap late (the font loading passes).
- Third-party widgets that insert above the fold.
Each fix is a width/height on the img, a size on the container, or a reserve space for the widget. Reserve space is the change that makes the metric stay low after a re-run.
Re-run and verify
After making fixes, re-run the exact same PageSpeed Insights and Lab baseline and compare numbers. Verification before completion means the metric falls and stays: re-run 3 times at different times, and check the web vitals help box or your field report a week later. If the page still fails, go back to the element-specific guides and isolate one metric at a time, because LCP, INP and CLS regressions usually come from different parts of the page.
Prevention
Turn the audit into a gate: keep the table, re-run the same three checks after every notable frontend change, and leave a budget for the metrics as part of the performance budget. The procedure is repeatable in 30 minutes, and the discipline is what keeps the numbers green instead of rediscovering them seasonally.