Drupal 8 now has page caching enabled by default

After more than a year and probably hundreds of patches, yesterday it finally happened! As of 13:11:56 CET, April 8, 2015, Drupal 8 officially has page caching enabled by default!¹ And not the same page caching as in Drupal 7: this page cache is instantly updated when something is changed.

The hundreds of patches can be summarized very simply: cache tags, cache tags, cache tags. Slightly less simple: cacheability metadata is of vital importance in Drupal 8. Without it, we’d have to do the same as in Drupal 7: whenever content is created or a comment is posted, clear the entire page cache. Yes, that is as bad as it sounds! But without that metadata, it simply isn’t possible to do better.²

I’ve been working on this near-full time since the end of 2013 thanks to Acquia, but obviously I didn’t do this alone — so enormous thanks to all of you who helped!

This is arguably the biggest step yet to make Drupal Fast By Default. I hate slow sites with a passion, so you can probably see why I personally see this as a big victory :)

(One could argue you could just enable Drupal 7’s page cache, but there are 3 reasons why this is inferior to Drupal 8’s page cache: a) no instantaneous updates; b) any node or comment posted causes the entire page cache to be cleared (!), c) it’s not enabled by default: many users don’t know they should enable this. Sure, you can get similar performance, but you’ll have to give up certain things, which makes it an apples vs. oranges comparison.)

Benchmark

By default, Drupal 8 is now between 2 and 200 times faster than Drupal 7 for anonymous users: Drupal 8 will respond in constant time, for Drupal 7 it depends on the complexity of the page.

On my machine (ab -c1 -n 1000, PHP 5.5.11, Intel Core i7 2.8 GHz laptop, warm caches):

Drupal 7

• Front-page: 18.5 ms/request (55 requests/s)
• node/1: 23.5 ms/request (43 requests/s)
• More complex pages: easily hundreds of milliseconds, only few requests per second.

Drupal 8

Always 6.5 ms/request (154 requests/s)³.

Easily tenfold that on actual servers

The above is tested with a concurrency of 1 client, to ignore web server performance (Apache in my case).

Rasmus Lerdorf — creator of the PHP language — also did some benchmarking, and he found that Drupal 8 was able to serve >2500 requests/second on his server, with 20 concurrent clients.

Win-win

The real beauty is that it’s a win-win: enterprise (Acquia), medium, small, tiny (hobbyist) all win:

• Enterprise sites get very nice reverse proxy/CDN-based hosting
• Tiny sites can easily serve 100 requests/second (>8 million requests/day) on shared hosting.

So my work was sponsored by Acquia, but benefits everyone!

People have been expressing concerns that Drupal 8 has become too complex, that it doesn’t care about site builders anymore, that it is only for enterprises, etc. I think this is a good counterexample.
Yes, we added the complexity of cacheability metadata, but that only affects developers — for whom we have good documentation. And most importantly: site builders reap the benefits: they don’t even have to think about this anymore. Manually clearing caches is a thing of the past starting with Drupal 8!

Page cache is just a built-in reverse proxy

Drupal’s page cache is just a built-in reverse proxy. It’s basically “poormansvarnish”.

Drupal 8 bubbles all cacheability metadata up along the render tree, just like JavaScript events bubble up along the DOM tree. When it reaches the tree’s root, it also bubbles up to the response level, in the form of the X-Drupal-Cache-Tags header.

The page cache uses that header to know what cache tags it should be invalidated by. And because of that, other (“real”) reverse proxies can do exactly the same. The company behind Varnish even blogged about it. And CDNs are even starting to support this exact technique out of the box, for example Fastly.

Last but not least: all of Drupal 8’s integration tests use the page cache by default, which means all of our integration tests effectively verify that Drupal works correctly even if they’re behind a reverse proxy!

New possibilities for small sites (and shared hosting)

On one end of the spectrum, I see great shared hosting providers starting to offer Varnish even on their smallest plans. For example: Gandi offers Varnish on their €4/month plans. If users can configure Varnish — or even better, if they pre-configure Varnish to support Drupal 8’s cache tag-based invalidation — then almost all traffic will be handled by Varnish. (Update: see the official docs on how to use Varnish + cache tags.)

For 90% or more of all sites, this would quite simply be good enough: very cheap, very fast, very flexible.⁴

I can’t wait until we see the first hosting provider offering such awesome integration out of the box!

New possibilities for enterprise sites (and enterprise hosting)

On the other hand of the spectrum, enterprise hosting now gains the ability to invalidate (purge) all and only the affected pages on a CDN⁵. Without having to generate a list of URLs that a modified piece of content may appear on, and then purge those URLs. Without having to write lots of hooks to catch all the cases where said content is being modified.

At least equally important: it finally allows for caching content that previously was generated dynamically for every request, because it was a strong requirement that the information always be up-to-date⁶. With cache tag support, and strong guarantees that cache tags indeed are invalidated when necessary, such use cases now can cache the content and still be confident that updates will immediately propagate.

New possibilities for developers

Finally, the addition of cache tags and by extension, all render cacheability metadata (cache tags, contexts and max-age), allow for greater insight and tooling when analyzing hosting, infrastructure, performance and caching problems. Previously, you had to analyze/debug a lot of code to figure out why something that was cached was not being invalidated when appropriate by said code.

Because it’s now all standardized, we can build better tools — we can even automatically detect likely problems: suspiciously frequent cache tag invalidations, suspiciously many cache tags … (but also cache contexts that cause too many variations, too low or too high maximum ages …).

Next steps

Warm cache performance is now excellent, but only for anonymous users.

Next week, at Drupal Dev Days Montpellier, we’ll be working on improving Drupal 8’s cold cache performance (including bootstrap and routing performance). That will also help improve performance for authenticated users.

But we already have been working several weeks on improving performance for authenticated users. Together with the above, we should be able to outperform Drupal 7. This is the plan that Fabian Franz and I have been working towards:

1. smartly caching partial pages for all users (including authenticated users): d.o/node/2429617, which requires cache contexts to be correct
2. sending the dynamic, uncacheable parts of the page via a BigPipe-like mechanism: d.o/node/2429287