WordPress INP vs Next.js: Why the Menu Takes a Beat to Open

The metric that grades every tap, not just the first

Interaction to Next Paint became a Core Web Vital on March 12, 2024, replacing First Input Delay, according to Google's announcement on web.dev. The change mattered. FID timed only the wait before the browser started handling a visitor's first interaction. It ignored the handler's own work and the repaint afterwards, and it ignored every interaction after the first. Plenty of heavy sites passed it.

INP is stricter. Per Google's INP documentation, it observes the latency of every click, tap and key press during the visit and reports one of the slowest, ignoring one outlier for every 50 interactions. Hovering, zooming and scrolling do not count. An INP of 200 milliseconds or less is good, and anything above 500 milliseconds is poor, judged at the 75th percentile of page loads. Each interaction has three phases:

• Input delay: the wait before your event handlers can start, usually because the main thread is busy with something else.
• Processing duration: the time the handlers themselves take to run.
• Presentation delay: the time from the handlers finishing to the browser painting the next frame.

Underneath all three sits one rule. The browser's main thread does one task at a time, and Google calls any task longer than 50 milliseconds a long task. Every long task on the page is a door a tap may have to wait behind. The Core Web Vitals overview puts INP next to its two siblings; this page stays on the main thread.

Who is holding the main thread on a WordPress page

Start with a fair point: modern lightweight themes are rarely the culprit. In the theme source we checked, Astra 4.14's front-end scripts depend on jQuery only for one WooCommerce script, Kadence 1.5.2's only for WooCommerce-related scripts, and GeneratePress 3.6.1 uses jQuery in the Customizer, not on the front end. Blocksy registers no script with a jQuery dependency at all. The scripts fighting your visitors usually arrive later, from somewhere else.

• jQuery plugins. jQuery itself is a library, not a sentence. The cost is the decade of plugins written around it, which attach handlers to every matching element and run setup routines on page ready, all in the main thread.
• Sliders. A slider measures the screen, clones slides, starts autoplay timers and listens for resizes. That work competes with the first taps, and autoplay keeps adding tasks for as long as the page is open.
• Page builders. Each widget type can bring its own front-end script. Builders also nest containers deeply, and Google notes that large DOMs make every rendering update after an interaction more expensive.
• Chat widgets. A chat bubble is usually a full third-party application that boots on every page, whether or not anyone wants to chat.
• Tag managers. Every tag is a script. Click-tracking tags add listeners that run on the very taps INP is measuring, before the page can respond.
• Overzealous optimization. Combining and deferring scripts can break handlers outright. OceanWP's staff acknowledged in August 2026 that its mobile menu stops working with SiteGround Speed Optimizer's Combine JS on, and a Neve user traced an unresponsive iPhone hamburger to the same plugin.

That last item deserves a footnote. A menu that never opens has no INP problem, because nothing interacted. It has a much bigger one, covered in our guide to a WordPress mobile menu not working.

Three phases, two stacks, the usual suspects

The table makes the honest point. Both stacks fail INP for the same physical reason: too much JavaScript on one thread. WordPress tends to get there through accumulation, one plugin at a time. Next.js tends to get there through ambition, one oversized component at a time. Google's INP optimization guide applies to both.

Theme scripts, credited and cautioned

Some builder themes ship real tools. Divi's Performance tab turns on Dynamic JavaScript, which loads libraries only when a page uses them, and moves jQuery to the footer unless a header script needs it. Avada can combine scripts with its JS compiler, disable jQuery Migrate and defer jQuery to the footer, though its documentation warns the deferral can break scripts. Neve Pro's Lazy Rendering applies content-visibility to off-screen elements, a technique Google lists for cutting rendering work. Bricks says its front end runs on plain JavaScript with no jQuery. Details are in our speed guides for Divi, Avada, Neve and Bricks.

Older stacks carry more. Hestia enqueues Bootstrap's JavaScript, which depends on jQuery, plus a parallax script. Storefront loads its navigation and homepage scripts alongside WooCommerce's cart fragments script. Flatsome's 3.15 release notes, as summarized on ThemeForest, put its core JavaScript at 56 KB, 16 KB gzipped, which is modest until the add-ons arrive. See Hestia, Storefront and Flatsome for the specifics.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Hydration: the bill Next.js pays at the door

A Next.js page arrives as finished HTML, which is why it paints fast. To make the buttons work, React then hydrates the page: the Next.js docs define hydration as attaching event handlers to the server-rendered HTML. Hydration is JavaScript running on the main thread during load. A tap that lands in that window waits, and a button whose component has not hydrated yet has no handler to run.

React Server Components are the answer to that bill. A Server Component renders on the server and sends its result, not its code, so it never needs hydrating. Only files marked with the use client directive, and everything they import, go into the browser bundle, and the Next.js docs advise putting that directive on specific interactive pieces rather than large sections of the page. A service page built that way might hydrate a menu button, a form and an accordion, and nothing else.

Third-party scripts get a dial too. The next/script component loads scripts after some hydration by default, can hold low-priority scripts until the browser is idle, and has an experimental option to run them in a web worker. On a custom Next.js build, the chat widget and the analytics tag are placed deliberately, one decision each.

How a Next.js site fails INP anyway

It would be convenient to stop there. It would also be untrue. A Next.js site can fail INP as thoroughly as any WordPress site, and the ways it does so are worth knowing before you hire anyone.

• Use client at the top. Mark a whole page or layout as a client component and every import comes along. The page now hydrates everything, Server Components or not.
• Rendering in the browser. A product filter that rebuilds a long list on every keystroke is a long-task generator. Google notes that when HTML is built by JavaScript in the browser, the browser cannot yield until it has finished.
• One giant component. A carousel, map or configurator written as a single large client component re-renders far more than the change requires.
• The same tag manager. A container stuffed with tags behaves identically on any framework, and each tag brings its own listeners and timers.

No framework can make a tag manager polite.

The fixes are known: keep components on the server by default and push the use client directive down to the leaves, mark non-urgent updates as transitions so React can keep the page responsive, break long work into chunks that yield to the main thread, and load third parties late or not at all. The difference from WordPress is not that Next.js teams never make these mistakes. It is that the mistakes live in one codebase, where a review can find them.

An INP tune-up you can run on WordPress this week

INP is often the most fixable vital on WordPress, because the cause is usually a short list of scripts. The JavaScript errors troubleshooting guide helps when a script is broken rather than slow.

1. 1

   Find the slow interactions

   Check the INP figures in Search Console and the field data in PageSpeed Insights. A standard Lighthouse page-load run cannot measure INP, since no one taps anything.

2. 2

   Reproduce on a slow device

   Open Chrome DevTools, throttle the CPU and use the Performance panel while you tap the menu, the forms and the filters. Tap during load as well, as Google suggests.

3. 3

   Name every script's owner

   List the scripts on a key page and match each to a plugin, the theme, the builder or a tag. Unknown scripts are the first suspects.

4. 4

   Unload what the page does not use

   Stop form, slider and gallery scripts loading on pages without forms, sliders or galleries.

5. 5

   Replace the heavy hitters

   Swap the slider for a static image. Load the chat widget only when someone clicks a lightweight chat button.

6. 6

   Prune the tag manager

   Remove tags nobody reads, and fire the rest on specific pages and triggers, not every click.

7. 7

   Retest the menus on a real phone

   After any combining or deferring, open and close every menu on an actual phone before calling it done.

For a ranked view of lean starting points, see the themes with the least CSS and JavaScript. If you would rather we did the digging, our theme speed optimization service covers INP along with the other vitals.

Responsiveness as a property of the build

On WordPress, responsiveness is negotiated between every vendor whose script is on the page, and renegotiated after each update. On the sites we build, the interactive pieces are components written by one team, and editors working in Athena CMS change words, images and listings without adding a single script. Apollo reads every page and says what to fix first, and Argus flags slow pages after changes.

One honest warning: if your INP fails because of a tag manager or a chat vendor, a rebuild alone will not fix it. You would need to cut the tags on either stack. Our performance consulting will tell you which case you are in. The sibling pages cover WordPress vs Next.js for LCP and WordPress vs Next.js for CLS, and the comparison hub has the full argument. If a move makes sense, the Next.js rebuild keeps your URLs and redirects every old one.