Script Loader: Disable script and style concatenation by default

[haqadn]

Trac ticket: https://core.trac.wordpress.org/ticket/57548

Flips the fallback in script_concat_settings() so an undefined CONCATENATE_SCRIPTS resolves to false instead of true. load-scripts.php and load-styles.php become opt-in — sites that want the current behaviour can define( 'CONCATENATE_SCRIPTS', true ).

Scope is narrower than the constant's name suggests. The guard immediately below already forces the global to false outside of is_admin() and login_init, so only wp-admin and the login screen change. The concatenation code paths themselves are untouched.

Two reasons to make this the default:

• Concatenation is the root of a class of bugs that only appear when it is on. SCRIPT_DEBUG being ignored (#52879), translations not printing for concatenated handles (#50999), and "use strict" leaking between bundled scripts (#65515) are all conditions a stock install currently ships into. Defaulting off takes wp-admin off that path.
• It is what makes Script Loader: Prefetch the admin's unconcatenated assets from the login screen #13084 do anything. That PR warms the admin's individual assets from the login screen, but gates on concatenation being off. Under today's default it is inert on a stock install; with this flip it applies by default, which is the pairing the two changes were intended to have.

The cold-cache performance trade-off is the open question here, and the benchmark numbers and the compression-dictionary discussion belong on the ticket rather than in this diff. Opening as a draft for that reason.

Notes about TinyMCE

This slightly changes TinyMCE's concatenation behaviour too, through a different mechanism than the rest of this ticket. TinyMCE's bundle isn't produced by load-scripts.php — it's a static file built at release time. Concatenation only decides whether that prebuilt bundle is registered, or two separate files are.

So with concatenation off, the bundled file stops loading, and TinyMCE core and the compat3x plugin load separately instead.

That sounds like a tiny loss until you look at what the bundle holds: 24 concatenated sources — core, the modern theme, and 22 editor plugins — of which only two are ever requested on a real admin screen. Measured on Add Post with a cold cache, concatenation on gives one request and off gives two, with none of the 22 plugins fetched either way. Loading TinyMCE isn't the same as initialising it, and the block editor doesn't initialise it until a Classic block is present.

The concatenation is effectively bundling two files, and shipping 22 unused ones to do it:

	Requests	Bytes
Concatenation on	1	671 KB
Concatenation off	2	369 KB

~295 KB less on first load.

Testing instructions

1. Use an install with neither CONCATENATE_SCRIPTS nor SCRIPT_DEBUG defined in wp-config.php.
2. Load any wp-admin screen (the Dashboard is fine) and view source. There should be no requests to load-scripts.php or load-styles.php — every handle appears as its own <script src> or <link href>.
3. Confirm the admin behaves normally: menus, the list tables, and the block editor should all load without console errors.
4. Add define( 'CONCATENATE_SCRIPTS', true ); to wp-config.php and reload the same screen. Both load-scripts.php and load-styles.php should reappear, confirming the opt-in path still works.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Making the change, running the test suite and confirming the pre-existing failures against baseline, and drafting this description. Reviewed by me.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.