Your fastest Drupal experience ever: Drupal 8 Cache Tags and Varnish

Adding Varnish to a Drupal hosting stack can make things very fast but can also make them complicated. We will show you why Cache Tags are the key to accessing the power of Varnish for your fastest Drupal experience yet.

Photo by Scott Webb on Unsplash

Varnish provides extremely fast reverse proxy caching to Drupal by caching the whole HTML response of Drupal. Unfortunately cache purging possibilities weren’t that great, even though there were multiple approaches on how to purge the caches of Varnish none of them where a perfect solution. The options were:

  • Purge the whole varnish cache every time something is updated on the Drupal side. This is obviously not an efficient solution.

  • Trying to guess on which URLs a node was existing and purging these URLs in Varnish. This method means a lot of guesswork and leaves some URLs unpurged.

  • Having a very short Cache lifetime of just a couple of minutes. This solution does not provide performance we’d like.

Cache tags FTW!

Cache Tags are one of the key improvements of Drupal 8. They allow Drupal to know which entities are used during a page view. This means that Drupal saves the cache tags along with the data it caches. So if Drupal needs to clear the caches because one entity is updated (let’s assume node with ID 77), instead of clearing all caches, it can easily check which caches actually used node 77 and clear only those. (You can learn more about cache tags on drupal.org).


This system is completely automated and transparent to the users, editors, and developers but allows for unprecedented speed for Drupal sites.


Cache Tags & Varnish

Cache Tags are not only reserved for Drupal internals, they can also be exposed via HTTP Headers. This means they can also be consumed by Varnish. Varnish saves these headers together with the HTML response. The result is that Drupal just needs to tell Varnish when a change was done and Varnish can purge it’s internal cache by using these cache tags. This approach has several advantages:

  • Cache lifetimes are basically forever: as Drupal will tell Varnish about every single change, if there is no change then Varnish will never need to purge its cache.

  • Caches are immediately purged in Varnish for every single change within Drupal. This means no confused editors wondering why their changes don’t appear on the website.

  • Truly purging everything. Drupal no longer needs to guess where a specific node has been used on the website.


Varnish & Drupal 8 in Lagoon

As you can probably tell, we are very excited about Cache Tags and Varnish. We wanted to make sure that Lagoon supports this system right out of the box and to the fullest extent possible. We are excited to share the following:


  1. A dedicated documentation page on how Varnish and Drupal 8 is setup and how it works behind the scenes: http://lagoon.readthedocs.io/en/latest/using_lagoon/drupal/services/varnish/

  2. Full support for the Drupal Purge and Drupal Varnish Purge Module. No special Lagoon Module needed!

  3. Full capability to test your Varnish setup within your Local Docker Development environment.

  4. Full support for “Purge Late runtime processor” and “Varnish Bundled Purger”. This means that purge requests are sent to Varnish immediately and not during a cron job.

  5. Full support for “Varnish Ban Lurker” which allows Varnish to run automated cleanup tasks and keep the memory usage to a total minimum.


A big thank you to everybody in the Drupal Community that worked hard on the Cache Tags system and the maintainers of Drupal Purge and Drupal Varnish Purge for their awesome work and contributions!


Writer