Stop concatenating scripts and stylesheets in wp-admin and retire load-scripts.php and load-styles.php

And I will add that this proposal will reduce the attack perimeter in terms of WordPress security.

Many security plugins propose to reinforce the parameters of calls to these 2 URLs, because possible source of DDOS attack.

I think this is worth pursuing. Once we have a working solution, we should gather some performance comparisons to make a comparison between the two approaches.

The current implementation (in WordPress 6.3) is currently causing the asset generation and concatenation to fail with an HTTP 503 error if less than 1.5 Gb RAM is assigned to the site. See ​https://github.com/WordPress/gutenberg/issues/54294 for fuller details.

Update from the hosting company: the peak RAM required for this process is 1.9 Gb.

The use of script concatenation just came up again in #63887. See comment. If we can get rid of script minification, it would make things easier for that other ticket while also removing technical debt.

Replying to markhowellsmead:

The current implementation (in WordPress 6.3) is currently causing the asset generation and concatenation to fail with an HTTP 503 error if less than 1.5 Gb RAM is assigned to the site. See ​https://github.com/WordPress/gutenberg/issues/54294 for fuller details.

#47322 is a ticket with a simple patch that likely reduces peak memory usage for wp-admin/load-styles.php.

My understanding is that there are still benefits from concatenation with HTTP/2, particularly on servers configured with compression.

While it is true that assets can be downloaded in parallel, each file will have it's own compression dictionary. For example, each CSS file will have entries for color, background, font, font-size, etc.

By concatenating the requests WordPress is reducing the number of dictionaries that need to be transferred across the wire. Harry Roberts documents the results in a post on ​HTTP performance.

Rather than rely on instinct, it would be good to get some data on the benefits for common screens: the dashboard, the post list, the post editor.

As WP is all-or-nothing at the moment with concatenation, another comparison point is to check limiting the number of script in a single concatenated request to N files.

@peterwilsoncc We should test this indeed.

You're referring to transferring dictionaries, but Compression Dictionaries aren't implemented by load-scripts.php, right? Also, I don't see that there is even any compression at all (e.g. GZip). Maybe I'm not seeing something.

The additional latency required to boot up PHP to concatenate the scripts should be considered as well. Serving static files would be a much faster TTFB.

We can get some additional benefits by preloading key scripts and styles used on in the editor when the user lands on the dashboard, for example.

Replying to westonruter:

@peterwilsoncc We should test this indeed.

You're referring to transferring dictionaries, but Compression Dictionaries aren't implemented by load-scripts.php, right? Also, I don't see that there is even any compression at all (e.g. GZip). Maybe I'm not seeing something.

Yes, that's what I'm referring to.

WordPress doesn't do anything, I'm thinking of the compression modules used by web servers & CDNs.

On the two sites I can readily use live servers to run experiments with, adding define( 'CONCATENATE_SCRIPTS', true ); increased the transfer size of the CSS while the JS dropped a little.

I shared this ticket with some trusted performance folks @sergiomdgomes and @josephscott, I'll summarize their feedback here.

Most results seem to indicate that concatenation remains beneficial in general. It hasn't been made obsolete by HTTP/2.

A few additional links discussing the topic:

• ​Forgo JS packaging? Not so fast
• ​Browser module loading - can we stop bundling yet?

​There's also "tight mode" discussed in this talk around 11 minutes:

Chrome loads resources in 2 phases. “Tight mode” is the initial phase and constrains loading lower-priority resources until the body is attached to the document (essentially, after all blocking scripts in the head have been executed). In tight mode, low priority resources are only loaded if there are less than 2 in-flight requests at the time that they are discovered.

It seems conclusive that concatenation is usually better for performance. Does anyone have evidence to the contrary?

To move this forward, a different case needs to be made because it doesn't seem like "no performance benefit from concatenation" is valid.

Do the benefits of not concatenating outweigs the drawbacks of degraded performance. Or in the contexts where concatenation is used (like the customizer view) is degraded performance irrelevant? Or is concatenation so buggy that it doesn't make sense to support it?

Thank you, @jonsurrell!

Sorry for not joining the discussion earlier, but I'd like to add a few comments inline now that I'm here :)

Browser module loading - can we stop bundling yet?

I just wanted to add a note that my article is really old, and most of the findings may no longer apply. Still, it mentions the sort of issues one can reasonably expect.

In general, I haven't seen conclusive evidence that concatenation no longer has a benefit.

As @peterwilsoncc mentions, the "small files" compression problem is still relevant, and there isn't a cross-browser solution to address it. Even though WordPress doesn't handle compression itself (whether gzip or brotli), the expectation is that a competent host will enable it at the HTTP server level, and that it will have a meaningful impact on performance, so it's something we do need to consider.

The additional latency required to boot up PHP to concatenate the scripts should be considered as well. Serving static files would be a much faster TTFB.

This would be good to test, but we have to remember that the WordPress ecosystem is extremely heterogenous, and it's difficult to make broad assertions that are valid everywhere.

In this case, since we're thinking outside of WordPress and at the level of serving infrastructure, we have to consider the impact of edge caches as well. It's reasonable to assume that the concatenated files would also be edge cached, potentially negating the effect of any boot-up cost in concatenation at scale.

We can get some additional benefits by preloading key scripts and styles used on in the editor when the user lands on the dashboard, for example.

Preloading is a rather forceful technique that should be used with extreme caution, as it has the potential to make things worse. It's generally preferable to leave prioritisation to the browser, and at most provide hints in the form of fetchpriority or by rearranging things so that the resource is discovered earlier.

In any case, if there is any benefit to be had here, it may be worth exploring independently of concatenation.

Don't get me wrong, there are definitely some downsides to concatenation. Beyond the security issues mentioned, it makes debugging harder, and it can worsen problems with scripts, in that script-breaking bugs now break all the concatenated scripts, not just the one script.

But in terms of performance, the evidence I've seen so far is that there's still an improvement.

With 6.9 beta 1 happening in ~2 weeks and this ticket still be discussed, I am going to move this to Future Release.

Related: #58302 (Deprecate and disable the unused compression_test() and wp_ajax_wp_compression_test())

Milestoning for 7.0 to investigate further.