Core Web Vitals in 2026: still boring, still decisive

Where sites fail in 2026

LCP is mostly solved by CDN + image discipline. Most audits show LCP passing on desktop and marginal on mobile, usually fixable by preloading the hero image and shipping AVIF or WebP with correct sizes.

CLS is mostly solved by explicit dimensions on images, video, and third-party embeds. Where CLS still fails, it's usually a delayed ad slot or a consent banner injected after paint.

INP is where 60%+ of the sites we audit fail at p75. It's the current mainstream failure mode, and it's the one that requires actual engineering rather than a one-off template tweak. Every serious performance conversation in 2026 is really an INP conversation.

The INP autopsy

The usual culprits: hydration of oversized React trees on interaction, third-party tag managers firing synchronous scripts on click, overzealous animation on user interactions that runs on the main thread, and event handlers that trigger large state updates without transitions.

The autopsy pattern is consistent. Open Chrome DevTools performance panel, record a real user interaction (usually the mobile menu open, the search open, or the primary CTA click), and look at the long task in the trace. Nine times out of ten the task is a hydration cascade or a third-party script chain, not the app's own code doing anything unreasonable.

The tenth time is usually an animation library running expensive property transitions (layout-triggering CSS properties, or JavaScript-driven position updates) on the main thread. Fixing this is a matter of moving the animation to compositor-safe properties (transform, opacity) or to the Web Animations API.

The four fixes that ship 90% of the wins

One: defer non-critical JavaScript. Anything below the fold, anything not required for the first user interaction, gets deferred or dynamically imported. React.lazy plus Suspense covers most of this in modern stacks.

Two: move analytics and tag manager work to a worker. Partytown or a similar solution moves GTM off the main thread. This alone often takes a failing INP score to passing on sites where GTM is the primary offender.

Three: break large components with useTransition. Any state update that triggers a re-render of a substantial subtree should be wrapped in a transition. This tells React to prioritise input responsiveness over render completeness.

Four: debounce or memoise expensive handlers. Search-as-you-type without debouncing, filter inputs that trigger a re-fetch on every keystroke, live-search dropdowns that don't memoise their results — these are all common INP failures with well-understood fixes.

Third-party scripts: the honest conversation

The uncomfortable truth is that third-party scripts are usually the largest single INP contributor and the hardest to fix without political friction. Marketing wants the marketing automation script. Sales wants the chat widget. Analytics wants everything.

The pragmatic move is a script budget, negotiated once per quarter, with a hard cap on total third-party JavaScript weight and a review process for any new script. This is easier to sustain than case-by-case negotiation and it forces the conversation to happen when nobody is under pressure to ship anything specific.

The script that most reliably survives the budget conversation is analytics. Everything else is on the table. Chat widgets, in particular, are worth interrogating: if the widget adds 300ms to INP and the chat volume doesn't justify it, it's worth loading only on the pages where chat conversion is measurably useful.

Measuring in the field, not the lab

Lab data lies about INP. Lighthouse and PageSpeed Insights simulate a limited interaction set and consistently under-report INP relative to what real users experience. CrUX (Chrome User Experience Report) plus a lightweight RUM library in production is the only honest measurement.

We ship a RUM dashboard in every engagement where performance is in scope. The dashboard shows p75 INP by page template, by device class, and by network condition. This lets us prioritise fixes on the templates that are actually failing for real users, not the templates that happen to look bad in a synthetic test.

The RUM library we default to is web-vitals; it's under 2KB, it's actively maintained by Google, and it reports to any analytics endpoint. We wire it into GA4 or a simple serverless collector depending on the client's stack.

A phased performance roadmap

Phase one, weeks one and two: instrumentation. Ship the RUM library, get real user data flowing, build the dashboard. Do not fix anything yet — you don't know what's actually broken until you see the field data.

Phase two, weeks three to six: the quick wins. Defer non-critical JS, add explicit dimensions to images and embeds, preload the hero image, move GTM to Partytown if applicable. Most sites see p75 INP move by 30–50% from this phase alone.

Phase three, weeks seven to twelve: the real fixes. Refactor the largest hydration cascades, wrap expensive state updates in transitions, negotiate the third-party script budget, replace animation libraries running on main thread. This phase is the majority of the engineering work and where the sustained wins live.

Phase four, ongoing: budget enforcement and quarterly review. Once the site is passing, protect it. Every new feature should be scoped against the performance budget before it ships.

What we still get wrong

We consistently under-estimate how much time the negotiation with marketing takes on third-party scripts. Budget three times the engineering time for the stakeholder conversation and you'll be about right.

We used to under-invest in RUM instrumentation and try to fly on lab data. That's a lesson we've learned the expensive way. Ship instrumentation first, always.

We still occasionally ship a fix that improves lab scores while leaving field metrics unchanged. This usually means the fix addressed a synthetic bottleneck that wasn't in the real user critical path. RUM before and after every fix catches this.