Core Web Vitals in Practice: Fixing INP, LCP and CLS in the Right Order

The three metrics in plain words

Each metric stands in for a different kind of user frustration: waiting, tapping and shifting.

Two details about how these are assessed change how you should work. Scores are taken at the 75th percentile of real visits, which is why a fast laptop on office wifi tells you almost nothing. And assessment is per URL group over a rolling 28-day window, so a fix shipped today will not be fully reflected for weeks.

Why INP catches teams out

LCP is a loading problem and most teams have some intuition for it. INP is different: it measures the delay between a tap and the visible response, across every interaction in the session, and reports close to the worst one. A page can load quickly and still fail badly.

The usual culprits, in the order we tend to find them:

• Tag managers and analytics running long tasks on the main thread, often several containers deep with no owner.
• Chat widgets and consent banners that initialise heavy work on first interaction — precisely when the user is trying to interact.
• Large hydration or re-render work in single-page frameworks, where tapping a filter re-renders half the page.
• Event handlers doing layout-triggering work synchronously, so every keystroke forces a reflow.
• Oversized DOM trees, where even cheap work becomes expensive because there is so much to recalculate.

A useful diagnostic habit: reproduce on a mid-range Android device with network and CPU throttling, not on your own machine. Most INP failures are invisible on developer hardware.

The audit order that works

1. Start with field data, not lab data. Real-user measurement tells you which templates actually fail for actual visitors.
2. Group failing URLs by template. Fixing the category template fixes every category page at once.
3. Weight by traffic and revenue. A template with 2% of sessions is not where to start, however bad its score.
4. Profile one representative URL per failing template and identify the single largest contributor.
5. Fix that one thing, ship it, and wait for field data to confirm the direction. Batched fixes hide which change helped.
6. Repeat until the template passes, then move to the next-highest-value template.

The fixes that reliably move numbers

The list of possible optimisations is endless. This is the short list that accounts for most of the improvement on most sites.

For LCP

• Serve the hero image at the right dimensions in a modern format, and preload it. This is the single biggest lever on most sites.
• Remove render-blocking CSS and JavaScript from the critical path; inline only what the first screen needs.
• Cache HTML at the edge wherever the page is not personalised.
• Self-host fonts, subset them, and use font-display: swap so text is never invisible.

For INP

• Defer or lazy-load every third-party script not needed for the first interaction, and delete the ones nobody can name an owner for.
• Break long tasks — yield to the main thread between chunks of work rather than blocking it for hundreds of milliseconds.
• Debounce expensive handlers, and move heavy computation off the main thread where it is genuinely needed.
• Render the visual response to a tap before doing the work behind it, so the interface feels immediate.

For CLS

• Reserve space for images, ads and embeds with explicit width and height or aspect ratio.
• Never insert banners or notices above existing content after load.
• Load fonts in a way that avoids a large metric shift when the web font swaps in.

Notice what is absent: rewriting the site. We have taken the overwhelming majority of failing sites into the green without changing the framework, and the ones that did need re-platforming needed it for other reasons anyway.

Keeping it from coming back

Performance decays by default. Every new tag, embed, hero video and marketing widget adds weight, and each one is individually defensible. Three habits hold the line:

• A written budget — a maximum page weight and JavaScript size per template, agreed with marketing as well as engineering.
• Automated checks in CI that fail the build when a budget is exceeded, so the conversation happens before release rather than after.
• A named owner for third-party scripts, with a quarterly review that deletes what is no longer used.

The last one is quietly the highest-return habit on this entire list. On most sites we audit, at least one third-party script is still loading for a campaign that ended years ago.