Drupal 8: BigPipe module ready
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
P.S.: none of this would have been possible without my employer Acquia, whom sponsored both my time and Fabian’s to make BigPipe a reality.
-
We were able to release it today because the code was ready: it was developed over the course of several months in a Drupal core issue and “just” moved into a module, with every commit matching a comment in the issue, to make it easier to understand how the code base got to this point. ↩︎
-
And please report any issues you encounter at d.o/project/issues/big_pipe — depending on how well BigPipe works in the real world during Drupal 8.0.x, we should be able to get it into Drupal 8.1.x core! ↩︎
Comments
Congratulations, Wim and Fabian! Your work all these months is awesome!!
Congrats! Awesome work by everybody involved. Amazing progress Iike this is exactly what Drupal and the web need.
Amazing that you have managed to get this far within Drupal 8 release. Thanks for all your hard work in core and contrib making Drupal 8 as fast as it possibly can be. How does big pipe work with pages you want to cache in Varnish or another proxy, will this give any issues or does it just work?
I’ve just added documentation to explain exactly that. Proxies can’t cause sites to become broken when using BigPipe, but they can break BigPipe by buffering a response, which causes the response to not actually stream, and hence once again function as the traditional model.
I just found out LinkedIn switched to BigPipe-style rendering https://engineering.linkedin.com/frontend/new-technologies-new-linkedin-home-page — see http://www.ybrikman.com/writing/2015/06/30/ping-play-big-pipe-streaming-for-play-framework/ and https://github.com/brikis98/ping-play for the code (Scala).
Dries just blogged about this: http://buytaert.net/bigpipe-no-longer-just-for-the-top-50-websites.
And apparently node.js now also has a package for it: https://github.com/bigpipe/bigpipe.
Thank you for your work Wim! Does ‘streaming’ mean that the more expensive content is actually sent to the client after the main html document has already been sent? I am asking this, because it does not matter what gets rendered in which order, if it is still sent in a single html document, correct?
Correct, the “more expensive content” (the poorly cacheable or uncacheable content to be accurate) is actually sent to the client after the “main HTML document” (the cacheable content to be accurate).
This is not correct. Please read the documentation: https://www.drupal.org/documentation/modules/big_pipe. And perhaps also read the Facebook “Engineering Note” where they present BigPipe: https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919 (also linked from the documentation).
Thank you for the info. I have a customer on Drupal! I mainly use dynamic caching on Joomla which works very well for me but I will have this in mind if need arises for Drupal customers. Prodromos Kikas ( https://www.jcsl.com.cy ( GR)) JCSL Ltd ( https://www.jcsl.com.cy/en (EN))