Aggregates Javascript files to a footer and header file.
| Author: | EdwardBock (profile at wordpress.org) |
| WordPress version required: | 4.8 |
| WordPress version tested: | 7.0.2 |
| Plugin version: | 2.2.0 |
| Added to WordPress repository: | 05-06-2015 |
| Last updated: | 04-08-2026 |
| Rating, %: | 0 |
| Rated by: | 0 |
| Plugin URI: | |
| Total downloads: | 3 109 |
| Active installs: | 10+ |
 Click to start download |
|
This plugin has reached the end of its life and receives no further updates. Please deactivate and delete it.
It aggregated a site’s local JavaScript files into one header and one footer request, back when the number of requests was what made a page slow. That has not been true for years, and on a current WordPress the plugin now does more harm than good.
Why it is being retired
HTTP/2 removed the reason it existed. Bundling files was a way around HTTP/1.1, which opened a new connection per file. HTTP/2 and HTTP/3 send many files over one connection, so a handful of separate scripts costs next to nothing – while one big bundle has to be re-downloaded in full whenever any part of it changes.
WordPress does the job itself now. Since 6.3 a script can be registered with defer or async (wp_script_add_data( $handle, 'strategy', 'defer' )), which is a better answer to blocking scripts than merging them. Since 6.5 there are script modules, a separate registry this plugin never touched at all – so on a modern block theme part of the JavaScript was never aggregated in the first place.
And it breaks pages. Measured on WordPress 7.0.2 with version 2.1.2:
- Anything added with
wp_add_inline_script()is silently dropped. Bothbeforeandaftercode disappear. WordPress itself and a great many plugins pass configuration to their scripts this way, so this can leave a page with script files that never get their settings. -
A
deferorasyncstrategy is lost. Scripts that were meant not to block rendering end up inside a bundle that does.wp_localize_script() data survives – the plugin re-renders it itself – which is why the damage is not always obvious.
What to do instead
Deactivate and delete the plugin. Nothing needs to replace it: WordPress serves the individual files again, which is the right thing over HTTP/2. If single scripts block rendering, register them with a defer strategy.
The aggregated files the plugin wrote are left behind on purpose so nothing breaks mid-request. They can be deleted afterwards – by default in wp-content/uploads/aggregated/, or in your theme directory if that was configured under Settings › Aggregator.