 So welcome to our nice big pipe talk today. I hope you all had a great Drupal console far. And I hope we can start this morning after the keynote with a nice little session for you. So what is this big pipe thing? And I know, because I saw it this morning. Actually, it was not me, but him, but anyway. Here in New Orleans, this is a big pipe. So no, no, no, no, no, no, no, no, no, no, no, no. This time I get it right. It's this. This is a big pipe. No. OK. But maybe this, or this. Is this a big pipe? I'm not really what we are thinking about. So I know, I know, I know. This time I got it. It's a pipe of a steamboat. It's this. This is a big pipe. Not wrong again. OK. This time I'm really, really, really sure, because I saw this interview with this Fabian France. It is the Gandalf's big pipe. There are smoking rings and maybe not. So what big pipe is, and if you ever wondered why is there this kind of thing with the streams and water and everything. You remember Drupal is actually a drop. So this is kind of how a page request is looking like. You're having this Drupal icon, and this is your page. And you always have to wait a moment, and then it comes in one big blob. So this is how page handling at the moment, Drupal 7, Drupal 8 works. But now if you were using Drupal 8.1, who if you use this Drupal 8.1 already? OK, cool. Some people have already started. And who if you have tried out big pipe already? Some people. The rest, hopefully, all after the session, because it's exciting. Then this actually changes to this. So it gets much faster. And you see there's not just one drop, but there's several drops of data. And how that works in detail, that we'll just explain in the session. Yeah, good morning. So we'll be talking about big pipe and explain you from a very high level to some level of detail, so that it should be clear to anybody, even if there's people here who don't use Drupal. It should be understandable. Because really it's not something that is highly Drupal specific. It is something that is a technique that we brought to Drupal and may work in a way that you don't have to think about. May it work in a way that you don't have to write custom code for it. So we'll take you through it. And hopefully by the end of the session, you will all want to try it out and see what it's about. So big pipe is related to performance. And when talking about performance, I'm sure any, well every single one of you have considered the differences between front end and back ends. And front end is of course about the fetching, the parsing, the executing, the rendering of CSS, JavaScript, images, fonts, all sorts of assets. And the back end traditionally, well in fact it is only about HTML. So basically the front end has to do lots of things dealing with all those assets. And the back end has to do just one thing, HTML. And so that actually already kind of suggests it, but really in reality 80 to 90% of the time that it takes to render a page to actually do a request to seeing something useful on the screen is spent on the front end, not on the back end. And so we really can make far bigger gains on the front end in terms of speed rather than on the back end. And we very often forget about that. That is still a relevant thing. And the other aspect here that we are aware of, but not everybody is always considering is performance versus perceived performance. Because performance usually what we think about in terms of performance is how many milliseconds does it take to generate a response? Is that really the thing that really matters? In the end it actually is not that important. What matters is the perceived performance. How fast does a page feel? How fast do you see something that is useful? On the page, even if not maybe every single detail has been loaded. So perceived performance is a thing that really matters. Why don't we think about it more? Because it's far more difficult to measure. We measure the things that are easy to measure. We measure the time to generate a response. We measure the time until the entire page is loaded to window load events. But that's not really what matters in the end. So perceived performance is something we should be talking about more. And that's what is really relevant for Bigbyte because that is what it improves. So a few measures that are very valuable are these four and they are in the order of being relevant while handling a page request and loading a page. The time to first byte. So that's the time between doing a request and starting to receive the very first byte of the response. So the total waiting time until you get something back from the server. The next one, TTAB, time to asset prefetching. That's the one you will not see in probably any other presentation. It's one that is particularly relevant for Bigbyte because that is the thing that it enhances the most, if you will, because browsers actually are able to start fetching assets. So the CSS that is in the top of the page, the JavaScript that is mentioned in the top of the page, and is able to start fetching those even if maybe the bottom of the HTML is not yet available. So time to asset prefetching is super important because it allows the browser to start doing work while the rest is still arriving. And that is absolutely key, particularly for Bigbyte. TTI is something that you will see in many presentations and many companies, but sadly only the bigger companies with big software engineering departments, if you will, are actually using this measurement because in the end what matters is the time to being able to do the interaction you are there to do, whether it is accessing or reading a blog post, whether it is being able to use a particular form, whether it is the ability to start interacting with a fancy to-do application and start being able to enter a new to-do entry. So the time to interaction really depends on the particular application, but that is really the thing that matters because if maybe some detail far down on the page is not yet available until maybe two seconds in, but the actual interaction is available right away in half a second, that is what really matters. So depending on your use case for the very most important things on your site, ideally you would define what is the interaction I care about it and start measuring when that becomes available, that is what really matters and that's where Bigbyte helps significantly. And then the last one, the page load time, that's just a total load time that we all know, that's still important to make sure that you don't have anything excessive that is taking minutes to load, for example. So it's still a relevant thing, but it's important to also look at the other measures. And so when trying to make your website faster, typically the traditional front-end optimization still applies to optimizing images, minifying JavaScript and CSS, pure HTTP requests, and yes, that also still matters in HTTP too, sadly, until today. The promise is that we wouldn't have to think about that anymore at all, but today the proof shows otherwise. Hopefully it's just a matter of optimizing our HTTP to clients and servers, but for now all of the typical optimizations are still relevant and still necessary. But if we do those front-end optimizations, they actually matter because typically 80 to 90% of the time to generate or show a page rather is spent on the front-end, but if the backend is already very slow, say it takes half a second, a full second, maybe even multiple seconds, which is not unheard of in the Drupal world or outside of Drupal, sadly, then the front-end being super fast, let's say the entire front-end can load in 0.1 seconds, superb, but you're already taking two seconds to just get an initial response, so it doesn't really matter anymore. And so what BigPipe is about is that intersection of front-end and backend performance. BigPipe cannot magically make something that takes 20 seconds, say. Everything, it cannot make something that takes 20 seconds available completely in one second. It's impossible because it was taking 20 seconds, but what BigPipe can do is bring up a lot of the things that aren't staking those 20 seconds, but the parts that are actually the same across users, it can bring that to the end user much faster, which means that the browser can start rendering that part, which means the browser can start fetching assets, start rendering images, and so on much faster. And so BigPipe is really at the intersection of front-end and backend performance. So a concrete example would be BigPipe versus traditional, so the traditional page loading model. Traditional only doesn't send anything until the very end, so it's calculating, calculating, calculating, and then it sends everything. BigPipe, on the other hand, it starts a bit of initial HTML so that assets can start to be fetched, then it sends another chunk of HTML, another chunk of HTML until it's complete. So it's taking the same total amount of time, but it's delivering it in a far more efficient way. So concretely speaking, that would mean, for example, that your page header with the menus and the title, the logo is visible very, very fast, 150 milliseconds to the screen, instead of 350 maybe, or maybe even more, just one concrete example. So really changing the backend can improve perceived performance, and that's what this is about. So Fabian is going to talk now a bit about the differences between BigPipe and other systems to improve performance. Okay, so what we're doing here is we are comparing different things. There's kind of, in Drupal 8, we've integrated several methods to do things. Obviously, there can be code caches, so there can be an un-cached page, or someone says, well, who needs this caching? We just turn it off. Then obviously we have the page cache, which has been in Drupal since Drupal 3.1, so that had always been kind of at the heart of Drupal, but with Drupal 8, the page cache has become way more awesome, thanks to them and other contributors. And then there's dynamic page cache, which was made possible by the whole caching re-architecture, re-integrated, which is working so transparently to you that you don't even notice usually. And then there's obviously BigPipe, and we'll compare how those different methods have different latency times for the measures that Wim had already laid out. So for the un-cached regular page, Drupal needs to do a lot of things before replying, because the backend is doing everything and calculating everything. Here's a node, here's a block, here's something, here's another thing it needs to render, so you have typically hundreds of milliseconds on the backend. So kind of all the time to first buy, time to the assets pre-fetching, the time that the user can interact can be really slow in that. So, and what then happens is kind of that dreaded, the user clicks on a link and the page is loading, loading, or if he's coming first to your page, it's that dreaded white screen, where the user is seeing that white screen and their study said if a user sees such white screen, it takes way too long, they're just closing the window and going to some competition now. The page cache, there, Drupal needs to do almost nothing before replying. We usually have time to first buy it's smaller than 10 milliseconds, obviously there's always network latency. Then because we are sending this whole chunk like the Drupal.con you saw, we are sending it directly, there obviously the browser can directly start fetching their assets as well. And depending on your front end code, how much JavaScript you have, how much you are initializing on the page the time to interact can be hundreds of milliseconds or less. In Drupal 8, we've made it so that for anonymous users there's no JavaScript on the page, so we don't have to deal with that and then the time to interact is much faster. So, especially with CSS3 animations and other things that made CSS so rich, it can be very well worthwhile to say we are trying a no JavaScript side for some of our pages because that can improve the user experience. Then there's the dynamic page cache and that's new, it's especially important if you have authenticated users and it transparently works in the background. However, the way we've very securely, very safely integrate the dynamic page cache quite late in the game of Drupal 8, there's a little more work to be done. So the time to first byte is more within the 10 seconds to 100s of milliseconds thing. They are however initiatives to change that so there might be improvements in the future here. We just wanna make sure this is very carefully just working for you so that you never have to worry about it and then obviously the time to SHP fetch is also within the 100s of milliseconds and the time to interact is pretty high. So that's for authenticated users and that's all nice but with the dynamic page cache what we have, we have a page which has all the information but for certain things we are coming to that a little later there are things that are for example personalized or otherwise not fast or not cacheable in such things we have placeholders for but actually we have to execute those placeholders when we are getting something out of the dynamic page cache. So let's say you have one slow block, one slow block on the page that's uncacheable but your CTO, USEO, all the bosses are saying we need this block, it's so important to our business but it's making your whole page slow and that's kind of sad in everything because we are kind of, we know the data and then we have it already and that's where Big Pipe comes in because with Big Pipe we are just sending everything we have and then we are rendering your slow block and then we are sending it once we have it. So and that's how we can have, I'm liking to speak of that like the fastest triple ever in that with Big Pipe because then we can have four authenticated users time to first bytes of low tens of milliseconds typically like 1540, the time to asset prefetching is then also within the tens of milliseconds because we are sending what we have as soon as possible in the time to interact depending again on your front at hundreds of milliseconds. So especially for those authenticated users this slide still says it's a candidate for Drupal 8.1 or 8.2, but actually it's in 8.1 as an experimental module you can play with it today. Isn't that nice? Yeah, and here's a nice little demo of Big Pipe. So in this scenario there are several things that are personalized slow and such uncashable because on this music website we wanna give recommendations and as Trees said in his keynote it's always important to give much more streamlined things but as you see Big Pipe's already there while the traditional model is still calculating in the background and that's what I said. There's one slow really business important bug block that's making your whole site slow but with Big Pipe you can just wait until the blocks to appear in the end. But what's a misdifference that's sometimes thought is that Big Pipe is making server response time faster. No, it's not making it faster. It's actually exact same time in the end but we are using it more intelligently by ensuring that things we can already send we have been sending and that's pretty cool in that and even if you have users for example accessibility concerns or such that have JavaScript disabled there's a Big Pipe Lite version are enabled within Drupal by default then it will for example just send the page to that certain block or whatever within the dome that it can send generate the content and send the rest. So even with JavaScript disabled you can rehab some of the benefits of Big Pipe in that. Okay, so at a high level how does that whole thing work? How did we manage to do something that Facebook has been doing since 2010 and other big enterprises like LinkedIn have been starting to be doing and I just saw on Flickr they are also doing some Big Pipe stuff now but huge enterprises have huge budgets. How can it be that now every Drupal 8 site can profit from this by just enabling the module? And the answer to that is cashability metadata and that's basically dependencies. You are telling Drupal how to invalidate, when to invalidate and how you are varying things. To get into that a little more concretely cash techs are your data dependencies. I mean you all know that scenario you are having a web page and it has this one title on all of the pages. Everywhere and now the boss comes and says this title is totally not acceptable but you are within a huge traffic rush because all people are visiting your website so your only option kinda is because you don't know where the title appears is to do a Drupal flash all caches. Drush CCO all. And that obviously will lead to big problems for your visitors because they are then like, oh my God, a Drupal needs to rebuild all the caches and it's not necessary. So how did Drupal 8 solve that? The thing is in Drupal 8, the editor very relaxed goes to the node, edits the title, saves and all pages are automatically, all blocks, all views, everything is automatically expired where that one title was but nothing else. And that's what cash techs do. You are tagging your content and with that kind of relationship of data dependencies to render content you are able to do that and you never have to worry about that scenario anymore. And because everything in Drupal is cash tech the same works for your Vanish server no more nightly cron jobs where you are going a huge list of URLs that you are clearing from the CDN or if some people have used some big proprietary CDNs as well, then you might know that it takes like three to four hours until all edge nodes in the whole of the network are cleared which is very bad if things happen like like white bugs where CSS file does not appear or something and there are other CDNs however that have immediate invalidation and CDNs that are supporting such code server gate keys like for example, Fastly which was the other one, Cloudflare. Those CDNs like Drupal is using a special module for Fastly you would install the Fastly module for Cloudflare the Cloudflare module and then sending a special header and then again your content editor is changing that the CDN gets a special command and again you don't have to worry that that person in Asia is still seeing that old title so again it's kind of solved. Cash context are your context dependencies if you've worked with Drupal 7 there was a possibility for blocks to specify some basic caching you could say this is cached by user or this is cached by permissions this is cached by role this is cached by URL by page but it was not very granular and it was also sometimes problematic because if you were caching one block per user for example then suddenly your whole page was only cached by user and you couldn't no longer really use any page cached in that and that resolved those placeholders we're coming to a little later but context dependencies means you are telling Drupal how your content varies my content varies on the face of the moon or my content varies on some strange Indian ritual that's done some time which is a very complex proprietary calculation and you can do that you can just put in a cached context service for your needs you need to change something by some cookie you can do that right now you need to vary your content by a device mobile it's just a cached context away so this has become much more simple because we've created kind of like this cacheability meta data language and then obviously there are things where you say this should only ever be valid for five minutes so you are setting a max age of five minutes yeah and one of the nicer things in Drupal 8 one of the huge achievements we've made there is that this cacheability meta data is actually bubbled up during rendering that means we have this render tree but we have things that might be way below in the tree and but even if one of your blocks and it's not placeholder, it's varied by the moon we ensure that your whole page is then varied by moon phase so that all caches are synchronized in that way and there was a pretty big challenge but we made it yeah, oh yeah as I said cache text works perfectly with the reverse proxy we did talk about that in a lot more detail last year at DrupalCon Spain, Barcelona so there's this talk at WIMPS page to look at so if you are interested in authenticated user caching in the CDN, check out that talk oh yeah and here we come to one of the coolest thing which is like the rendering and isolation which is the lazy builders and the auto place holding so one of the big problems we had was let's say we have like this user block and then we have our page and what happened in Drupal 7 in that user block you would put in a user object that user object would have a field that field would have another node selected so you would have like this big chunk of data and you would need to put that in that would be very inefficient so what we did is we said that's not how it's gonna work there was a huge problem was in the pre-render cache pattern we are introducing something new that's a lazy builder and we are ensuring that whatever parameters you give are either cache context or those parameters you are inverting into the lazy builder have to be scalier values so you cannot just put in an object and everything and then say well Drupal will serialize it somehow and do something but we say if you want to render that block one then you have to do a lazy builder and then you have to just put in block one not like a block object then you have to load the block object but because we have that independence now things like ESI get easy now things like placeholdering get easy now things like dynamic page cache get so simple and then we have this really nice auto placeholder conditions that we are saying that for example you are having this block which is varying by session so you cannot use a normal Drupal page cache but you really need this block to be varied by session because there's some shopping cart or whatever but there's still the dynamic page cache to help you out because that one has a placeholder in this block placeholder for session but so that you do not need to do this yourself what we've made possible is we have auto placeholdering that mean you tell Drupal how things vary and Drupal is smart enough to figure out if something varies by session you probably don't want your whole page to be varied by session because it's a high frequency cache context that would lead to millions of entries of data so Drupal is auto placeholdering that for you putting a placeholder in then it can be dynamic page cache cache and then for your anonymous users where your normal page cache wouldn't work you can still have that work because you get that page out of the dynamic page cache and then just render this one block in isolation that's per session yeah that's the thing those two things make that possible and then you can even big pipe it as an step because why not just send the page already if you have it already outside there okay and here you see again that in a very nice diagram made by Sean McCabe which really shows that your user is getting so much more if you're having like already all the header all the product your footer shown and you are gradually building up the page for him then if he has to wait until this page has finally loaded because waiting, waiting, waiting, waiting, waiting I'm gonna close that side okay so and now Wim will show you how to use that thing cable problems here so Fabian went into a little bit more detail than was the goal at this stage but hopefully that was okay so given that you already have a good idea now how big pipe is able to work using cache ability metadata the ability to render in isolation how can you actually start using all of this how can you try big pipe on your triple site well it is as Fabian mentioned earlier in the very beginning it is very simple you just install a module there is nothing to configure because all the things that it needs in order to be able to function are provided by the APIs that triple eight itself has deep in its render system and everything that is rendered is already supposed to provide cache ability metadata based on the cache ability metadata triple is able to decide which parts are not good to cache because they would cause so many variations that it would not be efficient anymore so given all of that big pipe can just work without any configuration at all because it is just building upon the concepts and the patterns that we brought into triple core itself so if you're on triple eight zero which is the vast majority of you I saw install the big pipe contract module it is kept in sync with triple eight one and as Fabian also mentioned big pipe did get committed to triple eight one as an experimental module the goal is to get as much exposure as possible to get as many people to try it as possible we wanna make sure that there is no edge cases that we are unaware of we wanna make sure it works in every single case that it never can break your sites so far it is looking very good we are getting very few bug reports like literally less than a handful and only tiny things that are very easy to resolve so that it's looking very good but we want you to try it in even your craziest setups hopefully you don't have a crazy setup but in case you do we wanna make sure it works even in those cases so just go and install it however it's very possible that you're saying well I'm not sure I wanna trust this on my production side yeah you shouldn't try it on production immediately of course but try the big pipe demo there is a demo posted on my website and you can just go there so it's bigpipe.demo.wimliers.com you click start session because big pipe only works for authenticated users for anonymous users the page cache is much faster it's able to send a response right away so there is no point in using big pipe even and then once you've done that you can just let's say I've got two blocks here two demo blocks, demo one and demo two let's say I wanna make the first one take 0.1 seconds and the second one 0.2 seconds so as you can see it is showing the off-roll page immediately and then the rest is showing up later big pipe works for any block automatically out of the box because the way blocks are the way the block API works in Drupal 8 it guarantees that any block can be rendered in isolation which means it can be delivered by big pipe so try it install the big pipe demo module, this one try either the website, the demo here which is relatively limited of course but you can't play with different durations for the two blocks that are placed there you can install it using SimplyTest.me so you don't even have to install it locally if you don't want to but the really cool thing is if you do install it locally or on SimplyTest.me you can configure these blocks to have different HTML so that the HTML resembles your particular site your particular use cases so you can get a better sense of what it would feel like to use big pipe in those cases like if it's a very important piece of content that is in there how does it feel if it shows up later do I need to make design adjustments, those kinds of things and you can just play with the query string to turn it off to really observe the difference between big pipe enabled or not very easily so to get started, try the big pipe demo but the message here is just give it a try because you have nothing to lose there's only two kind of problems that you may encounter the first one would be jumpiness like it is a valid concern that because big pipe is causing content to show up later well that might cause some jumpiness depending on how your site design works because it's inserting content in a certain place if the place was not reserved it could cause some content to be pushed down well in that case you should probably make your CSS more robust because it's not really a problem really induced by big pipe usually it is the same problem when your site is being loaded on a slower connection on 3G, on Edge, while you're on a train the page is loaded partially and then more is coming more is being received, more is being rendered then all of the things are jumping around all the time like I just did myself that's the thing you wanna fix anyway so if you fix it for a big pipe it's just more prevalent it's more easy to observe with big pipe but you actually should be testing with slower connections anyway so just fix those situations and then you don't have any problem there the only other thing you may encounter is that something is not being delivered via big pipe it works automatically for any block that you create any custom block, custom code blocks also so in that case I would say simulate it first in the big pipe demo like the generated HTML, put that in the block see what it feels like and then you have a sense but then the next step would be to fix your code and use a lazy builder as Fabian explained so this is pretty much the entire set of problems you could have either jumpiness which is a problem you should have fixed anyway and it makes it easier to observe it or slow code is not being delivered by big pipe well in that case you just need to adjust the code but the usual case is actually you won't need to do that so really the message is play, analyze, simulate and adopt play with it to see what the difference can be analyze your particular site does it have uncashable content does it have personalized content if so you probably want to simulate it and install the big pipe module itself and just try it locally on a testing environment or install the big pipe demo module on a vanilla Drupal site and see what the difference it could make and then when you try to adopt it you may need to fix a bit of cacheability metadata if you have custom code and you didn't specify the correct cacheability metadata like for example if something is actually varying by user or it is varying by session but you didn't specify that corresponding cache context big pipe doesn't know, Drupal doesn't know and so it may end up caching incorrectly well in that case you need to fix that but that's about it so given that you now have an idea of how to start playing with it which is just very simple give it a try you don't have to do anything complex next step is like how does it actually work how is Drupal able to do this in some more detail so there's four key parts to this and Fabian already mentioned a few but let's put them together to have a better sense of how they actually interact with each other and how they help bring us to the point that we can do this automatically because as Fabian mentioned before there's actually others let me go back one slide actually do not let you read it just yet LinkedIn is using it, Facebook is using it there's custom code for Scala there's custom code you can write for Node.js there's lots of different implementations but the one thing they share is that you need to write custom code in order to be able to use big pipe you specifically every part of the page that you want to deliver via big pipe you need to write custom code to mark it up in a certain special way and call special callbacks and whatnot you don't need to do any of that in Drupal the only thing you need to do is provide cacheability metadata and make sure it's renderable in isolation and so that is a very key difference between other systems and Drupal because Drupal really wants to make sure that site builders are also able to achieve cool things this is pretty cool this is not achievable with anything else because otherwise you need to know how to code and not just basic code pretty complex code so the four things that are key cacheability metadata so the tags, context and max age plus bubbling the bubbling of those three things so that describes the dependencies we need to know the dependencies in order to know whether something should be rendered later or not whether it is personalized or not that's what that tells us then the ability to render in isolation just like you have pre-render callbacks in Drupal 7 and before which still exists in Drupal 8 by the way the difference between pre-render and lazy builder is at first sight small they serve similar purposes but the difference is that pre-render has zero restrictions so you can pass around objects which means it's not actually renderable in isolation usually pre-render callbacks are calling into global states and that's what prevents us from delivering it later so lazy builder callbacks ensure us guarantee us that it can be rendered later auto place-holding if the first two cacheability metadata and isolated rendering are both met and the cacheability metadata indicates that it's poorly cacheable so either completely not cacheable or cacheable per user which may cause millions of variations or varying by session which can cause even more variations well in those cases we wanna turn it into a placeholder so it doesn't slow the rest of the page down and so auto place-holding relies on the first two and then finally placeholder strategies so we have those placeholders already in Drupal core even without big pipe Drupal core relies on placeholders that are replaced at the very last second to be able to serve pages efficiently and cache the majority of the pages efficiently in the dynamic page cache so by default Drupal 8 as it does today is it replaces the placeholders in response just before sending the complete response so it has everything the HTML ready let's say it took one second to keep it easy to keep it simple and then there's still a bunch of placeholders in there like say for example the high user or the shopping cart or any of those kinds of things and then it replaces all of them and then sends the entire result in one go that's the current strategy but big pipe just adds a new strategy and the strategy is very similar it receives the overall HTML response with still the placeholders but it then sends it right away it doesn't wait until every placeholder has been rendered it sends that right away and then renders each individual placeholder and as soon as it becomes ready it sends it over so that's just it Drupal already provides infrastructure to have different strategies big pipe is just an additional one so conceptually speaking what big pipe does is it sends the initial page directly and it gets it from the dynamic page cache so page cache and big pipe are kind of on the same level in terms of optimization in the sense that page cache is as fast as you can get for anonymous users it's just it's completely ready Drupal assumes that the responses are the same for all anonymous users so that's what page cache does it's as fast as it can get big pipe it layers on top of the dynamic page cache which can cache the skeleton the parts of the page that are not placeholders and so then big pipe can send that right away it just receives it from dynamic page cache and sends it and then it starts sending the big pipe placeholders in the order they appear in the DOM so conceptually speaking these two things are all that big pipe does and conceptually speaking that's all you need to know if you wanna learn more about the technical details this intimidating diagram is awaiting you it's called the Drupal 8 render pipeline which explains in perhaps excruciatingly detail how it all works it also explains big pipe it explains it not in a big pipe specific way this is just a full Drupal 8 render pipeline from bootstrap to serving a response until the very last byte until the very last moments so if you wanna learn more about that it's documented at drupal.org there's a talk about that as well if you are interested in that and then the very very important thing is that unlike well Fabian already mentioned Facebook they have a very big engineering team LinkedIn the same so those companies are very big teams they can afford big investments they can afford lots of infrastructure surely Facebook has tens of thousands of service LinkedIn probably the same well most of us who has a thousand service I don't think many people will have okay so the whole point is you don't need any infrastructure this is available for any site small and large like for a non-profit or your local sports club to very big sites for governments the only thing you need is the ability to stream responses and not have buffering and by default Apache actually doesn't do buffering so by default any Apache installation is fine Nginx actually has the ability to explicitly disable buffering so any Nginx installation out there will is guaranteed to work with big pipe because big pipe already sets that header so you can get started right away you don't need Farnish you don't need a CDM you don't need anything except the web server that doesn't do buffering so that means it is for hobbyists and enterprises alike it's a big step forward for everybody and you don't need to learn how to set it all up in case you do have buffering you may be wondering does do things break well no they just go back to the old way because in the end what happens then is you get the entire response in one go which means you didn't start receiving the initial parts sooner so nothing breaks it's just back to the old slower behavior so if you have a crappy proxy in between you so for example in schools or in some businesses you have a proxy and you cannot use the proxy and some of those proxies unfortunately have buffering enabled in those cases you won't see the speed boost you will see otherwise but at least it still works everything is guaranteed to still work so a few of the edge cases that some of you may be thinking about and wondering if they actually work what about placeholders that aren't HTML elements like a div or a image or whatever like HTML we can easily query for we can use query selector all and find it efficiently using big pipe JavaScript that's what it does effectively it finds some HTML and replaces it but what if the thing we need to replace is somewhere deeper like for example HTML attributes containing for example the forum action URL which is one of the examples that is in fact a placeholder or maybe a CSRF token in a URL in an attribute how do those cases work because actually those can slow your site down significantly as well so we want to make sure that those also work and they do as I will show in a second another example is if JavaScript is turned off how do things then work Fabian already mentioned that case but that's really crucial that things still do work and big pipe in fact detects that case itself automatically it detects whether JavaScript is off and ensures that everything continues to work just fine well in both of those cases so in the first case we replaced those few placeholders that are very tricky that are inefficiently replaceable with JavaScript in the second case every single placeholder cannot be replaced by JavaScript because JavaScript is not turned on well in those cases we replace it with our JavaScript as Fabian explained we send the HTML until the first placeholder we encounter we stop sending so we don't send everything including placeholders to the client, to the browser so we send just a part into the first placeholder work to replace that, send that placeholder then send the subsequent HTML into the next placeholder so we have many many small steps instead of being able to send a bit more at first which is unfortunate but at least you still have streaming so it still makes things significantly faster so in other words big pipe is always an improvement even if JavaScript is turned off so let's dive into a bit of the code details and Fabian will explain that to you okay so to make your code not only big pipe compatible but generically Drupal 8 compatible you have to take care of some things whenever you are rendering something you have to think of our nice little language that's kind of the trade-off or the contract we are doing here in Drupal 8 you have to tell us what you are doing if you have to give in Drupal 8 the information so that it can do all those things for you so in practice there's a little thought process you can make a habit whenever you are rendering something you must think of catchability and when it's something that's expensive to render and it's worth caching then you are setting cache keys on that object obviously so very simple render caching you just set the keys and it works so and then the other thing is if this is varying by something a combination of permissions, URL, interface, language whatever then you need cache context so user permissions, URL, just edit fortunately Drupal adds it already for many things automatically that's very similar to HTTP, it's very header so and if you have something it causes the representation of the thing you are rendering become outdated like the editor edits the node then you need cache text for example for the node you are rendering right now and when it becomes outdated time-wise then you are adding a max age the standard for that is to cache permanently so all relevant objects within Drupal have this wonderful cacheable dependency interface where you can get the cache context cache text and max age and that's implemented by almost everything in Drupal configuration and all entities content config, access results, block contact condition plugins, et cetera, et cetera so and the other thing is you need to ensure that things are renderable in isolation blocks is one big use case but you might have like more complex layouts or something where you have something that needs to be also rendered in isolation so you have like this current temperature saying and the temperature from satellite to get that that takes quite a lot of time because you have to get it from satellite in this case it would run our ways so one problem was you would add a cache but it would still run our ways because Drupal would just execute this kind of render array the cache would never do anything for you because the marker pass already being created so that kind of pattern you used in Drupal 7 for that was a pre-render cache pattern you have some function that is building the markup for you with the pre-render and you're setting the cache for the keys and the max age so now the time from satellite runs only if there's a cache miss but it's not isolated because it can do anything in build I could put in like a big object from the database and that way it depends on something so if you want to have it isolate the way to go is to replace a pre-render with a lazy builder and you see the lazy builder you're setting like it's like a callback like you used to, you have a function and then you have the parameters and the parameters we are guaranteed that need to be scalar so that's how you do that so because all the calculations happen in the callback there's no more objects you are passing in there's just scalar values and that's very, very important because we need to cache whatever you are seeing here we need to put that into the database and you have to think if you don't want that to be big then make it small so once it's isolated and deferrable then we can big-pivot yeah and there's a nice little developer tool Wimvroad well I wrote a prototype as the URL says so I think that in some cases this can become overwhelming like if my page is varying by session by user, by URL, by whatever what the hell cost my page to vary by that thing or if my page is tagged by a certain cache tag why is it tagged by that cache tag and to be able to answer that question I think it would be very cool, very valuable to be able to visualize that much like Firefox is able to do with the DOM so I'm not sure if you know but Firefox if you go into its web developer tools click on elements then it has a 3D mode which flips the page in 3D and allows you to see how the elements are stacked on top of each other well I think that a very similar tool would be very valuable for visualizing cacheability metadata it would allow you to say okay what are the tags on the page given the tags where does this tag come from where does this tag come from so in this particular example what I did was I asked well actually let me open the image because it seems very small on the screen so in this case what I'm looking at is a front page and over here we have the timestamp, the time when the note was posted and I asked basically I asked RenderVis to visualize what cost the time zone cache context because there's many time zones and the timestamps that you see are always varying by time zone because if I'm here in New Orleans there's a seven hour time difference with Belgium where I live so that actually was a bug on Drupal Lore actually at one point because we assumed that it was always fine to cache timestamps but it's not because it needs to be customized to the current user so in this case I'm asking what is causing the page to vary by time zone well it turns out it's this timestamp no surprise there I asked it to visualize how the time zone cache context the first time it was used is bubbled up well actually it's used here and it's a field that is rendered as part of the note this is the note, the outline of the note and the note is part of a view so it bubbles up to the entire view the view sadly still has several layers of diffs and containers so you see three outline containers and then it bubbles up to the entire page level and so being able to ask such questions and see what thing is causing a certain lack of cacheability or poor cacheability I think it's very valuable and so if anybody of you is interested in helping out with this because it's just a very hacky prototype at this stage you can work on very cool CSS3 animations and fancy things like that that you usually don't get to work on well come and talk to me and we'd love to have your help so note that you have a good idea of how big pipe works note that you have a good idea of how it is able to work what you can do with it what you can expect from it what are some other possibilities well we could add more placeholder strategies as I mentioned before there's a default one which triple core uses and then big pipe is a new one but we could add more like ESI there's no reason why we couldn't have an ESI strategy the downside of ESI is of course that you need additional infrastructure which is not the case for big pipe another thing that could be very interesting based on all of this work is something like turbo links where we would only load the difference between the current page and the next page and we could do that because we have the cacheability metadata so we know which parts are actually page specific and which ones aren't so we can figure out which parts should actually be the same on this page and the next so we can figure out which aren't so that we only load those so that's a pretty cool possibility service workers that would be very cool service workers are basically varnish a reverse proxy on the client that you can control with your JavaScript code so you can fully control what gets actually to the network because there is something in between the browser and the actual network and given that cacheability metadata we could automatically ensure that whatever the service worker has cached in terms of responses isn't validated when necessary for example, if it has cached the entire response for node five and node five was updated it would be able to be notified node five has been updated and that would allow it to work very efficiently and that's just a handful of the number of possibilities yeah and now Vimba show you something that you've not seen before because he actually made something like turbulence possible and that is coming now thanks for dramatic introduction so it was actually first called turbulence but the turbulence people didn't quite like it so we had to rename it and we call it refresh less refresh less it is turbulence but better to the extent that it is actually able to work automatically you don't have to write any custom code you don't have to do any integration because it is able to once again reuse that cacheability metadata that Drupal is already providing and so what it does is it's automatic it loads only the parts that change and it relies on the cacheability metadata to make page refreshes and navigating between pages much smoother so a very quick demo of that that I recorded a long time ago before it was called refresh less this is what it feels like to navigate between two pages without turbulence today in Drupal 8 and this is if you enable turbulence so let me actually stress it once again see how things are flickering and jumping about and then ah, peaceful and turbulence obviously has another advantage because we are sending way less data over the network for that because we are only sending those parts that actually have changed so there's also some advantages there yep, well obviously the browser has to do less work which explains why it's so peaceful and refresh less is something you can use and try today again, zero configuration just downloaded and installed it's in alpha state at this point it is not perfect yet but it's getting there it is approaching beta level stability but there is no consequences for you you can install it and immediately remove it and give it a try I welcome all feedback and with that we've had everything so try Bigbyte try the demo install it, give the try give feedback so that we can make it a stable module in Drupal 8.2 hey, hopefully otherwise 8.3 maybe and then everybody can benefit thank you how does Bigbyte affect document ready time? the question was over repeated because it seems like the mic is not really turned on or it's turned on but not doing anything does Bigbyte affect document ready time? it actually does in the sense that it is able to start loading the page much sooner and so it is not going to wait for every single block to have appeared until the document is ready something else you're probably asking about the dome ready event in that and the answer is no I was not able to find a way how to actually trigger that event in a way if someone knows we are happy to add it but because in Drupal you should use Drupal behaviors so you are also ready for Ajax as long as you use Drupal behaviors we are calling Drupal attached behaviors as soon as we've sent the first chunk so the first JavaScript will already start loading then and that's how we avoid that limitation yeah, exactly so that's why it's also able to make things work immediately before all of the things have arrived but then as soon as something arrives we also make sure behaviors are attached so never use dome ready in Drupal always use the proper abstraction I have a question you gave a lot of great examples like the weather thing like maybe customizing content based on IP address or based on a cookie or session or something like that but then I also thought I heard you say it's only available to authenticated users is there, we don't authenticate is there a way we can still use it you can definitely use it also with anonymous users in this case you would probably want to create something where you kill the page cache there are several methods which would be too detailed to outline now but the trick is kind of the only thing you need to do you create a new cache context my crazy thing and for your crazy thing what you would actually do is you would add that to the auto place holding conditions you would add that cache context to your blocks to whatever you are doing if you need lazy load entities we have some more work to do but you could just put in a lazy builder for yourself for that part that's independently buildable and then you just let Drupal do its thing it will automatically create a place holder for you and then you can make use of at least the dynamic page cache and pickpap automatically no problems yeah and one small addition and one follow-up question for you we said authenticated users and that's actually not entirely correct what it is is users that have a session so anonymous like e-commerce sites that's a typical example they have anonymous users usually but then as soon as they add something to a shopping cart they have a session big pipe works for anything that has a session enabled so authenticated users always have a session but anonymous users that have a session because of some very dynamic thing like a shopping cart they also have big pipe so if it's just a session if it's a site that is anonymous users but there is a session for some personalization that is taken care of automatically so you said there is a different way that it works if but it's still doing something if JavaScript is disabled I was wondering how it detects that in order to know what to send are you gonna show the code? yeah okay yeah yeah this is how it works so what it does is so the no script tag that is something that wraps any HTML that is only relevant and that will be interpreted by a browser if no scripts are available so if JavaScript is turned off so that means that this meta tag which causes a redirect to a URL that sets a no JS cookie this is only interpreted and seen by a browser if JavaScript is turned off so when JavaScript is turned off the first time you hit it with a browser that has JavaScript turned off it follows a redirect that says cookie that is not used for anything except no JS and then it knows that JavaScript is turned off on the server side does the big pike work on admin pages and it doesn't even make sense to have it there it should work on admin pages and it does not make total sense but for example at the moment forms are not cached so if you have a command form that would for example come later in that Hi, are you aware or did you use at all any type of tool or methodology for reliably and objectively testing TTI? It seems very subjective, is it am I wrong? It's a very good question so the question is how what is basically the best way to measure TTI in an objective way that's reliable that's a very good question the only way that I personally know of is to use basically inject in the right place in the HTML a piece of JavaScript, a little bit piece of JavaScript that marks that time because there is a resource timing and web performance timing specs that are supported by old browsers nowadays and that allows you to measure custom, that allows you to add custom metrics for performance and that is the best way I know of but probably in your case you have some interactive JavaScript and you can run that measurement code just when your JavaScript has finished initializing However, time to first byte is a pretty good measure, kind of, in it usually did match quite well at least browser timing, time to first byte is giving you an idea of what the time to interact could be in that bear It really does Yeah, okay, a JavaScript that you are creating a timing eventress is still more accurate, that's true I have a couple of questions, the first one is, I've been working on some large governmental websites that have thousands of static pages like news releases, government publications and they use Akamai caching for that which makes it very fast, you know, because they're just all static would this eliminate the need for the Akamai in every case or maybe would you still use it for something like that? It sounds like those pages are all static so it's the same for everybody so I don't think you would be gaining much with big pipes specifically but the other things, the cache tags and so on that is what would allow Akamai to be invalidated more efficiently and precisely so it would allow you to solve the problems of taking, of the time between publishing something and actually seeing it as the end user but that's not really what you're asking, you're asking can I remove Akamai because this would solve it well it really depends also on the latency between where your server is at and where the user is at so there is no clear answer well I would rather say the answers no because Akamai is scaling for thousands of users and this does not solve that problem of distributed global things in that this is really for the personalized experiences and for such Akamai solutions that are customized yeah Akamai has, I know that Akamai has some solutions for that usually you would still use Ajax for that and to get in the personalized parts and while Drupal 8 can help us with other things that we have been doing not specifically with that use case where things are like that and my other question and this is something that's always bothered me I've always thought that a lot of web pages would have like a bunch of links on them and people often go to one page and they go to another page but you can often predict what page they're gonna go to I mean you might have a page that like 50% of the people that go to that page also go to this they click on this link and go to this next page why not, is there a way to like preload that intelligently? yes well intelligently the intelligently is a very difficult answer, the answer to is it possible yes and actually I think at this point almost every browser supports it so I forget the exact name but in the head of the HTML you can specify a link tag that says pre-fetch this page so that if the user actually goes there the browser has already fetched everything and at this point it's even possible to have it pre-rendered so that you click it and it's there immediately that part is possible so you should look it up and I'm sure you will find it the exact name of how to do it, it's not much code you just have to use the right notation but the tricky thing is of course determining what is going to be the most popular thing so intelligently you would need to look at your traffic logs I would say and you probably won't be able to do such an optimization for every page but for the landing page it has the majority of people going to a certain next page there you could just do that and as that secondary page is preloaded big pipe would help load it faster well it would still have the same benefit as it would have for any other page but in your case you're asking can I make it ready right away which browsers have a solution for so big pipe would still help but it wouldn't help quite as much as just using the complete pre-fetching and pre-rendering that a browser can do nowadays I do technical SEO so I'm concerned about what the crawler sees and its behavior and I know you know we're not going to send personalized content to a crawler obviously but I'm curious about the no script and the meta refresh we don't like to send crawlers to weird places right have you looked at that at all so we would only send this JavaScript with a meter refresh when the user actually has a session most crawlers don't have a session as we said we are still debating internally for big pipe for anonymous users it's possible we'll probably make it possible but maybe not enabled by default but more make it an opt-in thing for sites that have that specific need but because most Google crawlers are pretty anonymous that should never affect them right as long as they don't have a session big pipe is not enabled and therefore they won't get any of the special behavior Thanks guys this is really awesome stuff I have a couple questions though going back to what you're saying about the jumpiness do you have any actual recommendations how to make the CSS more robust I'm thinking in terms of because I don't really understand caching that well for Drupal 8 inside of block you have CSS and divs and things is that all cached is that all that replaced in the placeholder or is the placeholder inside those little divs that gets replaced like are you replacing content or the entire block in this case the entire block is replaced there's a div we have an open issue that you all can contribute to if you want where we are integrating big pipe with the same system so you can have templates and then you can have like Instagram did it like this little previews you could for example say I create this kind of layout or block layout I want here I put in like an image I put in like some markup that's kind of the placeholder maybe some little spinner and then you can avoid the jumpiness also and when your content arrived it gets replaced but yeah that's kind of the idea of where we're going we are also debating if we have an outdated version of the page that we could send that with some special class outdated to that template and the template could decide oh I want to show the old version of that page actually so that would be another possibility to avoid some jumpiness because much content some content might not change as much as that it would be a problem so but there's still solutions in the works and debates around that and obviously if you have an inspiration come to us open issue and there's lot to research first a great session very good information we're on v6 right now and we use our cache module to the content for authenticating users I'm wondering if this will help us replace that in Drupal 8 yes or no yes because dynamic page cache is actually exactly what AuthCache does so big pipe builds on top of that so yes it solves it but it's not big pipe specifically that solves it it's already solved in Drupal 8 without big pipe dynamic page cache is very much what AuthCache does without the painful parts where you have to basically analyze your entire website to figure out which things are varying because which code paths are being executed we had we don't have cash ability metadata in Drupal 7 or 6 we have that in Drupal 8 and that's why dynamic page cache is able to do what AuthCache does out of the box so where we set different cache tags like for the base on the language or user or something and then we cache the content so is that that would be the cache context in Drupal 8 cache context replace this cache ID you can customize in AuthCache and we have some special variable renderer default cache context or something like that and there you can specify that your whole site everything that's ever cached render cached somewhere is varying by the moon cache context as I said so there's a variable to help you alter that and there's some lots of documentation you can look at and that should answer most of your questions entities and views are they being rendered in isolation or not yet they're not yet I have got a prototype it's possible their entity view builder is a little interesting code which made it that a lot more complicated than I originally thought but yes it's possible to render those in isolation and actually one of our earlier demos might have been LA or Spain they can actually see entities being lazy loaded one after each other uh... so it's possible we just have to do the work and views blocks so views that are rendered in blocks are served because it's just a block once again so it works thanks everyone have a good day actually I actually had it ready I just need to hit the publish button