Blog

Almost a year ago, BigPipe was the first experimental module added to Drupal 8. It was still experimental in Drupal 8.2 (October 2016), but it was upgraded from alpha to beta stability. Later today, Drupal 8.3.0 is going to be released, and BigPipe is now stable!

Install it!

BigPipe is a zero-risk module. So … why not install it right now? You can uninstall it at any time. It won’t cause problems in any browser, on any web server, or with any proxy. Because:

There is zero risk of data loss. And when the environment — i.e. web server or (reverse) proxy — doesn’t support streaming, then BigPipe-delivered responses behave as if BigPipe was not installed. Nothing breaks, you just go back to the same perceived performance as before.

If you’re still on Drupal 8.2 for a while — also install it! There are no functional changes for BigPipe between 8.3 and 8.2.

Stability

In hindsight, we could have made BigPipe stable from day one, or at least in Drupal 8.2.

This is an ode to Dirk Engling’s OpenTracker.

It’s a BitTorrent tracker.

It’s what powered The Pirate Bay in 2007–2009.

I’ve been using it to power the downloads on http://driverpacks.net since the end of November 2010. >6 years. It facilitated 9839566 downloads since December 1, 2010 until today. That’s almost 10 million downloads!

Stability

It’s one of the most stable pieces of software I ever encountered. I compiled it in 2010, it never once crashed. I’ve seen uptimes of hundreds of days.

Today, Drupal 8.1 has been released and it includes BigPipe as an experimental module.

Six months ago, on the day of the release of Drupal 8, the BigPipe contrib module was released.

So BigPipe was first prototyped in contrib, then moved into core as an experimental module.

Experimental module?

Quoting d.o/core/experimental:

Experimental modules allow core contributors to iterate quickly on functionality that may be supported in an upcoming minor release and receive feedback, without needing to conform to the rigorous requirements for production versions of Drupal core.

…

Experimental modules allow site builders and contributed project authors to test out functionality that might eventually be included as a stable part of Drupal core.

With your help (in other words: by testing), we can help BigPipe “graduate” as a stable module in Drupal 8.2. This is the sort of module that needs wider testing because it changes how pages are delivered, so before it can be considered stable, it must be tested in as many circumstances as possible, including the most exotic ones.

I spent about a week of my time at Acquia on improving Drupal 8’s REST support.

That time was spent fixing, reviewing, triaging and documenting.

Drupal 8’s REST works very well, we just have to make it more friendly & helpful, remove Drupalisms and support more REST capabilities.

Fixing, reviewing & triaging

I went through the entire issue queues of rest.module, serialization.module and hal.module. I was able to mark about a dozen bug reports as duplicates, fix a dozen or so support requests, have reviewed probably a few dozen patches, rerolled about a dozen patches, created at least another dozen patches and … triaged 100% of the open issues. I clarified titles of >30 issues.

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.

I’m happy to announce that Fabian Franz and I managed to get a first release of BigPipe published today, coinciding with the Drupal 8.0.0 release!

Rather than explaining what it does, see for yourself:

(That’s with 2 slow blocks that take 3 s to render. Only one is cacheable. Hence the page load takes ~6 s with cold caches, ~3 s with warm caches.)

Go download BigPipe 8.x-1.0-beta1![^1]

Fastest Drupal yet!

After Drupal 8 already shipping with both the Page Cache and Dynamic Page Cache enabled by default earlier, this is the third and final step in our quest to make the entire web fast.

• Fast anonymous user page loads: Page Cache — entire page is cached.
• Fast authenticated user page loads: BigPipe — majority of page including main content is cached (thanks to Dynamic Page Cache) and sent first, the rest is rendered later and streamed.

Go and enjoy the fastest Drupal yet![^2]

Later today, Drupal 8 will be released! At this time, good docs are of course crucial.

As the maintainer and de facto co-maintainer of several Drupal 8 core modules and subsystems, I spent the last several days making sure that the documentation is up-to-date for:

• the Text Editor module (editor)
• the CKEditor module (ckeditor)
• the Quick Edit module (quickedit)
• the Filter module (filter)
• the Cache system
• the Render system (specifically the render caching part)
• the Asset Library system

The following drupal.org handbook pages have either received minor updates, received complete overhauls or were written from scratch:

Drupal 8 now has a Dynamic Page Cache. The Page Cache module only works for anonymous users, the Dynamic Page Cache module takes that a step further: it works for any user.

Since April 8, Drupal 8 had its Page Cache enabled by default. Exactly 5 months later, on September 8, the Dynamic Page Cache¹ module was added to Drupal 8, and also enabled by default.

What?

The Page Cache module caches fully rendered HTML responses — it assumes only one variant of each response exists, which is only true for anonymous users². The innovation in 8 on top of 7’s Page Cache is the addition of cache tags, which allow one to use the Page Cache but still have instantaneous updates: no more stale content.

While walking, I started listening to Jeff Eaton’s Insert Content Here podcast, episode 25: Noz Urbina Explains Adaptive Content. People must’ve looked strangely at me because I was smiling and nodding — still walking :) Thanks Jeff & Noz!

Jeff Eaton explained how the web world looks at and defines the term WYSIWYG. Turns out that in the semi-structured, non-web world that Noz comes from, WYSIWYG has a totally different interpretation. And they ended renaming it to what it really was: WYSIWOO.

Jeff also asked Noz what “adaptive content” is exactly. Adaptive content is a more specialized/advanced form of structured content, and in fact “structured content”, “intelligent content” and “adaptive content” form a hierarchy:

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.