 First session in Drupal Camp London. Right. Yeah. So thanks a lot for joining in. I am actually here to talk about Drupal 8 with cache and big pipe. Looks like a big line, but yeah. It's quite simple. So who is me? I am actually Nikhil Sukul. I am a senior Drupal architect working in Feichi Solutions. Overall, I'm working for that 17 years now in IT. Big time. 8 plus years in Drupal, already 8 plus experience in Drupal and maybe more and long years to come. So let's dive in. Have you read this phrase around the world in 80 days? Everybody might have read this book, right? So what actually people require is they want their site to be around the world in eight seconds. Is it? Not now. Maybe three to four years back or five years back, everybody wants their site to be loaded less than 10 seconds. That's what their aim was. And then after that, they said, let's load our site in less than five seconds, around the world in five seconds. And now the error is that people say, we should load the site around the world in three seconds. Was it really true? We need to load the site in less than three seconds. Well, if you see the survey, they actually say that 40% of users abandon a site that takes more than three seconds. So it's absolutely critical that our site should load in less than one second or two seconds based on our mobile browser or based on our desktop browser, because nobody ever cares about if loads are longer. So what to do about it? So initially, when we had such kind of problems when Big Pie or any other technology was not there, conventionally or traditionally, how we were actually doing it. So what we're doing is we're actually saying, load my page faster. So everybody was saying, please load it faster. They don't know how much faster, but they wanted to make it faster. They wanted to be very, very fast. As soon as I see it on my mobile, it should be fast. Doesn't matter three second or four second. I don't care what my network speed is. I don't care what my ISP provider is, but I want to make it faster. So what should I do? So what I started off with back end. So the first thing that people realize is, OK, we have to make the page load faster. So what is our technologies all about? We have a back end, and we have a front end. So what is back end is? The back end can be any technology, right? It is a series of servers, maybe Apache, maybe Nginx, maybe any other server in the back end. Let's optimize our back end. Optimize in such a way that is actually rendering or getting the content to the browser very, very fast rate. So if your back end, which is source of data, which is going to the browser, is optimized, it will throw the content in a faster rate, and then my front end will be faster. So the first thing what we did was, or what we thought to do was, we first actually optimize our back end. So what do you optimize our back end for? There are a lot of ways to do it, and there are various ways to optimize back end. Apache was actually having modules for, you can actually zip the files and throw it to the browser. The next to it will be less, and then you can get the files in a very, very straight way, faster rate. Your HTML will be passed and shown in a faster rate. So there are various ways to optimize back end, and that was a traditional approach when somebody says, I need to page load faster. Being 16 years, I also did that initially. I was very, very enthusiastic to dig that. I actually optimized the back end. See, your front end is very fast now. I've optimized the back end. Everything is coming from back end. Very, very fast rate. You can actually see it very fast rate. But that's not going to help us more, because we also optimized the front end. So what actually technologies come from front end? There are many, many more, but for few, we have to minify. So we have to less our CSS files, the JS files, the images, make it minify. The size of the CSS is very small. So the size of CSS is very small. It is pushing to the browser. It is minified. And then the lateral latency doesn't come. Sprites, and that technology came in the picture was sprites, so images need to be sprites. So actually the front end is actually more optimized. You get the images very quickly, and then it is sprites. Now HTML5 came in the picture, we get offline caching. So once it is cached once, then HTML5 is more of cache and all, and the page becomes loading very fast. Cleaner HTML, yeah. So definitely we get rid of tables. We came on to div, and now we are going for HTML5 tags. So our HTML is very, very smaller, rather than a view source which is keep on loading and loading and loading, we have a view source which can be, we can see it. So smaller code, less code, less byte, fast load. This was one of the few other things which it does for front-end optimization. But what exactly the end user really wants? What do you really want? If you're an end user, you're a non-technical person. What you really want is that as soon as my site is loaded, or as soon as my page is loaded, I want to interact with it. So I want those parts of the page to be loaded first, which I want to interact with. I don't want to have a white page with saying keep on loading, because I can't do anything about it. But as soon as I have something on my page, which I can click on a button and do some interaction, I'm happy with it if the rest part of the page is not loaded yet, right? So this is our experience. This is what we require. This is what end user require, performance versus perceived performance. So optimization of backend, optimization of front-end, all nerves down to only one conclusion, that where the users are clicking and what exactly they are seeing, what part of the page they actually wanted to load first. And if that load first and the rest of the part is still loading, they don't care right now. They can see the part of the things what they're really interested in and they can use it. And that's what Facebook did. That's what actually the technology of Big Pipe came. But before Big Pipe, there was another one. Lazy load. So I have these talks in various conferences about Big Pipe and the first question comes in the mind of everybody who is very technical and working for a long time in the industry. Lazy load is there. Anybody is familiar with lazy load? Yeah, most of the people are. So lazy load is actually a technology in which you can actually have the page loaded and then from Ajax request, rest of the part of the page is keep on loading. It's Ajax request. If lazy load is already there, then why we have this Big Pipe thing going on? And lazy load is good enough for us, right? There will be some problem with lazy load. That's why Big Pipe came in the picture. So what is the problem in lazy load? It has few drawbacks. So traditionally, lazy load was actually great for images. Traditionally, though people have hacked it and people have created lazy load for content also, we have githubs for that. If you can go and check it out there, you'll find it. And secondly, the most importantly, it files separate HTTP request per lazy load, which means subsequently it increases the number of connections of the backend server. For the backend, it's new connection. For the front end, guy is just Ajax, it is coming on. For the backend, it's like keep on hitting for each and every connection for that particular part of the page. So it's like if I have a site which is having millions and millions of users and I have a lazy load on top of it, think about the performance of the page. I mean, if one page is having 10 lazy load, that means one into 10, you have to multiply that performance impact. So that's where the lazy load was having a problem. The lazy load was actually having a problem with respect to Ajax. But it's not that it doesn't work now. It is still working, people are still using it, but we have a better thing than lazy load. So what is the solution of that then? Introducing big pipe. This is what happens in big pipe. So in big pipe, you have one HTTP connection for the whole process. So as you can see here, you have a normal processing structure, normal page, you have Ajax scattered loading, which you can say lazy load, and you have a big pipe. So in big pipe case, you have only one HTTP connection. We can see which can actually pushing the data to the page. So the processing cost is less, normal structure anyway, there's no problem, but you can see the processing speed of the same as normal page here. And we're using big pipe on top of it. So what exactly is big pipe? So big pipe was founded by Facebook in 2009. So they actually give that particular phrase as big pipe. It actually uses something known as pagelets. So what it does is actually create sections of the page. Anybody here who have used Joomla before? So in Joomla, there was a particular ocean where you can actually have pagelets, not pagelets. They say portlets. So in Joomla or in other Java technologies, they say portlets. You can create portlets, small sections of the page. That is for the backend technology. We can actually create in Joomla the portlets and then the portlets get loaded as a part of the page. In Drupal, we know those backend things as blocks. So we have blocks on the page. And that blocks we actually load. But what I am talking about here, or big pipe is referring to is pagelets for the front end. So what they are saying is you have a page in front of you and I will divide the page in small pieces known as pages. So the idea was that several execution of stages will be sent, will be inside the web browser and the servers as pagelets. So let me define what pagelets is and how it works. So in a layman language, a pagelet does actually. So it does whatever lazy load kind of thing does. It actually loads the most important part of the page first. And the time taken of the page of the entire page is actually the same. That's why I said perceived performance. So if you actually go to the inspect element and click on network, you'll find the load page time is actually the same. Doesn't matter if it's using big pipe or not. But what happens is the relevant part of the pages or the sections of the pages are actually loaded first because that's what technology big pipe is all about and actually that is done via pagelets. So this is an animation which was created for big pipe. So as you can see here, big pipe caching, header, products, these were loaded first and then it started loading the other things. So see, this is the standard page. It is loading the entire page whereas in big pipe caching, the header, products which are the relevant sections are loaded first. And this is the favorite one. I think you might have seen yesterday if anybody have attended the session. So here, oh, let me do click on it. So personalized low cacheable, this is Rupal. This is personalized low cacheable, personalized low uncacheable. And then you can go down and check this is the comment section. It's personalized fast and uncacheable. This is this section. In tradition approach, if I click on it, what happens? And this is the big pipe section. So 0.5, 2.5 seconds, the relevant sections are loaded. In tradition, it is keep on loading because it has to load the entire page. The total amount of time is 6.50, which is the same. But actually what happens is you have the time difference the same, but the relevant part of the page are loaded first. So see, in traditional, if I have cache also, it's 3.25. And in case of big pipe, it is again 3.25, but relevant part of the pages are loaded first. So how big pipe works? Big pipe works in all these seven, eight things. So actually the big pipe works in page generation process in several stages. It first do the request passing, which is a web parser, parsers, and sanity text checks their HTTP request. Data fetching is happened from the web server. So all the first three things are happening on the web server steps. And then from four to eight is happening from the browser steps. So data fetching is happening from the web server. It fetches the data from the storage tier. You can say it's a database layer and any other layer you can think of. Then markup is generated for the HTML. Then network transport happens from the client layer. So it goes to the network layer. The response is transferred from the web browser, web server to the browser, sorry. Then in the browser what happens? The CSS started downloading because as soon as the request come to the browser, the first thing will happen is it will start downloading the assets, the CSS images and all. It will do that. Then the DOM tree's construction will happen on the browser, which means the CSS started now, the estimerization and the DOM structure will start alimenting on the browser itself. Then the JavaScript will start loading, which we need to parse and we need to run. And then the Java will execute. So if you think of this way, it will be something like this. So on the server side, you have request parsing, data fetching, and markup generation. And on the client side, you have network transport, CSS downloading, DOM tree construction, CSS styling, NGS download and execution. Now, if you think of in the big pipe perspective, each pagelet must go through all these stages sequentially. But each page, each particular pagelets are actually worked simultaneously. So every pagelets will have all these things to be done, but all will be done simultaneously. So the effects to the browser is actually very, very good. Because you are able to see what exactly you require, though every page will have all these stages to be done. So let's talk about big pipe in Drupal. Okay, so how to use big pipe in Drupal? We have a module, big pipe. I think this was done by Fabian and it was actually done by Vim. And Fabian is the one who is the contributor there. So thanks a lot for him. So we actually have to enable big pipe in Drupal. And also, we need to enable internal dynamic page cache module along with it. Okay, so let me first talk about what happens in big pipe in Drupal. So big pipe in Drupal module is actually dependent on the very, very good module of caching, which is available only for Drupal A, which is this internal dynamic page cache module. What it does is actually, it allows you to prioritize the content which is more dynamic or which is not dynamic. You are not the one who are prioritizing it. You are not the one who is getting a screen. Can I load this content or can I not load this content? This is done by Drupal itself. So there is a render caching API which is done in Drupal A specifically. It's an awesome API. What it does is it's actually analyze the page and find out what is the most dynamic content, what is the least dynamic content or the static content. Based on this render cacheable API, this particular dynamic internal cache module works. And based on this concept, big pipe actually takes data from here. So big pipe whenever they ask us to install, they also say that please install internal dynamic page cache along with it. So that the big pipe will work seamlessly on that particular ground. And there is another module. If you open and see the Drupal 8 core, you have internal page cache. Internal page cache is actually for anonymous user if you see the description. But so it is not dependent for big pipe. So it's not required that when you're using big pipe, you need to enable it. You can enable it for anonymous user anyways. That works well for anonymous user's experience. Okay, so how big pipe works in Drupal? So what happens is it actually turns rendering into placeholders. So without big pipe, Drupal will use single flush. I think we already saw that particular slide of GIF where we have standard page. It is single flush. And we have another page of big pipe which is actually loading the relevant content. So without big pipe, Drupal will use single flush strategy for replacing the placeholders and will not send a response until all the tokens are replaced. So it will keep on waiting and when all the tokens are replaced, then it will send the response at one stroke and you will see the entire page. But whereas in big pipe, you have initial page load because you have placeholders. Now how the placeholders will come in the picture, will actually come in the picture with respect to render arrays API which is already available in DA. So when you have big pipe enable, it also knows that based on the render array API, what are the sections of the page which are more dynamic. So those kind of pages will be flush out and then the placeholders keep based on that, placeholders will be starting load and then you will see all the parts of the page. So the key parts of the page will be load first and then the expensive part of the page will be loaded. So this order is not decided by us, this order decided by the render API of the Drupal it was already available there. Okay, so let me push to a demo. So this is my site. I don't have any big pipe here. And this is my site with big pipe. So if you see here, it's a standard normal devil generated page. Nothing much is there. If I go and nothing is aggregated, sorry about it, still loading. It's a pretty old system, bear with me. Maybe of 90s. It doesn't take parallel process it seems. So come on, 42.39 seconds. 1969, okay, let me click on the homepage. This is without big pipe. Bear with me, I don't think it will be the exact second thing, this is just for demo because I don't think my system is good enough to give you the exact speed, but yeah. So without big pipe for this page, it's actually saying 16 seconds, it's too bad. Okay, I don't know what will happen here. It should be the same, but let us see. So I will go to the same page again. It has the same database, same content and everything. The only thing is, additional is big pipe module enabled. Nothing else, everything else is the same. So let me click on that, click on network. So it started loading the page first and then it started loading the other things. You can see it's coming everything in the background. So the small part of the page was started loading already and then it started loading the rest of the part of the page. So it's actually 18 seconds, so it's even worse than that. But what I wanted to tell you was is that on the right side, what you see here, when the pages start loading, this was still loading. This was still loading the content. Where in that case, when this page start loading, it was that particular right side section was already loaded. So what I did here in big pipe, so let us see in the model section. So this is D8, we have modules here, graphs of modules, internal dynamic page cache. This was enabled, internal page cache, it is also enabled, but this is actually for anonymous users and where does big pipe? Here you go. This was big pipe. What I did additionally, I did nothing additionally, anything else, I just download the module big pipe, enabled it here, and I enabled one more model along with it, which is required is this one, internal dynamic page cache. That's it, these are the only two models enabled, rest everything remain the same. I didn't do anything else for this, but still I was able to get some kind of performance boost as perceived performance boost in my page. Because in a normal scenario, this page will be loaded and along with it, this particular all the sections will be loaded. In case of big pipe, you will have internal dynamic cache plus big pipe, it will actually allows you to have that perceived performance effect. Okay, so let us see what happens in the module. So this is the model of big pipe in Drupal. So how many folders it has? It has JS, big pipe.js, it has some source, definitely once the guys who already knows Drupal 8 might be knowing what exactly this structure is, and you also have some test, and you also have big pipe. So in big pipe, you have info, so let's start with info. What is the dependency of big pipe? Any dependency of big pipe here? No, what happens in Vyamel? Yes, so there is a dependency in libraries for big pipe.js. This is being modified with respect to Drupal. It is not that particular standard big pipe JS which is used by Facebook. It has a lot of properties with respect to Drupal, which is done by Vyman and Fabian, thanks to them. So which is actually based on our render API thing so that we can actually render the things properly. It has dependency on jQuery anyways, you can see that, it's already in the code, and it has routing.Vyamel which is actually going for a path which no JS and no cache and those kinds of stuff are there. So if I go to a module file, or let's say let's go to the JS file first. So in the JS file you see, it's very much specific to Drupal. The functions is actually creating an anonymous function which is actually having a Drupal setting. And then we have a place holder replacement, so this is what I was talking about, that in big pipe you actually have a technology for place holders. So first thing what they will do is, the pages will actually have the page place holders and the place holders will be replaced by big pipe. But what happens in traditional manner, in lazy load or any other manner, the place holders are done in a single flush, traditionally by Drupal. So all the place holders will be done at once and then the page will be rendered. In case of big pipe, this is a JS file which actually does it based on the priority. So it actually sees the content and based on that and do the parsing and everything. This is a particular JS module file, sorry, JS file which is being used. They process the document also and then based on that the big pipe process happens. There's a time interval also set there for big pipe process. It is actually 200 for now. And then you have jQuery and all the other things. So in the module file, just to quick thing for module, we have a big pipe help and we have big pipe attachment things there. So there are a lot of sessions, configuration which require in big pipe. So that's the way big pipe actually works a lot with it. So yeah, this is what big pipe is. Any questions? Not right now. As per the big pipe current version, there is no configuration, zero configuration for now. And what is being, what I have seen as per the render API, it actually done by automatically to see what is the dynamic content order is and how big is the dynamic content is. It is done by render API. There's a link in my slide. You can actually go inside and have a detailed look. Actually, we can have a different session for it. It's so big to understand that. But yeah, so they have a particular way of doing it. They have cache tags and cache APIs and all. You can actually go through each one of them and then you can understand how exactly they do the ordering on it. But big pipe is actually taking on top of it on that. I haven't installed it in a corporate site yet. More of a sandboxing thing I have used it in. And one of my corporate site I have used it. Till now I haven't got any downside till now. But yeah. I have one more question. Yeah. Looks like, because as per the code, it looks like a standard Ajax call. But if you compare with lazy load, they say it's just one HTTP request rather than having separate HTTP requests for all the Ajax calls. So if you build around the code of big pipe module, you find that Ajax is actually there. So it's not that it's not doing Ajax at all. It's actually doing it. But the way it's actually doing it is actually pipelining it. So at one stroke itself, it's actually getting on from single HTTP request rather than having multiple of it. Yeah. How is doing that? How is managing to do that? So there's a big pipe JS file I told you I showed you already. That is a core of the Facebook one. They have modified it on top of it to make it a Drupal wrapper on top of it. And that is having that sequence to how to do it. So the magic is actually coming from that JS and then Drupal is actually on top of it. The rendering is coming from the API. So all the things follows like that. It's like a process. Clever new technology, definitely. An awesome one. Yeah. Actually then you've got the single request going from JS to the backend. Yeah. The backend is returning everything in one response and then the JS is intelligently. Intentantly rendering it. Yeah. How to render it. So is it possible then that if you have one particularly slow part of your backend that could delay everything because you still wouldn't get your response back in time. So in some situations it might make sense perhaps let's say to have two requests not lots like the original lazy loc but perhaps two requests one for the really slow backend. I truly understand that that is required or that may be possible. We have to see about the backend also. So this is the ideal scenario in which the front end is optimized but definitely we need to think about backend anyways. Yeah. Yeah. I'd say you can sort of use pager but it goes to the page. Could that be another option? I think. The package is all very slow stuff. So the question is whether we can implement big pipe of normal Drupal Ajax request. This is what I think is anyway big pipe will be in the core in Drupal 8.1. I think they will be doing that maybe once they will be doing it with respect to Drupal. Maybe that is the next step which we are doing. Right now we have to additionally install this model and do it for it but maybe it will be in there in the view source or in the views in the code itself in the Ajax. Because anyway internally it is anyway calling the Ajax. The only thing what is happening is pipelining the request at one time and throwing it at once. Yeah. Does it work hopefully for anonymous users as well? Yeah so for anonymous users anyway we have internal caching system. There's two modules on it in Drupal.com. If you only had anonymous users would you bother with big pipe at all? I can. I can use a big pipe. I can check it out in that but it's better experiences for authenticated users and we have a trouble authenticated user in Drupal. We know that already for a very long time. This is a very good solution on it. Yeah. My HTTP 2 isn't really good but I believe it kind of features the idea of pushing. I wonder if there's been any movement in this direction of we know from the front end we send our request to the back end and then the back end gives whatever it can as quick as it can towards the front end maybe prioritizing the stuff you want quicker. Excellent question. But I don't believe I have an answer for it right now. But yeah. Any other question? Right. No it's not a strict dependency but what has been assumed is that the render API actually have the priority things in there. So when you enable big pipe and if you enable that particular module of internal dynamic as in fact if you do the readme.txt of big pipe when you are enabling it it actually recommends that. It says that when you have to use big pipe please enable this module because that particular module has all the render priority which actually does it and then the big pipe works efficiently. So that's why we have to enable it and that's what we see. Anything else? Anybody else? Yeah, thanks a lot. Thank you. Thank you.