Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Drupal 8 can concatenate assets like CSS and JS. This can greatly reduce the amount of HTTP request. But with HTTP2 the overhead of an HTTP request is now very low and concatenation seem useless and can degrade performances.
Perhaps the first step would be to create a notice in admin/reports/status if you a in HTTP2 and use bandwidth optimization for assets.
There is a lot to explore like server push and content prioritization. Peoples have to understand that HTTP2 turn best practices upside down.
Comments
Comment #2
nod_We need to check some data first. While theory is great, we can't dismiss real life :)
We have a lot of files (like 50+ js files for admin users). Also for CSS when not aggregated we use
@import
which had (and probably still has) it's own performance problems so we'd need to change that too.Comment #3
gagarine CreditAttribution: gagarine as a volunteer commentedI Agree of course we have to do real test.
If I remember right the "@import" was because of an old version of IE that has some kind of limit with the numbers of included files.
EDIT: yep that's it https://support.microsoft.com/en-us/help/262161/a-webpage-that-uses-css-... not sure it still applied to more recent version of IE.
Comment #4
Wim LeersAt the moment, this is not remotely true yet, sadly. Plenty of evidence around that shows that fetching dozens of CSS or JS files via HTTP/2 is still slower than aggregating them into a few…
Comment #17
catchMoving to needs more info. There's also the issue that aggregation and minification are linked.
On top of this, the sheer number of elements that CSS and JavaScript would add to a page would increase the amount of HTML to download and parse - it could be hundreds.
I think we'd be better off looking at #2554051: Use the asset library dependency tree to improve CssCollectionGrouper & JsCollectionGrouper and revisiting this only after that issue is resolved.
Comment #18
Wim Leers+1!
The general advice on the web as well as 99% of articles on this subject do not apply to Drupal, because Drupal is extremely modular, with each Drupal module able to add 1 or more CSS/JS files, and potentially hundreds of installed modules… resulting in indeed hundreds of CSS or JS files, with each one tiny.
I have yet to see any data at all on how hundreds of tiny CSS/JS files would impact front-end performance on HTTP/2.
But given that each even for far fewer and far larger files, it wasn’t even feasible stopping bundling and relying entirely on H2 until at least a few years ago, it seems unlikely the increase in overhead could ever be sufficiently compensated 😅
(The only way that could IMHO conceivably happen is if at least we let asset-library-level bundling. That would then also result in a nice simplification of the asset handling logic. But … on its own that’s probably not worth it either. And it likely still results in a performance regression.)
Comment #19
KlemenDEV CreditAttribution: KlemenDEV as a volunteer and at Pylo commentedThere is the ADVAGG bunder module where one can set a number of files it is aggregated to, meaning one can set it to eg. 15 files which is good trade-off for HTTP2. I think something similar in core would be very beneficial.