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".
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.
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.
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.
- After downloading CSS resources, browser parses them and applies them to the DOM tree.
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.
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.
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.