This issue is to explore if the same issue as described in Stampedes and cold cache performance issues with css/js aggregation exists in Backdrop, and if we could benefit by implementing the same/equivalent changes.
Problem/Motivation
Our current logic for building CSS and Javascript aggregates relies on creating the aggregates from within the page being requested, this leads to a number of issues:
When there are no aggregates on disk, the page response has to create the files on disk before it can be served. This adds hundreds of millisecond or seconds to uncached page requests. Additionally, each aggregate is created in sequence. So if you have 30 requests in a second, and the pages they're requesting have the same ten aggregates on, each individual aggregate needs to be created, one by one, before any of those 30 pages can actually serve any HTML at all. This can take hundreds of milliseconds or seconds, which can lead to 503s on cache clears.
Filenames have to be tracked in state - this means additional queries (and sometimes writing back to state) on every HTML request. When this issue was originally opened, filenames were tracked in variables which was a much bigger issue, now it's a minor one, but still adds to general post-cache-clear churn.
Because it's expensive already, it makes it difficult to add on-the-fly js minification and similar, since that would further degrade cold cache performance.
...
Before
- HTML request.
- Check if the file exists on disk
- Build the aggregate and write it back to disk if it doesn't, link from the head tag.
- Back to step 2 for each CSS and JS aggregate potentially a dozen times.
- Serve the HTML page to the browser.
- Browser requests files that already exist on disk.
After
- HTML request
- Generate just a filename as part of the head tag (no filesystem access, no writes to database)
- Serve the HTML page to the browser.
- Browser requests the asset URLs. If they don't exist, they're created and served from PHP. If they do they're served from the filesystem. This allows multiple aggregates to be generated simultaneously by separate HTTP requests, all without blocking any HTML being served.
Recent comments
Ruby Text can be a bit of a hassle to edit... Yes, I can imagine that. No idea, how an editor dialog (or whatever) for easier editing of those should look like - in terms of...
Specific tags to work in CKEditor 5
"why are these tags only relevant for admins?" I'm allowing the editor as well. That being said, Ruby Text can be a bit of a hassle to edit... easy to accidentally delete a tag or part of a...
Specific tags to work in CKEditor 5
Out of curiosity: why are these tags only relevant for admins? Don't "regular" editors on that site also need them under circumstances? Yes, the editors play nicely, no problem to...
Specific tags to work in CKEditor 5