Core Web Vitals keeps evolving, and each update has caught teams that treated their last optimization pass as a one-time project rather than an ongoing discipline. The metrics themselves matter less than the underlying pattern: Google keeps refining what it measures because real user experience keeps revealing new ways a technically “fast” page can still feel slow or frustrating to use.
Where the metrics have actually shifted
The move from First Input Delay to Interaction to Next Paint (INP) as the responsiveness metric is the most consequential recent change, and it changes what “good performance” actually requires. FID only measured the delay before a browser could begin processing the very first user interaction - a narrow, easily-gamed measurement. INP measures the full responsiveness of every interaction throughout a page’s lifecycle, including how long it takes for the visual result of an interaction to actually appear, not just when processing starts. A page that scored well on FID by being fast on that first click can still score poorly on INP if later interactions - after more content and scripts have loaded - are sluggish.
What actually drives poor INP scores in practice
- Long JavaScript tasks blocking the main thread during an interaction - heavy computation, large re-renders, or inefficient event handlers that tie up the thread long enough that a click or tap feels delayed even though the underlying logic completes eventually.
- Third-party scripts - analytics, ad tech, chat widgets, embedded content - often the single largest, least-controlled contributor to poor interaction responsiveness, because they’re outside your own codebase’s direct optimization and frequently not built with the same performance discipline your own code follows.
- Excessive DOM size and complexity, which makes every interaction’s downstream rendering work more expensive, even for logic that itself runs quickly - a large, deeply nested DOM tree taxes the browser’s rendering pipeline regardless of how efficient your JavaScript is.
What we actually do to address this
- Breaking up long tasks - using techniques like yielding to the browser during heavy computation (via scheduler APIs or simply chunking work) so a single expensive operation doesn’t block the main thread long enough to make an interaction feel unresponsive.
- Auditing and constraining third-party scripts - loading them deliberately (deferred, lazy-loaded, or via a sandboxed approach like partytown) rather than accepting whatever default loading behavior each vendor’s snippet ships with, and periodically re-auditing as new scripts get added over time by different teams.
- Simplifying DOM structure where it’s grown unnecessarily complex - often a byproduct of component composition over time producing more nested markup than the actual visual result requires.
Why this needs to be ongoing, not a one-time project
Performance regresses by default as a product grows - new features add scripts, new third-party integrations get bolted on, components accumulate complexity - unless something actively prevents it. We build performance budgets into CI for clients specifically so a pull request that would meaningfully degrade Core Web Vitals gets flagged before it ships, not discovered months later in an audit when the fix is a much larger, more disruptive undo.
What we’d actually recommend right now
If your last Core Web Vitals optimization was more than a few months ago, treat it as stale, not finished - re-audit against current metrics, particularly INP if that wasn’t the focus last time, and check specifically what third-party scripts have been added since. This is one of the areas where “we already did this” is one of the most common and most costly false assumptions we encounter.
We build performance monitoring and optimization into our ongoing web development engagements, not as a one-time deliverable. Get in touch for a current audit of where your site actually stands.