Solving Lighthouse's inefficient cache policy warning on Drupal websites

Solving Lighthouse's inefficient cache policy warning on Drupal websites

While working to improve the performance of my website, I have been using Google's Lighthouse to audit the page performance and looking for quick wins. One that comes up frequently, and is easily solved, is improving the cache policy on static assets. When running Lighthouse against my Drupal site, I get the warning "Uses inefficient cache policy on static assets". This will always occur on a Drupal site, but is really easy to improve the site performance to fix this:

For just a single page, there's 24 assets that have an inefficient cache policy. The Lighthouse warning here is about these files. It's reporting that the default Time To Live (TTL) on the generated static assets is only 2 weeks. If a file never changes, you want a long cache lifetime (TTL) so that the visitor's browser doesn't request assets it already has in chache.

Befoer fixing, you need to understand how Drupal manages and static assets. If you have the various performance settings and modules turned on, then it's most likely that you are trusting Drupal to determine which blocks and components will be on your page and concatenating them together to reduce the number of JS and CSS files. You likely have a cache folder in your /files/ directory that's full of static assets with indecipherable filenames, and when you flush Drupal's cache, these files get deleted. Drupal manages this by generating the file names using a hash based on the contents. It then inserts links to the combined hashed filenames instead of the original individual source files.

What this means, is that any particular hashed file is pretty much going to be unique, and never need to be regenerated for the same file name. If anything changes, the hash will change, and a new file is generated. The purpose of using new file names each time the cache contents change is so that any caching in the visitor's browser is skipped, and the new assets are loaded when new assets are needed. This is what prevents your visitors from loading a page with obsolete Javascript or stylesheets.

Since our hashed static assets are always going to be unique, they can support much longer TTLs than the Drupal default of 2 weeks. To up this to a better default, open your .htaccess file and find these lines:

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

2 weeks is fairly short for truly static assets. Comment out the lines so you remember the defaults in the future and immediately after, add these two lines:

  # Cache all files for 1 year after access
  ExpiresDefault "access plus 1 year"

This updates the cache lifetime for static assets to a full year instead of merely 2 weeks. If you find this is too long, play around with values until you land on what makes sense for your site and your frequency of asset generation. For me, this one line change dramatically improves the reported page performance since these assets never need to be reloaded after a visitor first hits the site.

This one small change reduced the reported number of warnings from 24 to only 4. The remaining assets on my list are from 3rd parties, so I'll come back to those later after addressing some other low-haging fruit, but for now, this is a significant preformance improvement for very little effort.


Add new comment