Use the asset library dependency tree to improve CssCollectionGrouper & JsCollectionGrouper

For CSS, I was thinking about this issue, but then found ✨ Allow CSS to be added at end of page Active and I think that would help here - i.e. placeholdered content gets it's CSS asset links rendered alongside it, instead of collected and eventually rendered in the head.

That would give us less libraries rendered in the HTML head, meaning less render blocking CSS. We'd still want to optimize the grouping but the results would be very different.

👍

Note that we already do this, and have been for over half a decade, in one case: BigPipe serving responses to no-JS clients.

I'm very interested in seeing how this works out because making aggregation work - especially for JavaScript - was a nightmare for RefreshLess 2.x: 🐛 Turbo: JS aggregation causes the RefreshLess JavaScript to evaluate more and more times on navigation Active

This particular improvement might be less relevant to that project since it was more the additive part that had to be implemented, but anything core can do to make the library system even more predictable would be awesome.

Also, this makes me wonder if we get core to provide a list of all possible aggregates given the known dependency trees, could we then use that as part of a post-deploy process to proactively/preemptively build all those aggregates? That would be awesome from a performance point of view.

Also, this makes me wonder if we get core to provide a list of all possible aggregates given the known dependency trees, could we then use that as part of a post-deploy process to proactively/preemptively build all those aggregates?

We can get all the libraries. Then calculate every possible combination of libraries and pass it into AssetResolver. Aggregation will already normalize the list to the minimal representative set and calculate the resulting aggregate, so if 50 combinations of libraries result in the same actual libraries loaded due to dependencies, you'd still only get one aggregate. At least since 🐛 Logic error in Drupal's lazy load for asset aggregation Active . However there will still be more or less impossible combinations of libraries (a slider for the front page + views_ui or similar). There are some other options to improve performance like using FileCache for individual file optimization, and maybe bringing back the stale aggregate file threshold (at least on production) to leave files on disk for 30 days across cache clears - we used to do that prior to the recent changes because it was required, now it's not required but it might still be good.

🤔🤔🤔 🐛 Logic error in Drupal's lazy load for asset aggregation Active will definitely be helpful for this. Will have to experiment with 10.4 when I get a chance.

I have mixed feelings about the stale file threshold: I can see it being useful for some smaller sites and it would be nice to have cache clears not wipe out aggregates, but on the other hand, I feel like it's treating a symptom and not the root cause; the root cause usually being that it's the tool someone reaches for when they don't know how to use update hooks, the Cache API (tag invalidation, etc.), or the appropriate service to clear/rebuild a specific thing they need. That's specifically why I created the Rebuilder module → , which can rebuild just aggregated assets among several other things.