performance

At least 20 people helped push one or more issues forward in Montpellier, at the Drupal Dev Days Performance Sprint!

Here’s an overview of what we set out to do, what we did, and what the next steps are.

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![^1] 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 :)

I’m working on making Drupal 8 faster as part of my job at Acquia. The focus has been on render caching¹², which implies that cacheability metadata is of vital importance in Drupal 8.

To be able to render cache all things that can possibly be render cached, Drupal 8 code must:

• set the right cache max-age — to ensure only the cacheable parts of the page are cached
• set the right cache contexts — to ensure content is varied as expected (per language, per role, per timezone, per user …)
• set the right cache tags — to ensure rendered content is invalidated when the data it depends on is modified

Before Drupal 8, approximately zero attention was given to cacheability of the rendered content: everything seen on a Drupal 7 page is rendered dynamically, with only the occasional exception.

By flipping that around, we make developers more conscious about the output they’re generating, and how much time it takes to generate that output. This in turn allows Drupal 8 to automatically apply powerful performance optimizations, such as:

This year, Performance Planet did an advent calendar again, just like the last few years. I also contributed an article — what follows is a verbatim copy of my “The real challenge: making the entire web fast” article for the 2013 Performance Calendar.

Probably many — if not most — of us speed freaks work for big companies that are optimizing top 1,000 websites.
Some companies have the budgets to hire people who work on WPO full time. Those companies are able to do that thanks to huge revenues — otherwise it would not be financially justifiable. In other words: they’re probably a top 1,000 website. The percentages of page speed improvements those people bring must translate into sufficient additional revenue to cover their wages.
Other companies have people who get to spend part of their time on WPO, and maybe pay for the services of one of the several WPO companies out there. But even in this case, a sizeable revenue is a requirement to justify it.

So what about the millions of other websites?