According to intriguing research, pages with a load time of 1 to 2 seconds have the maximum conversion rates, and with every additional second of load time, the conversion rate drops by 4.42%. Surprising. We live in a world where speed is everything. If your website performance cannot meet the expectations of the visitors, the stakes are quite high. So, what can you do to boost website performance? Gladly, there are numerous techniques available and the BigPipe technique is one of them. If your site relies on Drupal, you can install the BigPipe module with incredible Drupal 10 compatibility to leverage the power of this technique. It is interesting to note that the BigPipe technique was initially developed by Facebook but today, a plethora of organizations are utilizing it across the globe.
How Does Drupal BigPipe Function
The BigPipe module works by decomposing webpages into small chunks. These small chunks are known as pagelets and are pipelined through several stages of execution inside web browsers and servers. To be a bit more specific, BigPipe breaks an HTML response into chunks before sending:
● One chunk: It includes everything until just before </body> which possesses BigPipe placeholders that are essential for personalized parts of each page. Hence, this one chunk sends the non-personalized parts of the page. Let’s name it The Skeleton.
● N chunks: It includes a tag <script> for every BigPipe placeholder in The Skeleton.
● One chunk: Finally, this one involves the </body> and everything that comes after it.
The best part of this module is that it is seamlessly available for Drupal 8 and beyond. This implies that whether you have already made the switch to Drupal 10 with Drupal 10 migration services or still rely on Drupal 9, you can leverage the power of this incredible module. As the process discussed above exhibits conceptual similarities with Facebook’s BigPipe technique, this Drupal module is known as the BigPipe module. However, there are some points of difference between both, which we’ll discuss now.
Differences Between Drupal BigPipe and Facebook’s Technique
A major difference between Drupal BigPipe and Facebook BigPipe is that the former possesses the capability to automatically discover the parts of the web page that can reap benefits from BigPipe-style delivery. Drupal’s render system is equipped with ‘auto-placeholding’ which replaces dynamic content with a placeholder that can be rendered later.
Another point of difference is that Facebook’s BigPipe implementation requires JavaScript. When it comes to Drupal’s BigPipe module, JavaScript isn’t an integral requirement for replacing placeholders. This implies that it isn’t technically BigPipe. It is just the utilization of multiple flushes that makes it possible for us to leverage both ‘no-js’ BigPipe and ‘classic’ BigPipe in the same response. This maximizes the amount of content we can send in a short frame of time.
Here is what exactly happens during page rendering
● It all begins by turning personalized parts into placeholders.
<span data-big-pipe-placeholder-
id=“callback=d_profiles.builder%3Abuild&args%5B0%5D=profile_widget_mini
&token=6NHeAQvXLYdzXuoWp2TRCvedTO2WAoVKnpW-5_pV9gk"></span>.
The placeholder is equipped with information about the required callback to call and pass arguments to. The renderer continues its journey of traversing the array and converting it to HTML which is cached by default. Afterward, in accordance with the rendering strategy being executed, dynamic content replaces each placeholder.
● Javascript is utilized for replacing the placeholders. Once a special element is printed and located, the callback begins searching for replacement script elements.
<script type="application/vnd.drupal-ajax" data-big-pipe-event="stop">
● The replacement with the actual content takes place at the very last moment. With this new strategy, flushing the initial web page before anything else becomes possible. Later, we can easily stream the replacements for placeholders
How and When to Use Lazy Builders?
Let’s begin with the when first. It is best to use lazy builders with the following types of content
● Content with high cardinality if cached: A block that is responsible for displaying the user's name is an incredible example of such type of content. Caching is possible for it but it can also result in cached objects that exhibit a low hit rate as it varies with each user.
● Content with no possibility of caching or with a very high rate of invalidation: This type of content includes the display of current date and time or statistics that are required to be up-to-date.
● Content requiring a lengthy and potentially slow assembly process: A block leveraging a third-party API to display content where content requests to the API are incurred overhead, is an example of this type of content.
Now, let’s proceed to discuss how to use lazy builders
To understand the implementation of lazy builders easily, let us consider an example wherein a custom profile widget block has been placed on a web page. The block has the user’s full name, profile picture, and profile menu.
We can leverage various strategies such as employing user contexts and tags and setting the “max-age” to 0 to ascertain that every user can see their personalized information. However, we need to be aware that once we set “max-age” to 0, the rest of the web page will become uncached.
Gladly, Drupal uses the concept of ‘auto-placeholding’ which makes it consider the block as a personalized part without fail. Consequently, it turns it into a placeholder.
However, there is an issue we have to deal with here - the entire block gets replaced by a placeholder.
<span data-big-pipe-placeholder-
id="callback=Drupal%5Cblock%5CBlockViewBuilder%3
A%3AlazyBuilder&args%5B0%5D
=profilewidget&args%5B1%5D=full&args%5B2
%5D&token=QzMTPnxwihEGO
itjJB_tahJj8V-L-KopAVnEjVEMSsk"></span>
Further, it is imperative to note that for all users, the data within the block may remain static or consistent.
If we wish to make our block more granular, we can easily do so with the transformation of dynamic parts into placeholders. The rest of the block content continues to remain cacheable and loads during the initial page load effortlessly.
Here is the step-by-step procedure for developing and implementing lazy builders
Developing lazy builders
Just like other elements, lazy builders are executed with a render array of the #lazy_buildertype. A callback should be the first element of the render array and the second element should be an array of arguments to the callback.
When it comes to the properties of render elements, they should only contain #cache, #weight, and #create_placeholder.
Implementation of a trusted callback interface
At this step, it is crucial to ensure that our lazy builder implementation is capable of calling the lazyBuilder() method. For this, all we need to do is execute the trusted callback interface to inform Drupal that our lazy builder callback has permission to be called.
During the implementation of this interface, we shouldn’t forget to add the trusted callbacks () method. Drupal can call this automatically through interface detection. This method’s return value should produce any methods within the class capable of being used as callbacks.
The following image shows its basic implementation:
The cached block will look like
<div id="profile-widget" class="profile-widget dropdown">
<button class="btn dropdown-toggle" type="button" id="dropdown-menu-button" data-toggle="dropdown" aria-expanded="false">
<div id="block-profilewidget" class="img img--round">
<span data-big-pipe-placeholder-id="callback=em_profiles.builder% 3Abuild&args%5B0%5D=profile_widget_mini&token=ArkAzE-rR2gaSeRCkyb61vLT6nWbvDcIx0HQ8gjUMUs"></span>
</div>
</button>
<div class="dropdown-menu" aria-labelledby="dropdown-menu-button">
<section class="profile-widget__data p-5">
<h3 class="profile-widget__name title-h4 mb-2">Profile</h3>
<span data-big-pipe-placeholder-id="callback=em_profiles. builder%3Abuild&&token=ODDkF_Laqrq9ERh-djJN_UI_C1J2L6FtmRMh8luWPqk"></span>
</section>
<nav class="profile-widget__menu p-5" aria-labelledby="profile-widget">
<ul class="nav navbar-nav">
<li class="nav-item">
<a href="/user/settings" class="nav-link--icon-settings nav-link--icon nav-link" data-drupal-link-system-path="user/settings">Settings</a>
</li>
<li class="nav-item">
<a href="/user/logout" class="nav-link--icon nav-link--icon-logout nav-link" data-drupal-link-system-path="user/logout">Logout</a>
</li>
</ul>
</nav>
</div>
</div>
Generally, the lazy builder callback gets executed on every page load. However, in some cases, caching placeholders is an integral requirement. For this, we can add cache keys with the cache context. The following image depicts the same.
Ascertaining a smooth visual page load experience
Drupal BigPipe can sometimes delay the loading of certain parts of the page. As it could result in user frustration, it is imperative to address this issue proactively. The best way to do so is to reserve a space for the lazily loaded content. This will help avoid reflowing content. Another solution we can implement is to apply a loading animation to all BigPipe placeholders in the selected theme with CSS. If this is something you wouldn’t try, the last resort is to define an interface preview that BigPipe can populate with the help of a Twig template.
Here is a comparison of the final result produced in custom lazy-builder strategy (1) and auto-placeholder strategy (2).
Tips For Avoiding Problems with Lazy Builders
There are several reasons why a lazy builder might not prove to be fruitful in enhancing Drupal page load speed or producing the desired results. If you also experience any issues with lazy builders, given below are some things you can try.
● Ensure the Drupal BigPiple module is active.
● Check the cache settings for the lazy builder callback method. As Drupal automatically makes some assumptions about the cache, it might opt for settings that may not be suitable for you. So, you can evaluate the cache settings and make the desired changes.
● At times, an upstream CDN or Varnish layer might be contributing to the problem by caching the entire webpage. Consequently, the entire output of the BigPipe rendering process might be served simultaneously. If this happens to you, you’ll have to devise another mechanism to mitigate the issue.
Let’s Wrap Up
Drupal BigPipe is a phenomenal module for taking website performance to a whole new dimension. It is available from Drupal 8 onward and exhibits seamless Drupal 10 compatibility. The underlying principle behind its working is breaking an HTML tag into chunks. If you also aspire to leverage the power of this incredible module to boost website performance, the above-mentioned information will lighten up your path.
If you come across any issues with the module or require expert assistance, feel free to contact us. LN Webworks is a trusted Drupal development company. Our Drupal development team excels in dealing with all facets of the module. So, without any second thoughts, reach out to us today.
Author Information
LN Webworks
Your Drupal Solution PartnerLN Webworks have championed open-source technologies for nearly a decade, bringing advanced engineering capabilities and agile practices to some of the biggest names across media, entertainment, education, travel, hospitality, telecommunications and other industries.
