Document which parts of the module are still relevant after aggregation changes in 10.1.0

Last test run was on Jan 2, against 10.0: https://www.drupal.org/pift-ci-job/2557734 → .

Let's see how this works on 10.1.

Commenting as a fellow contrib module maintainer that was also affected by the changes in Drupal 10.1 (see 📌 10.1.x compatibility: tests are failing against Drupal 10.1.x due to upstream changes Fixed ) … I think there's some pretty happy news here actually: I think the advagg module is obsolete for >90% of sites using it in Drupal 10.1! 🤯

Most sites installed it to gain the following capabilities on top of what Drupal 7, 8, 9 and 10.0 provided:

1. on-demand generating of aggregates, to avoid costly stampede effects
2. JS minification, because A) there tend to be MANY more JS bytes than CSS bytes, B) core had NO JS minifier until 10.1, C) core has had a suboptimal but effective (i.e. fast but more bytes could be stripped in theory) CSS minifier

Since Drupal 10.1, these 2 prime needs/use cases are already addressed out of the box by Drupal core!

Remaining use cases where you still need the contrib module:

1. You are using advagg_bundler, which is a VERY advanced use case where you want to control the number of aggregates: https://git.drupalcode.org/project/advagg/-/tree/6.0.x/advagg_bundler
2. You really want to save every possible byte of CSS, which is why you'd want CSSmin and use https://git.drupalcode.org/project/advagg/-/blob/6.0.x/advagg_css_minify... — may happen at a later time for Drupal core: 📌 Consider adopting a third party CSS minification library Active
3. You disagree with Drupal core's use of Peast and would prefer another minifier and hence use https://git.drupalcode.org/project/advagg/-/blob/6.0.x/advagg_js_minify/... or https://git.drupalcode.org/project/advagg/-/blob/5.0.x/advagg_ext_minify...
4. You are SUPER advanced and use https://git.drupalcode.org/project/advagg/-/blob/6.0.x/advagg_mod/advagg...
5. You have once experienced broken CSS/JS (should be impossible with Drupal core) and want to validate every aggregated CSS/JS file using https://git.drupalcode.org/project/advagg/-/blob/6.0.x/advagg_validator/...

pretty sure there are other use cases for advagg still. Unless I'm mistaken to that stand out are

6. prefetch support
7. asset debugging

Added a core issue for prefetch ✨ Support prefetch/preload/dns-prefetch in the libraries API Active .

I met @NickDickinsonWilde at DrupalCon, he's looking forward to simplifying this module thanks to the changes in Drupal 10.1! 😊😄

As D10.1 has now been released, what is the status with this module?

Can I use 10.1.x with this module, will things work, or will advagg not work at all?

@KlemenDEV you should uninstall advagg as part of updating to Drupal 10.1.0 - even if it works with 10.1.0, there are advantages to core's new aggregation system which aren't in advagg (like the new URL structure, less database-heavy etc). advagg will then need to be reworked on top of 10.1.0 which should result in a much smaller, more targeted module doing only a couple of things.

Yeah this is a large priority to me, but unfortunately not a /work/ priority so not going to happen this week. But I'm extremely keen on the changes in core and it is gonna be great.

Is it enough to disable JS compression, or do I need to disable bundler and other modules too?

@klemenDEV I would uninstall everything, and then if you find you're missing something, carefully re-enable one by one, but more likely you'll be fine with core aggregation in 10.1.0 for a while and then can check in on progress here.

@NickDickinsonWilde would you be up for putting a note on the project page saying 10.1.x compatibility coming soon but consider uninstalling for now or similar?

@klemenDEV Yeah definitely disable bundler especially I would say. Really I'd disable everything - or feel free to test and report. But big changes need to be made.

@catch already did that this morning "Note: AdvAgg needs a major rework for Drupal 10.1 - recommend holding update or disabling AdvAgg until a new release comes out." Good enough or would you like different wording?

@NickDickinsonWilde ah no that's good I just hadn't checked the project page today, maybe a link to this issue? But otherwise that's plenty.

Any news on this topic?

regarding the listed remaining use cases in #7 - great summary!

for us, the advagg_mod functionality, especially the possibility of defer CSS loading, would be very important. I'm hesitating now, if I should update existing projects or starting new ones still on 10.x

To give feedback, I think use case 1. from #7 is also quite important and may not be that advanced use case. Most websites using HTTP2 benefit from using the bundler submodule to be able to set the number of aggregates to a big number to leverage parallel downloads.

@agoradesign it might be worth checking out 🐛 JavaScript aggregation should account for "async" and "defer" attributes Needs work and see whether you can apply the patch for that (and hopefully contribute to it being added to Drupal core for 10.2).

feel free to test and report

We disabled advagg's JS minifier and tested if the other functionnalities we are using still work:

• Defer CSS: does nothing because regexp is broken (see 🐛 css_defer setting broken with Drupal 10.1 Needs review )
• Advagg bundler: it seems to work as expected (generates the number of bundles we asked for)
• DNS prefetch: it seems to work correctly (the link tag is inserted in head)

Thanks for the tests @prudloff. So bundler seems to work even if "Enable advanced aggregation" is not enabled?

Yes, bundler works and generates X bundles that are loaded with the new core aggregation.

Thanks for the info @prudloff. I guess bundler could then be its own module in the future.

Btw is there any new progress on the plans for the advagg as a whole?

To clarify on #25, bundler does not work if advagg is disabled, meaning all advagg logic will need to run in order to use bundler right now

Is there any point in marking 6.0.x-dev as compatible with Drupal 10.1.x?

I can imagine people upgrading their sites going through the upgrade status recommendations and upgrading this blindly to the admittedly alpha version thinking it will not break their site. They would be in for a surprise when deploying such an upgraded site.

If on the other hand disabling features as outline in #23 makes the upgrade "safe", then this could go into a hook_upgrade_10100

Another use case I had for this module is to serve static Brotli compressed CSS and JS assets. It meant smaller files to transfer that are faster to decompress.

I hope core will introduce this soon (with support for static br and gz duplicates of svg images too).

Help is welcome on ✨ Support brotli compression of assets Needs work .

@NickDickinsonWilde: would it also be possible to add a note about Drupal 10.1 that is shown in Upgrade Status? I only found out about the compatibility issues after doing a test upgrade and I guess I will be the only one that follows the upgrade instructions → who will find out.

Maybe it can be a simple note in the Plan column like Quicklink has.

Regarding Bundler: it also looks like the Target Number Of CSS/JS Bundles Per Page setting stopped working correctly. I am getting less bundles, but more than the target number.

• CSS: I get 8 bundles with setting 3, and 6 bundles with setting 2.
• JS: I get 1 bundle more than the configured value.

@prudloff, do you have any update regarding different hashes on AssetControllerBase::deliver? I think I'm having the same issue. We use Cloudfront for caching website and JS assets can't be cached due to Cachecontrol: private, no-store headers.

@marcin-maruszewski We are still using 6.0.0-alpha1 with Enable advanced aggregation disabled and everything seems to work as expected.

Just a note that there are some upcoming core issues that are also likely to make the bundler less useful, although not ready yet by any means.
📌 Refactor system/base library Needs work
📌 Use placeholdering for more elements to optimize asset serving Needs work
✨ Allow CSS to be added at end of page Active

If and when those issues land, some CSS files will be rendered alongside the HTML placeholders they're #attached to (as already happens with Big Pipe) instead of as part of the main aggregate, and more content on pages will be rendered via placeholders so this will happen more often.

This will result in page-level CSS being rendered in aggregate in the HTML head, then smaller aggregates being served later on - resulting in more files overall. It should also lead to CSS that only affects content below-the-fold being rendered below the fold too, reducing render blocking time before LCP, although a fair bit of work to do before that's all testable.