Script Concatenation Is Being Removed From WordPress

Somewhere in most WordPress installs, a constant called CONCATENATE_SCRIPTS is quietly set to true, and almost nobody who runs a site knows it is there. The roadmap to WordPress 7.2, published 18 September 2026, lists “elimination of script/style concatenation in favor of prefetching” as a performance workstream for the release targeted at early December 2026.

Why concatenation existed at all

Concatenation was built for HTTP/1.1, where browsers opened a small number of connections per host and every additional file cost a round trip that could not overlap with the others. The WordPress admin loads a lot of small scripts and stylesheets. Bundling them into a single request through load-scripts.php and load-styles.php removed dozens of round trips from every admin page view, and at the time the win was real and easily measured.

That reasoning held for roughly a decade. It has not held for several years.

Why it stopped helping

HTTP/2 multiplexes requests over a single connection, so the request-count penalty concatenation existed to avoid largely disappeared. What remains is the cost concatenation always carried and nobody used to mind: a single bundle has a single cache entry, so changing one file in it invalidates all of them. Every WordPress update, and every plugin update that touches an enqueued asset, forces the browser to re-download the whole bundle rather than the one file that changed.

The bundle is also opaque to the browser’s own prioritisation. A browser can decide that one of thirty individual files matters more than the other twenty-nine and fetch it first. It cannot do that with a blob. Prefetching, which is what the roadmap names as the replacement, works the other way round: it keeps the files separate and moves the fetch earlier in time rather than merging the requests.

This is an admin change, not a front-end one

This is the part that gets misread. Core concatenation runs in the admin. CONCATENATE_SCRIPTS defaults to true, but concatenation is disabled outside wp-admin and when SCRIPT_DEBUG is enabled, which means the theme assets on your public pages were never being concatenated by core in the first place.

If your front end is serving one combined JavaScript file today, something other than core is doing it — a performance plugin, a build step, or a CDN feature. Removing core concatenation will not touch that, and the same reasoning applies to it. The relationship between plugin-level asset handling and real-world metrics is covered in more detail in what caching plugins move, and the pattern there is consistent: combining files is the setting most likely to have been left on because it was on by default.

How to check what your site is actually doing

The check takes a few minutes per site and does not require any tooling beyond a browser.

• Open an admin page with the network panel recording and filter for load-scripts.php. If it appears, core concatenation is active on that install.
• Grep wp-config.php for CONCATENATE_SCRIPTS, SCRIPT_DEBUG and COMPRESS_SCRIPTS. A host or a previous developer may already have set them.
• Load a front-end template and look for a combined asset with a hashed filename or a query string containing several handle names. That is plugin-level combination, not core.
• Record the current Largest Contentful Paint element and its resource timings before changing anything, using field data rather than a single lab run. The web.dev guide to optimising LCP sets out which sub-parts of that metric asset loading can actually move.

What to do before December

Measure first, then disable, then measure again — in that order, and on the front end and the admin separately, because they will not respond the same way. If front-end combination is being done by a plugin, turn it off on a staging clone and compare LCP and the resource waterfall over a real sample rather than one page load. On a site served over HTTP/2 or HTTP/3 with sensible cache headers, the combined build usually loses, but “usually” is not a result and your own numbers are.

Admin-side, the change is close to invisible to visitors and worth treating as a compatibility question instead of a performance one. Plugins that hook into the concatenation path, or that assume load-scripts.php exists, are the ones that will break, and the December release is the point at which you find out. Sites where this matters most are the ones described in where WordPress sites actually lose speed: large plugin counts, heavy admin screens, and an asset pipeline nobody has audited since it was set up. Test those on a beta rather than on a Tuesday in December, and keep the before-and-after numbers, because the absence of a regression is only provable if you wrote down what it was before. The LCP work in LCP optimisation is the more productive place to spend the same afternoon.