WordPress Interactivity API: What It Means for Plugin Performance

A recurring pattern shows up in Rank Math’s support queue: someone installs three or four plugins, each one perfectly reasonable on its own, and the site slows to a crawl. Open the network panel and you’ll often find the same root cause repeated — every plugin shipped its own copy of a JavaScript framework just to do something as simple as toggle a menu or filter a product grid. The WordPress Interactivity API was built specifically to stop that pattern from being necessary. Two years after it landed in core, it’s worth asking whether it actually has.

What It Is, in Plain Terms

The Interactivity API lets blocks add client-side behavior declaratively, through directives written straight into markup — things like data-wp-on--click, data-wp-bind, and data-wp-context — instead of hand-rolled JavaScript wiring up event listeners after the page loads. A single shared runtime, already loaded by WordPress core, reads those directives and handles the interactivity. It started as an experimental plugin in 2022, became an official proposal in March 2023, shipped as a private API restricted to core blocks in WordPress 6.4, and was finally made public for any developer to use with WordPress 6.5, released April 2, 2024.

Why the “Shared Runtime” Detail Is the Actual Performance Story

The headline feature isn’t really the directive syntax — it’s that plugins and blocks can now depend on one runtime that’s already present, instead of each one bundling and loading React, jQuery, or a custom solution independently. Only the specific region of the page tied to a directive re-renders when something changes; a paginated product grid or a live search box updates in place, without a full page reload and without shipping a second copy of a framework the page already has loaded for something else. WordPress.com framed this well when the API shipped, describing it — in an April 17, 2024 post — as a way to make what they called “43% of the web,” their shorthand for WordPress’s share of all websites, more dynamic without the weight of a full JavaScript framework bolted onto every plugin that wants interactivity.

Where Core Already Leans On It

This isn’t a demo-only feature. Several of the block types shipped and used by default in WordPress core already run on Interactivity API directives:

• The Search block, for live query updates.
• The Query block, for pagination and filtering without a full reload.
• The Navigation block, for menu interactions.
• The File block, for interactive behaviors around file display.

Any theme built on these blocks inherits that interactivity for free — the theme author doesn’t have to write custom JavaScript to get it, and the site doesn’t accumulate a separate framework bundle just because it uses a search box or a filtered archive.

What It Doesn’t Fix Automatically

Adoption is opt-in for plugin developers, and nothing forces existing plugins to migrate off jQuery or bundled React just because a better shared option now exists in core. A large share of the plugin ecosystem — including some of the most widely installed tools tied to legacy commerce, forms, and page-builder functionality — represents years of accumulated technical debt that isn’t going to move overnight, if it moves at all. Expect the transition to be gradual and uneven for a long stretch. Visiting a random WordPress site today shouldn’t feel meaningfully different because of this API existing; the gains show up in aggregate, as more of the plugin ecosystem opts in, not as a switch flipped on release day. Development hasn’t stopped either — WordPress’s own Gutenberg Times newsletter has continued tracking changes and refinements to the API well into 2026, which is a reasonable signal that this is treated as core infrastructure rather than a shipped-and-forgotten feature.

What I’d Actually Check as a Site Owner

When a plugin markets itself as “built for the block editor” or “modern,” that phrase covers both plugins genuinely using the Interactivity API and plugins that are just bundling React alongside the jQuery WordPress already loads — both get marketed the same way. The real signal is checking a page’s enqueued scripts for a shared @wordpress/interactivity handle versus a separate, plugin-specific framework bundle loading on top of it. It’s a five-minute check in the browser’s network panel, and on a site running several “modern” plugins, it’s often the fastest way to find out which one is actually adding weight.

The Interactivity API doesn’t make WordPress faster by adding a framework — it makes WordPress faster by finally giving the ecosystem one to agree on and share.

Treat this less like a feature that’s already delivered its performance win and more like a criterion worth adding to how you evaluate plugins over the next few years. The API is real, core already depends on it, and the direction is clearly toward less duplicated JavaScript weight — but the payoff is a slow accumulation across the ecosystem, not something you can point to on any single site today and call finished.