Fixing Interaction to Next Paint on content-heavy sites

Since Interaction to Next Paint replaced First Input Delay as a Core Web Vital, the number of sites failing the assessment has risen noticeably. FID only measured the delay before the browser started handling the first interaction; INP measures the full time from a tap, click or key press until the next frame is painted, across all interactions on the page, and reports one of the worst. Sites that passed comfortably for years suddenly show "needs improvement" or "poor" on mobile. The good news is that INP problems usually have a small number of causes, and they are fixable without a rebuild. This is how we find and fix them.

Start with field data, not lab scores

INP is a field metric. Lab tools can help reproduce issues, but they do not know which interactions real users perform on which devices. We start with three sources:

1. Search Console's Core Web Vitals report to see which groups of URLs fail, usually aligned with templates.
2. Public field data for origin and URL-level trends over the last 28 days.
3. Real user monitoring with attribution. This is the most useful. A small script using the web-vitals library can report the slowest interaction's target element, event type and a breakdown of input delay, processing time and presentation delay to your analytics.

That breakdown tells you where to look. High input delay means the main thread was busy when the user interacted. Long processing time means your event handlers are slow. Long presentation delay means rendering after the handler is expensive.

The usual causes

Across the content sites, stores and marketing sites we have worked on, the same culprits appear again and again:

• Third-party scripts. Tag managers loading a dozen marketing tags, chat widgets, consent managers, A/B testing tools and session recorders, all competing for the main thread. On one publisher site, third-party code accounted for about 70 percent of main-thread time during the first ten seconds.
• Heavy hydration. JavaScript frameworks hydrating an entire page on load, blocking interactions on the parts users reach first.
• Expensive event handlers, such as a menu toggle that triggers layout calculations across the whole document, or an add-to-cart handler that synchronously re-renders a large component tree.
• Large DOM size. Pages with 3,000 or more elements make every style recalculation and layout slower. Mega menus and long product grids are frequent offenders.
• Consent banners that do significant work on the first click, which is often the user's first interaction on the page.

Most INP fixes are not clever optimizations. They are decisions to do less work on the main thread, or to do it later.

Fixes that move the numbers

Govern third-party scripts

Inventory every tag, note its owner and purpose, and remove anything unused. Then delay non-essential tags until after the page is interactive or until the user has engaged. Chat widgets can load on intent, for example when the user scrolls or hovers over a help link. Moving eligible tags to server-side tagging reduces client-side work further. This step alone often takes a site from "poor" to "needs improvement."

Break up long tasks

Any task longer than 50 milliseconds blocks interactions. Split long work into smaller chunks and yield to the main thread between them, so the browser can respond to input. For event handlers, do the minimum needed for visual feedback first, such as opening the menu or showing a spinner, and defer the rest.

button.addEventListener('click', async () => {
  showLoadingState();
  await yieldToMain();
  updateCartAndAnalytics();
});

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

Reduce rendering cost

Trim DOM size by lazy-rendering off-screen sections, simplifying mega menus and paginating long lists. Use CSS containment on independent components so style changes do not ripple across the page. Avoid reading layout properties immediately after writing styles, which forces synchronous layout.

Hydrate less

On framework-based sites, adopt partial or progressive hydration so only interactive components ship JavaScript, and prioritize hydrating what is above the fold. On WordPress and Shopify themes, that often means removing a front-end library used for one slider and replacing it with a few lines of vanilla JavaScript.

Platform-specific notes

The same principles apply everywhere, but the work looks different by platform:

• WordPress: page builders and slider plugins are the most common sources of heavy scripts and bloated DOM. Replacing them with native blocks usually improves INP more than any caching plugin.
• Shopify: apps inject scripts on every page, even where unused. Auditing app embeds and removing leftovers from uninstalled apps is often the first win.
• React and Next.js: large client components and state updates that re-render whole trees are typical. Moving static sections to server components and memoizing expensive children helps considerably.

Whatever the platform, test on a mid-range Android phone. Most INP problems are invisible on a developer laptop.

Verify and keep it fixed

Field data lags. Changes take up to 28 days to show fully in public reports, so we rely on our own real user monitoring to confirm improvements within days. Once INP is green, we add a performance budget to the release process: a cap on total JavaScript per template, a review step for new third-party tags and alerts when field INP at the 75th percentile rises above 200 milliseconds. Without that guardrail, a single new marketing tag can undo months of work.

Typical results on content-heavy sites are a reduction of 40 to 60 percent in INP at the 75th percentile, with most of the gain coming from third-party governance and handler changes. The effect on rankings is modest on its own, but the effect on engagement and conversion is often measurable, particularly on mobile.

Our Core Web Vitals optimization service includes real user monitoring setup, diagnosis and implementation. For WordPress sites, much of this overlaps with WordPress speed optimization, and for Shopify with store speed tuning.

Get your INP back in the green

Share your domain and which templates are failing, and we will scope a fixed-price engagement to diagnose and fix them. Request a performance quote.