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?

My girlfriend and I both have an iPhone. Every night when we go to bed, we plug them in for charging. We also use them as our alarm clocks.

Until very recently, we did this by using the typical charger. Only my girlfriend’s side of the bed is rather far from a wall socket. So, she’d plug in a very long iPhone cable (that we got from Deal Extreme and was literally falling apart), but it was not quite long enough: she’d still have to get up (to reach for the phone, e.g. for turning off the alarm).
Plus, it was in my way to get to my side of the bed. So … several times I almost stepped on her iPhone, and many times I stumbled after getting stuck behind the cable. Less than ideal, right?

A very long time ago, on February 11, 2012, I backed the Elevation Dock Kickstarter for two docks. Somewhere in the beginning of 2013 I had received them. They’d been lying around in a closet, unused. A waste of money? I almost regretted ordering them.

What?

This article proposes a novel, simpler way of managing Drupal sites (where “managing” in this case is solely code updating & deployment).

It relies on only one command-line tool: mr (“a Multiple Repository management tool”, http://joeyh.name/code/mr/), plus a Drupal plug-in for that tool: mr-drupal, https://github.com/wimleers/mr-drupal.

Why?

If you run Drupal sites, you need some way to manage them; some way to keep them up-to-date. As of Drupal 7, there’s a built-in update manager, but it doesn’t use a VCS.

Most likely, you want use a VCS to manage your Drupal site. You may be downloading tarballs and checking their contents into your VCS, or maybe you’re using git submodules or even git-subtree. For all of these, there’s a whole lot of process, a lot of steps, a lot to learn, and a lot of tricky things you have to think about each time you want to update something. Too much that can go wrong.

Drupal 8 will ship with big authoring experience improvements: WYSIWYG editing & in-place editing, thanks to the Spark distribution that Acquia — my employer — is sponsoring.

But how well does it fare with the growing importance of structured content? Do Drupal 8’s WYSIWYG & in-place editing enable it or prevent it?

The new web world order: many form factors

The Big Thing of the last few years: the advent of mobile. Inherent to that: websites that are optimized for mobile devices and act as data providers for apps.

A new form factor — mobile devices — changed web development forever. Before mobile, the life of web developers and authors (content creators) was relatively simple: make sure websites work well on a few typical screen sizes (let’s deny the existence of Internet Explorer 6 and all the misery it caused).

But … we cannot predict what’s next. We cannot predict new content consumption form factors. That’s where content strategy becomes vitally important:

content strategy is to copywriting as information architecture is to design

We had already let you know that we would be using Aloha Editor as the WYSIWYG editor in Spark. In short: it has a very complete feature set, a proven plug-in system, solid cross-browser support, it can do “nested editables”, and so on; but most notably it’s the best WYSIWYG editor out there that can do “true WYSIWYG”.

Sprint

The most notable goals were:

A few weeks ago, we showed the in-line editing prototype we had built for Spark, which has now blossomed into Edit module. Additionally, we also pointed out that we were in the process of selecting the WYSIWYG editor to use in Spark. This selection process was performed in the public Spark issue queue, in order to gather community feedback and to attempt to reach consensus. 73 people followed that issue, about two dozen of whom contributed to the discussion as well.

After working at Nascom for a very brief time, I will soon start working at Acquia! I’ll be working on the Spark project as a Senior Software Engineer in the Office of the CTO (OCTO), reporting directly to Dries!

Why I left Nascom

I chose Nascom because I felt it was the best fit for me. I really preferred working for a Belgian company. Nascom seemed to have it all¹, but in the end, it was not a good match. I still stand by my choice of Nascom being the best possible choice I could have made, when limiting my choices to Belgian companies. They’re great. But the spark was missing for me.

Speed up your Drupal site with a CDN in a few minutes.

The fun part: it’s nice to learn how to make any Drupal site significantly faster in a few minutes. The profit part: faster websites lead to more users and more revenue.

This article covers the common case: you have a small to medium size (≤1M page views per month), without massive amounts of large images, you’re using Drupal 7¹ and you only want to spend a few euros or (U.S.) dollars per month on a CDN. (You already know what a CDN is, right?)
So, you want your Drupal site to be faster, only spend a few minutes doing so, don’t want to deal with infrastructure and want to keep the costs very minimal. You’ve come to the right place.

Also: don’t worry about the cost: this little experiment will only cost you a few cents.

I recently had my site redesigned (and that’s still in flux), but I also had a logo designed. Since I’m very much fond of llamas, I decided my logo would be a llama. (That one sits at the bottom of every page and greets you on the front page.) It was drawn by Ine Spee, whom has recently moved to the U.K. but is actually a fellow citizen of my hometown of Hasselt, Belgium.

A few weeks ago, a bank clerk told me I should get a personalized card soon if I wanted it for free… A happy coincidence of events later, and I now have a llama bank card! :)

It seems I’ve started an “Awesome Bank Card Saga”, since this is my second one already — back in 2008, I got a Drupal bank card! :)

The design

The result