When aggregating CSS & JS assets, the grouping is hugely important. Drupal 8's current grouping algorithm is old, and often results in inefficient groups.
Paraphrasing from #977844-15: Remove the 'every_page' option for CSS/JS assets: it is confusing, even damaging:
Every single asset in Drupal 8 is now loaded through asset libraries. That also means we know about all dependencies. Which means we can build a dependency tree, and thus we can calculate which assets appear on every page, and put those in a separate group.
TBD
None.
None.
None.
Comments
Comment #2
catchComment #3
dawehnerI'm curious whether for example for this case, the calculation could be moved into a asynchron place, so by default return basically what we do know
but then also add for example a queue item, which then does the full calculation, which might be computational intensive.
Comment #4
wim leers#3: Yep, we should also explore that. But, it could be that it's cheap/fast enough to analyze the entire tree at once. IDK yet :) One of the few places in core where we can actually play/experiment with algorithms to find a good solution!
Comment #20
catchFor CSS, I was thinking about this issue, but then found #2989324: Allow CSS to be added at end of page by rendering assets with placeholders 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.
Comment #21
wim leers👍
Note that we already do this, and have been for over half a decade, in one case: BigPipe serving responses to no-JS clients.
Comment #22
ambient.impactI'm very interested in seeing how this works out because making aggregation work - especially for JavaScript - was a nightmare for RefreshLess 2.x: #3414538: Turbo: Implement additive JavaScript aggregation to prevent multiple evaluation
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.
Comment #23
catchWe 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 #3467860: Ensure consistent ordering when calculating library asset order. 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.
Comment #24
ambient.impact🤔🤔🤔 #3467860: Ensure consistent ordering when calculating library asset order 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.