 Good afternoon, everyone. Can I have a good afternoon back? I knew you all would be feeling a bit sleepy because we just had lunch. So kindly bear with me on this. So welcome to DrupalCon Vienna. And I'm Jyoti Singh. I'm working in region technologies as a Drupal developer. And I'm really very excited for this DrupalCon because that's my first DrupalCon as a speaker. And I've been in this beautiful city Vienna and with a lot of beautiful people out here. So moving on, I'll just give us a short description of what topics we are going to have in our sessions today. What is big pipe? How does big pipe actually works? How to use big pipes in our current project? Implementation of some big pipe modules in our Drupal8 sites and a demo of big pipes along with some few illustrations. This is a short demo. So who all out here have worked on big pipe? Okay, not so many. And how about Drupal8? A lot of money of people. So the big pipe is being introduced in Drupal8. So it's not a concept of Drupal7. So it's a new introduction in Drupal8 right now. So the topic for today's session is tunneling its way fast with big pipe. So today we'll be talking about big pipe. And I'm Jyoti Singh with a hashtag at the rate jyoti.sing in Twitter. So before starting my session, I would like to give a word of thanks to Wim Lears and Fabian France who have done a fantastic job for giving us big pipes and caching for Drupal8. So it said that Drupal8 is one of the fastest ever Drupal. So that's because of Wim Lears and Fabian France that we have a fantastic caching system in Drupal8 and big pipes. So what do you want when you browse our site? So what type of site does you guys usually browse into? Anyone from the crowd? Can I have answer from you, sir? Facebook? So what happens when it loads really slow? What do you think? Something's broken, right? And it's like you just close the page or you just refresh the page again? Both, yeah. So it takes your time and maybe you get frustrated sometime, yeah. So why should the user be concerned about the page load time? It should be like he should be on the website and it should load fast. That was the user one. He nothing wants to see anything technical into the site. It doesn't want to sleep when he goes to the slide site. So how does a user feel? It's like how does I feel when I do the shopping? It's like sometime it's really slow. The page is really slow and I'm sleepy too. So what's the important of the time? So I went to some of the stats. It's completely the stats that I found on Google. So it says that one person, 40% of users abandon their site if it takes more than three seconds to load it. So it's totally impacting the business, right? So if I say I have a business and my site is running and the user is not satisfied at all, then there's something going wrong in my site. So it's like 79% of the shoppers who are dissatisfied with the website never ever go to the site again. So that's again impacting my business. And there are also many other domains that get affected by the same things. That like say search engine because if your site is slow, sometime Google doesn't get to read the keywords that you have in your pages. So if I ask a question that how fast you think that your site should load, so what answer would you have in your mind? Some answers? One millisecond? 300 millisecond. Okay. So there was a survey done by akamayangomes.com and they found that nearly more than half of the user on the website want their page to load in less than two seconds. And that's gradually decreasing every time because we are becoming more digitalized and we want our pages to get load at fast as possible. So when I say fast, what does fast means? So there are a few measurements that I have here with respect to what fast means when I go or browse a page. It's a great user experience. When I hit the page, I should see the site. Then it's time to first byte. What's time to first byte? It's the response that you get from your web server. So it should be as fast as possible to make your site load fast. Then it's time to asset fetching. How fast your JavaScript, your CSS, your images are being fetched in your site. That's also a very key point in your optimization and performance measurement for your site. And then there's a new term that's time to interaction that gave a path to big pipes and other things that are being produced nowadays in our site. So what does time to interact means is the first interaction that the user has with your site. So whenever you load your site, at least you should have some content that the user is to keep the user intact to your site. And lastly, the page load time, of course, should be minimal for the user. There are some other usual optimization that we usually do in our site. That is optimizing our code, making the query as simple as possible and using caching and other things. And if I say from the front end perspective, it is we minify JS, we minify CSS, we try to reduce images, we try to cache images, and we try to make as small and as low connections as possible. So how can we make the page load faster? Even with such optimizations that I already discussed, we still have lag of time in our pages, especially if I talk about Groupal. I see that even after working on my optimization for CSS and JS, I still have the slow page load time or in my site. So what the Drupal 8 said was cache everything. You should have correct invalidation in Drupal 8. So anybody who's worked with caching in Drupal 8, great amount of people. So correct invalidation with your render API, specifically if I say render API, it would be you should know where to put the cache tags, cache keywords, cache contents, cache max age, and cache tags are specifically for your render API to make the page optimize. So when we use cache context, it's cache dependent, cache context dependent. So sometimes you want the page to display user-specific content or you want to display some cache content in your specific URL. So here we use cache context. Secondly, cache max age is used for those content that usually change within some time period, like for some blocks that we are fetching Twitter handles or some feeds from another third party sites. And then cache tags are totally dependent on the data, the data Drupal renders. So even after I say I put up the cache for everything, I have some problem. So further on I'm going to discuss what problem I usually have with my site. We say cache all things. This cache solves everything in Drupal 8. People say yes, caching is the powerful weapon in Drupal 8, but somewhere it fails. It fails in cases where we have dynamic and static content in the same page. So handling static content with caching is very easy. It makes your page really, really very fast. Just in case of Drupal 8, we have anonymous page caching. So it's really powerful in Drupal 8. But when we talk about dynamic content that are really user-specific or that changes really very frequently, like for example, if we talk about some shopping site, that's really user-specific and its content changes now and then with every user choices and the selections. So in that cases, the caching fails. How can you cache something that's really changing every now and then? So the answer is, how can we optimize the page that is very dynamic? What can be done for that? So what Drupal 8 provided with the solution is placeholders. So any idea about the placeholders? Anyone in the crowd? Have you ever heard about placeholders? Okay, so, sir, can you give me any idea about the placeholder? Okay. Okay, that's the rendering. How Facebook renders the page. Like it's render your static part first and then it's render the dynamic page that's user-specific, correct? Okay, so placeholder is something I'm going to go into the technical details. What can we do with the dynamic content? What Drupal 8 actually does? I haven't started with big pipes yet. It's still the Drupal 8 core part that I'm talking about, the placeholders. So for the placeholders, the Drupal 8 core uses a single flush technologies that is used to handle the really very dynamic part of your page. For instance, if I say, if I am in a shopping cart and I am changing my choices and I am deselecting and selecting some of the things, so what should I do then? So what Drupal core does is it creates a dome with static content and then it creates a placeholder for every dynamic content. So you get the static content at the first time to first byte when you load the page and then after it, the page is refreshed and the placeholder are replaced by your dynamic content. So what user get to see is something because what happens is if you see that the page is loading and it's showing me nothing, then it's for no use for me as a user. So if you get to see something, then you are interacting with your site. So what Drupal 8 does is it plays all of your dynamic content in a placeholder and it's a part of the render API. So render API creates a placeholder and that it is replaced by the dynamic part of your page. So this concept is really renowned concept when we talk about big pipes is performance versus perceived performance. Performance something you want to measure in term of efficiency, time to first byte, and something that is quantitative. But when we talk about perceived performance, I cannot quantify it because as a user, you may have some other perspective of your page loading. For me, I want to see some images when I load the page. You want to see some username so that I cannot quantify the perceived performance for me. So as said by Dan's Michono, physical, the psychological time in our brain usually differs from the objective time of the clock. That means what you perceive is really different from what it exactly is. So how long it takes to generate the page is what I can quantify. But how long it takes me to see the content is something that totally depends on each of the perception. So if I show you the stats of the Facebook performance as said by sir that Facebook uses the big pipes. So Facebook uses big pipes and it has drastically reduced the page load time to almost 50% by using it. So what is big pipe? Big pipe was a concept conceived by Facebook and what theory it works on is that whenever the user loads the page, it renders the static content of the page and after that loads the dynamic content in the dome of the page. So this is what big pipe actually works in really lame word. So big pipe made Facebook as twice as fast and it segregates the page into smaller chunks known as pagelets. I'll be discussing about the pagelet in the next slide. And big pipe pipelines pagelet to several execution stage inside web server and browser. So I'll be covering this up and I'll be discussing the pagelets. So what pagelet is? Pagelet is a component of HTML page that contains layout, directives, code, HTML, everything of the page. And what big pipe does it? It divides the page into different pagelets and when you render the page in your browser, it first renders your static content and then slowly renders each every pagelet. So here's a small demonstration between how the standard caching works and how the big pipe caching is used to render the page. So here you can see in the standard way it's loading all the dome together. So the user is not able to see the content, any content, any interactive content whenever he loads the site. But with big pipes, what he sees is a header, something product and some footer and then some dynamic content with social media and some more products to be loaded in next phase. So what this helps the user is with interacting with your site more. So it takes the same time in the end, but the perceived performance is better. If you say big pipe has been a really big achievement and it has made Drupal it really, really very fast. So I would say it has made the perceived performance very fast. If you have a really heavy content page with a really dynamic content, the time to first bite and the time to asset fetching would be really affected, but overall page load would won't be affected that much. So if you'll be using big pipe and you say that my page would be really loaded fast, then I would say it would be incorrect to say. The perceived performance would be really fast but not the actual load time. So here's a small difference between big pipe and lazy load. So many people ask me that why not lazy load? When we are using lazy load so much with JavaScript with everything content in Drupal 8, we have so much to do with those load. Why to introduce big pipe? So there are a few differences between the structure costing and the speed for both. So when we talk about structure, the Ajax request that lazy loading has is different from the one that big pipe has. So for every scroll or for every Ajax hit, for your lazy load, we have different Ajax requests per HTML response. But if I talk about big pipe, what big pipe does is it accumulates all your Ajax request and post it in one HTML response. So that's the difference. So structural reference I will be discussing when I'll be going into the detail as to how big pipe works. And for the processing cost, it's almost the same for the lazy load and big pipes. But for the speed, it's almost one third the speed of lazy load. So big pipe is really three times as faster as lazy load. So if I say if I have to use lazy load in my Drupal site, so what people usually say is there are, there is a tremendous amount of content I want to show in views page, views listing page. And I want to implement a lazy load. So I would rather say that lazy loading is basically for images and not for content, though we still are using it for content management also. And for, if I say about SEO purpose, so if I have a one page application and I use a lazy load, then some of the content may not exist for Google. So that would be affecting the search optimization for your site. And every lazy load I said fires a HTTP request. So that we have really, we have many number of end points for lazy loads, but for big pipes we just have a single HTML response for every Ajax. So how big pipe actually works in general, I'm going to show that first. And then we'll be moving on into the details for the big pipes. So for the processing of the page by the big pipes, there is a request parsing that uses the web server parses and sanity check for every HTTP request that you are going to request from your web browser. And then there'll be the data fetching from the web browser and stored in the architecture or the tire that you have for your site. And then there's a markup generation wherein the big pipe would understand what static part and what dynamic part does your page has. And then there will be a network transport. The response is transfer from web server to your browser. Then we have a CSS downloading and the asset downloading by your page. Then there's a DOM tree construction and CSS styling that's associated, wherein we construct the DOM, but we do not add into the dynamic content. Then there is JavaScript downloading, wherein the JavaScript asset of your browser is being downloaded. And then there is JavaScript execution for your site. So this is how big pipe actually works in stages. So this is basically a theoretical thing that I wanted to add to the session. So how does big pipe create placeholder? So we talked about how core create the placeholder, but how is big pipe actually using those placeholder? So if I say, I already have a placeholder in my Drupal 8 core, so what does big pipe does? That's the concept is auto placeholdering. When we say placeholdering, it's creating a dynamic content every time, but you need to specify that which dynamic content are you going to have. But with big pipes, what big pipe does is, it's automatically differentiate between the static and the dynamic content. So you need not explicitly specify for your comments, for the user comment, for user specific block, for your changing content, to be up to be included in the placeholder. It is automatically identified big pipes. So there are the sections that have been replaced by the placeholder for the Drupal core. And in big pipes, they are automatically identified and rendered. So what Drupal actually at the end sends out is a markup along with your static content. And then after loading the dome, it loads your dynamic content as a placeholder. So the condition where for your content, browser content lies for auto placeholdering are high cardinality, where in some content that have lot of variation, as I talked about, like if you are fetching a Twitter feed from a third party, then it's really dynamic. And then the content which have a block that is constantly changing now and then is having a high invalidation rate. And also for those content that has a really small cash max age have high invalidation rate. So that falls into the category of differentiating by the big pipes that what all content of your site are actually dynamic. So we talked about the single flush strategy that Drupal it uses in its core. But what big pipe uses is an end flush strategy for the rendering API. So there's two categories where in the big pipes render API works. First is a default placeholdering strategy, wherein I talked about that there and Ajax responses for the big pipe, but there would be just single HTML response every time, unlike lazy loading. So here's a code from big pipe. So it's a file inside SRC folder. And this class has a create big pipe placeholder function, wherein it creates the placeholder for your dynamic content. So what argument it takes actually is a original placeholder, then placeholder render API that you are going to use for your content. And then what it actually does it, it creates a caching mechanism for those content and it's add up the marker for your static content. So here the placeholder are being created by the big pipes. So that's just, I would just wanted to give a glance of how big pipe module actually works towards it. Another strategy is a no JS big pipe placeholder strategy. Though big pipe doesn't work with the JS when there's no JS and when there is no session, but still there is a technical terminology for no JS big placeholder. So what it does it, it combines all the embedded HTML responses into one HTML response. So how it looks in the code is in the same file that I showed you before, there is another function that is create big pipe no JS placeholder, wherein you are not using the JS. I would rather say it is not part of the big pipe concept, but still it's included in there. So what it does it takes original placeholder render array and some attributes as the concept, as our argument. And then it's create the placeholder with nflush strategy. So earlier we didn't use the JS, earlier we used the JS and now we don't have the JS. So how did big pipe successfully make your page load faster? So where it actually creates the pagelets and everything in its code. So here's another send content function in the same file. And what it actually does it's use three function that's send pre-body, send placeholders and send post-body. I've already marked their three function. I hope it's visible to all. So send pre-body, what it does it takes the HTML from your browser request and then it finds out what is the static and the dynamic content. And then in the send placeholder, it sends all the dynamic content and in the post-body it sports the static content for your browser. So what it usually do is it creates two sections of static and dynamic page before rendering. So placeholdering how Drupal core is different from big pipe placeholdering. So I created a snapshot for the Drupal core. How the render array look for your page. So every request we make, the Drupal core creates a render API with markup, max age, caching tags and big pipe placeholder, I guess. This one is the Drupal core render API wherein uses the lazy builder with, you cannot see any big pipe, big pipe variable or the render array. Here what you see is a lazy builder that is being used by Drupal eight core. And we have the comment section, the common render array, and then there's another lazy builder for the same comment. And this is the array that is being used by big pipe, the render API array. And here it creates the markup for the static content that it renders first. And then it has all the cache tags like max age and context. And then it has a big pipe placeholder wherein you can see that there's another lazy builder for the same comment. So this is how big pipe actually distinguish that what is the dynamic content in your page. So how do we use big pipes in Drupal? That's really simple. That's a no configuration module. You need to just enable the module and there is no configuration that is associated with this module. And it actually works with internal dynamic page wherein with the help of internal dynamic page, it uses the static content to be rendered first for before then the dynamic content. And for the internal page cache, it doesn't actually affect the internal page cache because it works only for the sessions of the user. So I'm going to show you a quick demo for the big pipe. So here's a demo site wherein I have a list of many contents with a lot of content and images. And there is a block at left hand side that shows me the Twitter field, the latest Twitter field with the Drupal tag. So it is the dynamic content here and right now I don't have the big pipe module enabled for this site. If I try to check the time needed for time to first byte here, is it visible to everyone? The time to first byte. So it's 1.32 second, the time to first byte. Now I'm going to enable the module. The module is enabled and you can see the drastic change in the time to first byte. It's like 55.75 millisecond. So even with having the long list of my page and with a dynamic block, I'm able to achieve a smaller number of time to first byte here. So this is how big pipe works. I didn't have any configuration. I need not specify that what do I need to have as a placeholder for my big pipes and it automatically identifies. It won't actually affect the page load time. If you see the page load time, it's actually not affecting that much. The thing that we want to see here is the perceived performance by the user. That's all from my end. Any question and answers? Any questions from the crowd? Yes? Sorry? Do I need to come? Oh, sorry. How can you leverage a custom block? For instance, you have a custom block which does an API call. How do you tell the block that it has to use big pipe? Okay, so the one I'm using right now in my case is a dynamic block which fetches all the Twitter feeds that we provide in a configuration. So what I really do is provide a hash placeholder in my render API. So that's the structure of the Drupalate. So for the people who are really new to Drupalate, that's the structure for the Drupalate module. So I have a block here. What I really need to do here, that's a block and I provide a path to the lazy builder and I just need to add a create placeholder true. So that's what distinguished between my dynamic and then for the placeholder. And that was a snapshot that I used for the placeholder wherein you can see that this dynamic block has been identified by the big pipe. This is the answer to your question. Thank you. Any more? Yep. Why wouldn't you turn on big pipe? Why wouldn't I turn on big pipe? Yeah, so if big pipe is great, under what circumstances would you not want it? So there are the cases wherein you just don't feel the need that you have a really dynamic page. Like there can be cases where user can have a page to see the dynamic content after five second. You can have the maximum time page cache as five second rather than enabling the whole big pipe module. But is big pipe not better? Big pipe is better but why to have a whole module and creating the placeholder when we just can quote in the render API as a max age? Because anyhow big pipe is using the same render API, correct? So if we are just want to have the, when we have a low significance of the dynamic content there, we can just have the max cache, a max cache as just five seconds or six seconds rather than having the big pipe to work through all the same render API and create another thing, another render API. A follow up question then. Does it play nicely with engine X and Varnish? I haven't tried it yet through the engine X and Varnish. Thank you. Any more questions?