Problem/Motivation
Found in #3436527: Record total css and js file size in performance tests
Steps to reproduce
Install Umami. Visit the front page, then visit the 'articles' page.
The aggregate filename is the same, but the 'include' query parameter is different this is because one CSS-only library isn't attached on the articles page, so doesn't affect the file contents.
This is 'by design' in that the files should be identical when the libraries passed result in the same contents, but I wonder if we can improve edge caching but making the query parameter the same too.
This should have several benefits:
1. Browser and edge caches will get higher hit rates.
2. Slight reduction in Drupal page weight, for any HTML response.
3. Slight reduction in the request size from clients when they fetch the aggregates, since it's already small, this might be a higher percentage even if it's only a few bytes. Also often upstream bandwidth is a lot more constrained than downstream bandwidth.
Proposed resolution
When building JavaScript aggregate URLs, don't bother sending libraries with only CSS in them.
For CSS aggregate URLs, don't bother sending libraries with only JS in them.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 3437839-nr-bot.txt | 90 bytes | needs-review-queue-bot |
| #12 | 3437839-nr-bot.txt | 90 bytes | needs-review-queue-bot |
| #10 | 3437839-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3437839
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
catchPushed a commit, this is only a small change to AssetResolver, most of it is indentation changes because we can remove a condition in a later hunk.
Will see whether this requires any test changes.
Also realised we can do this in the opposite direction for CSS aggregates - remove the non-CSS libraries when building those URLs too,
Apart from the potential improvements to browser and edge caches, this also makes the URLs significantly shorter.
Before:
https://drupal-dev.ddev.site/sites/default/files/js/js_Xc0CqWop9HPDPJJr9o1ZfdcVQmp-Q9tMliiLOllT6-4.js?scope=footer&delta=0&language=en&theme=umami&include=eJx1j0sOwjAMRC9E2jM5jikW_lR2CiqnpyrqgkU2Xvg9jWZyz046V0i6bQrKMwpk7tP5QQ-azUNB-HMJi3gF-TF0Xd3Iek4nLKVxHgmsFCOjcxcawbt7pyhVHJ-3F9M75_NO6m2Tq0IQ8koFXYSws1uO8oKgFT3YSECI9r_cvA3tCmbjZTXAGtsy4o-jDMUXI82NiAAfter:
https://drupal-dev.ddev.site/sites/default/files/js/js_Xc0CqWop9HPDPJJr9o1ZfdcVQmp-Q9tMliiLOllT6-4.js?scope=footer&delta=0&language=en&theme=umami&include=eJxLzi9K1U_Ozy3Iz0vNKynWK81NzM3U1c1ITUxJLQIAqggLKQIt should also reduce the potential for differently ordered libraries to change the asset order.
Comment #4
catchComment #5
catchWe have implicit test coverage of this code in that the code path is tested, I think we can rely on #3436527: Record total css and js file size in performance tests to cover the performance/caching optimization, the newly added test in that issue is how I found this in the first place.
Comment #6
luke.leberRan against a page on a site with ~230 CSS-only component libs and ~5 JS-only libs, and ~10 CSS+JS libs.
Single page
Without MR Applied:
With MR Applied:
Delta:
Net: -.4kB
No clue why / how an extra 200 bytes of JS was delivered. That shouldn't have been possible. In theory, less variance means:
This improvement sounds good to me all around.
Note - I didn't review the code; just performed a basic sanity test against a highly customized 10.1.x site.
Comment #7
catchIt won't actually mean fewer Drupal bootstraps, because this doesn't change the number of files on disk, I'm working on that in #3437499: Use placeholdering for more blocks, which is how I indirectly found this. What it should (hopefully) do is instead of a many-to-one relationship of URLs to files, make it 1-1. Because of that, it will reduce the number of requests that fall through from the browser cache, CDN, or varnish, to the webserver itself.
Comment #8
catchhttps://git.drupalcode.org/project/drupal/-/merge_requests/7313 now has test coverage for this, showing that it saves one very large file download when browsing two different Umami pages as an authenticated user.
Before:
After:
Comment #9
catchRebased now that #3436527: Record total css and js file size in performance tests is in.
Comment #10
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #11
catchRebased.
Comment #12
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #13
catchRebased again.
Comment #14
thejimbirch commentedFollowing the validation steps, I can confirm the query parameter on the JavaScript file remains the same after the merge request had been applied.
Marking as RTBC for the validation steps. If it needs a code review, please switch it back to Needs review. Thanks!
Comment #15
alexpottCommitted 22707d5cd0 and pushed to 11.x. Thanks!
We need a 10.3.x MR...
Comment #18
catchOpened a 10.3 MR. We can backport this to 10.2.x too I think.
Comment #19
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #20
catchRebased. Green apart from a known failure in 10.3.x
Comment #21
catchThe backport only needed to update performance tests, so re-RTBCing.
Comment #22
alexpottCommitted 4dd78b9 and pushed to 10.3.x. Thanks!
Comment #24
alexpott