Performance Calendar 2015: "2013 is calling: are CMSes fast by default yet?"

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 “2013 is calling: are CMSes fast by default yet?” article for the 2015 Performance Calendar that was published exactly a month ago.

Two years ago, I wrote about how making the entire web fast is the real challenge. How only the big few companies are able to have very fast websites, because only they have the resources to optimize for performance. Many (if not most) organizations are happy just to have a functioning, decent looking site.

In that article, I said I thought that if we made the most popular CMSes faster by default. That would go a long way to make the majority of the web faster. Then less technical users do not need to know about the many arcane switches and knobs just to get the intended performance. No more “oh but you didn’t set it up correctly/optimally” — or at least far less of it.

Drupal 8: fast by default on many fronts

Since that article two years ago I’ve been working with >3300 other contributors to get the next version of Drupal done. Drupal 8 was released a month ago and is much faster by default.

All of the following changes improve perceived performance and Drupal 8 has all of them enabled by default:

… and for those last three fast defaults, each of which does caching: they don’t ever serve stale content.

Instantaneous, optimal invalidation thanks to cache tags. Lots of interesting possibilities with Drupal 8’s cacheability metadata.

Also, some CDNs already support cache tags. Which means instantaneous invalidation of content even when served from a CDN.

More fast defaults coming in minor Drupal 8 releases

We also paved the path for more optimizations to land in upcoming minor versions:

  • automatically use BigPipe for the dynamic/personalized/uncacheable parts of the page, have the initial part of the page sent immediately, thanks to the aforementioned partial page caching
  • JavaScript minification3
  • responsive images: already supported but not enabled by default
  • HTTP/2 server push of assets: we already have a dependency graph of all assets — we’re mostly blocked on HTTP/2 servers actually supporting this.

There are of course many additional defaults that would help Drupal 8 be even faster by default, such as:

  • optimal image compression
  • load JavaScript asynchronously
  • automatic inlining of critical CSS

WordPress 4.4: responsive images by default

WordPress has made one significant change to improve performance: responsive images are enabled by default since the 4.4 release a week ago. Sadly, that’s the only significant WPO change in 2 years. (Six significant releases were made: versions 3.8 through 4.4.)

Joomla 3.x: status quo

Unfortunately, no significant steps forward have been made by Joomla to make it fast by default. 3.3.0 made the routing system faster and continued the conversion from MooTools to jQuery, which hopefully translates to less JavaScript being loaded. (Two significant releases were made: 3.3.0 and 3.4.0.)

Let’s…

So, Drupal has put a lot of effort into making version 8 fast by default. As Drupal 8 is rolled out, hundreds of thousands of sites will become faster.

Hopefully other CMSes (and frameworks) will follow.

Let’s make the entire web fast!

  1. Functionality that is implemented in JavaScript for authenticated users is applied on the server side once and cached for subsequent visits. ↩︎

  2. Yes, for HTTP/2 that will make less sense … but at least today’s HTTP/2 servers and browsers still benefit from aggregation. ↩︎

  3. To do JavaScript minification in compliance with the GPL is not trivial. ↩︎

Original Article: