From Bauman National Library
Revision as of 13:43, 13 January 2017 by polina bobr (Talk | contribs) (BigPipe)

BigPipe is a radical new modular web pattern for Node. It is used in Drupal. It is an open source content management platform for millions of websites and applications. It was designed to be an active and diverse community for people around the world. BigPipe only works for users with a session. All authenticated users have a session. For anonymous users, you can explicitly start and stop a session in the block called "Start/stop session".

BigPipe demo site


People started pipelining web pages for high performance. This is because site speed is one of the most critical company goals for Facebook. In 2009, Facebook site was made twice as fast. Several key innovations from our engineering team made this possible.

BigPipe is a fundamental redesign of the dynamic web page serving system. The general idea is to decompose web pages into small chunks called pagelets, and pipeline them through several execution stages inside web servers and browsers. This is similar to the pipelining performed by most modern microprocessors: multiple instructions are pipelined through different execution units of the processor to achieve the best performance. Although BigPipe is a fundamental redesign of the existing web serving process, it does not require changing existing web browsers or servers; it is implemented entirely in PHP and JavaScript.

When was BigPipe created?

Starting in September 2014, Fabian Franz created a working proof-of-concept. Wim and Fabian went on to simplify its implementation, making significant changes to Drupal 8's rendering pipeline along the way to bring the concept of "placeholders" to Drupal core. This concept is essential for BigPipe, but also for ESI and it's also what enabled Drupal 8’s Dynamic Page Cache.

Wim explains, “The problem we were solving: Drupal 7 can’t really cache its output because it lacks metadata for caching. It generates just about everything you see on the page on every page load, even things that don’t change. Drupal 8 does far less work when serving a page, because we brought cacheability metadata to everything. BigPipe is the most powerful way to put that cacheability metadata to use and it delivers the most significant performance improvements.”

Has Drupal 8 changed this module?

“BigPipe was not possible before Drupal 8. So, no, it's the other way around: BigPipe has changed Drupal 8 and made it the fastest Drupal yet.” - Wim Leers.


Each day, more Drupal 7 modules are being migrated over to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules available for Drupal 8. This week: BigPipe.

Wim Leers, Senior Software Engineer in Acquia’s Office of the CTO and Drupalist for more than nine years, helped me better understand the power and importance of this module that he and Fabian Franz, Senior Performance Engineer at Tag1 Consulting have developed exclusively for Drupal 8.

Comparison of standart and bigpipe caching page loading

What does the BigPipe module do

The BigPipe module speeds up page delivery times by sending unchanging parts of a page to the browser immediately while rendering and streaming other, dynamic parts as soon as they are ready. Facebook pioneered the streaming of content in so-called “pagelets”. Wim and Fabian invented a technique called “auto-placeholdering” for Drupal 8 that automatically detects and separates the static (and usually cached) parts of a page--the main content and images, for example--from dynamic, uncacheable, personalized page elements. These can be specific to a logged-in user like content recommendations, friend notifications, or editorial controls; or the contents of a non-logged-in user’s shopping cart, for example.

Why is this important

In a nutshell: Using BigPipe, you get significantly faster sites without any special technical investment. There is zero configuration or coding needed: install it and let it do its thing. In Drupal 7 and just about every other CMS or framework, personalization has always made things run slower. Using BigPipe in Drupal 8, it is no longer so.

“We’ve created a way for anyone to take advantage of this technology that was previously only available to global players like LinkedIn and Facebook: just by installing our BigPipe module.” - Fabian Franz.

For developers: As long as you provide correct cacheability metadata, Drupal 8 will be able to automatically deliver personalized parts of the page later, without you having to write a single line of code. For example, every block in Drupal 8 can be rendered in isolation and can therefore be rendered later. So any personalized blocks you provide can automatically benefit from BigPipe. Fabian adds, “Powerful use of placeholders gives developers endless possibilities to optimize the delivery and caching of dynamic content. For example, this will make it possible to serve all content directly from a CDN (Content Delivery Network).”


To understand BigPipe, it's helpful to take a look at the problems with the existing dynamic web page serving system, which dates back to the early days of the World Wide Web and has not changed much since then. Modern websites have become dramatically more dynamic and interactive than 10 years ago, and the traditional page serving model has not kept up with the speed requirements of today's Internet. In the traditional model, the life cycle of a user request is the following:

  • Browser sends an HTTP request to web server.
  • Web server parses the request, pulls data from storage tier then formulates an HTML document and sends it to the client in an HTTP response.
  • HTTP response is transferred over the Internet to browser.
  • Browser parses the response from web server, constructs a DOM tree representation of the HTML document, and downloads CSS and JavaScript resources referenced by the document.
  • After downloading CSS resources, browser parses them and applies them to the DOM tree.
  • After downloading JavaScript resources, browser parses and executes them.

How BigPipe works

To exploit the parallelism between web server and browser, BigPipe first breaks web pages into multiple chunks called pagelets. Just as a pipelining microprocessor divides an instruction’s life cycle into multiple stages (such as “instruction fetch”, “instruction decode”, “execution”, “register write back” etc.), BigPipe breaks the page generation process into several stages:

  • Request parsing: web server parses and sanity checks the HTTP request.
  • Data fetching: web server fetches data from storage tier.
  • Markup generation: web server generates HTML markup for the response.
  • Network transport: the response is transferred from web server to browser.
  • CSS downloading: browser downloads CSS required by the page.
  • DOM tree construction and CSS styling: browser constructs DOM tree of the document, and then applies CSS rules on it.
  • JavaScript downloading: browser downloads JavaScript resources referenced by the page.
  • JavaScript execution: browser executes JavaScript code of the page.

The first three stages are executed by the web server, and the last four stages are executed by the browser. Each pagelet must go through all these stages sequentially, but BigPipe enables several pagelets to be executed simultaneously in different stages.

In BigPipe, the life cycle of a user request is the following: The browser sends an HTTP request to web server. After receiving the HTTP request and performing some sanity check on it, web server immediately sends back an unclosed HTML document that includes an HTML <head> tag and the first part of the <body> tag. The <head> tag includes BigPipe’s JavaScript library to interpret pagelet responses to be received later. In the <body> tag, there is a template that specifies the logical structure of page and the placeholders for pagelets.

After flushing the first response to the client, web server continues to generate pagelets one by one. As soon as a pagelet is generated, its response is flushed to the client immediately in a JSON-encoded object that includes all the CSS, JavaScript resources needed for the pagelet, and its HTML content, as well as some meta data.
For example: <script type="text/javascript"> big_pipe.onPageletArrive({id: “pagelet_composer”, content=, css=[..], js=[..], …})

At the client side, upon receiving a pagelet response via “onPageletArrive” call, BigPipe’s JavaScript library first downloads its CSS resources; after the CSS resources are downloaded, BigPipe displays the pagelet by setting its corresponding placeholder div’s innerHTML to the pagelet’s HTML markup. Multiple pagelets’ CSS can be downloaded at the same time, and they can be displayed out-of-order depending on whose CSS download finishes earlier. In BigPipe, JavaScript resource is given lower priority than CSS and page content. Therefore, BigPipe won’t start downloading JavaScript for any pagelet until all pagelets in the page have been displayed. After that all pagelets’ JavaScript are downloaded asynchronously. Pagelet’s JavaScript initialization code would then be executed out-of-order depending on whose JavaScript download finishes earlier.

The end result of this highly parallel system is that several pagelets are executed simultaneously in different stages. For example, the browser can be downloading CSS resources for three pagelets while rendering the content for another pagelet, and meanwhile the server is still generating the response for yet another pagelet. From the user’s perspective, the page is rendered progressively. The initial page content becomes visible much earlier, which dramatically improves user perceived latency of the page. To see the difference for yourself, you can try the following links: Traditional model and BigPipe. The first link renders the page in the traditional single flush model. The second link renders the page in BigPipe’s pipeline model. The difference between the two pages’ load times will be much more significant if your browser version is old, your network speed is slow, and your browser cache is not warmed.