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.


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:

  1. 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.

  2. 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.

  3. 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.



  1. HTML request.
  2. Check if the file exists on disk
  3. Build the aggregate and write it back to disk if it doesn't, link from the head tag.
  4. Back to step 2 for each CSS and JS aggregate potentially a dozen times.
  5. Serve the HTML page to the browser.
  6. Browser requests files that already exist on disk.


  1. HTML request
  2. Generate just a filename as part of the head tag (no filesystem access, no writes to database)
  3. Serve the HTML page to the browser.
  4. 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.
GitHub Issue #: