 So, just a brief introduction for me, for those of you who don't know, my name is Josh. I've been around the Drupal community for a long time, and I'm outlandish Josh on Twitter and other places on the internet, and I work for Pantheon, a website management platform that once makes it fast to build, fast to launch, and fast to run websites. So I have a long background of being interested in website performance, particularly from the infrastructure platform, the server side, the back end, if you will, and I'm here to talk about the other side of the equation, which I think is, you know, this is why I'm giving the talk, because I think at the very important side of the equation, we all need to get with it a little bit more. So... Sorry, I had to keep my dance. Damn! I guess that's what happens. So, this is a real talk presentation, which means I'm going to try to make it a no-bullshit presentation, and I have prefaced some of my recent performance talks with this label because everyone cares about performance, but it's often like a misunderstood thing. And I feel like on the web, there's kind of like this self-referential victim cycle we get into where the worst aspects of the web lend themselves to the worst aspects of talking about the web. So, like, you'll sometimes read blog posts or you'll even see a presentation, and it's kind of like this one weird trick that they use to get their website fast, or this website, this guy's site is totally jacked. The Rackspace hates him. And that's not how it works in real life. Like, this is actually a discipline. It is a lot of small improvements that add up to the big results that we all need. It's something that requires constant attention and iterative focus. But it's something that's actually very important. And my biggest hope in giving this talk is actually two-fold. One, that some of you in the audience who are currently a little bit more like my background, like kind of traditional Drupal performance back-end sort of people wake up and like want to start to play on the other side of the fence, because I think we actually need that. And my other hope is that some of you are here who are just generally interested in performance, but currently feel like it's some kind of magical, like you have to have a level 10 wizard hat to do it, like get inspired because you don't need a level 10 wizard hat. All you need is like a brain that can do logical processing and a will to do it. And it's a great field to get into. It's a vital field. It will ensure you career safety for the next decade or more. So hopefully I can be an inspiration. So I want to start with real talk. Time is important. We're all here for a finite amount of time. And how we spend that time is the value of our lives. And it's important to remember and recognize that. Can I ask for a show of hands? How many of you develop websites professionally in the audience? Who do this for a living? Okay, so that's probably a little over 100 hands raised. And at like the lower end estimate of going market rates, that means this session costs over $10,000. The opportunity cost of all of you listening to me is somewhere north of 10 grand. So hopefully I will make it worth your time. But it's all about this. Time is important. And all of the things that have been going on the web, like we've been trending in the wrong direction for quite a while now. And I don't know if any of you saw Ian's presentation on what they've been through at Vox, but they had a great famous blog post where they basically said, we have to declare performance bankruptcy. And if you look across the web at some of the loading times for major properties and websites that get a lot of traffic, the trends are not good. And some of this has to do with the way we build our websites. Someone has to do with the market around how advertising is often delivered. But overall, the web is not getting faster. Internet speeds are getting faster, but the web itself is, in many cases, getting slower. And that's bad. That's a problem. And we all think, ah, it's not that bad because we are always on fast Wi-Fi and we have the latest devices and everything else. But if we want the worldwide web to fulfill its promise in being worldwide, we have to care about performance and we have to care about performance at the last mile. And that means front-end performance. You might think, oh, I don't need to worry about this. I'm on Pantheon or some other awesome infrastructure provider. I've gotten lighting up the Pantheon signal that's going to make my website fast. And I wish, of course, like I'd like to infer that for sales and marketing purposes, but since I'm giving a presentation, I have to tell you that all of these technologies that we deliver, real talk, all of these badass pieces of the stack that we put in place and deliver for you to try to make your website fast, they don't matter. Ultimately, these are not the things that make your website performant. They're important parts of the puzzle. They don't matter. None of these things matter if you give someone a web experience that involves this, right? So, I've been called in countless times to look and debug something and try to figure out why this site is slow. Usually, if I'm looking at it from the back end, it's like a slow query or something like that. And then I look at the website itself because I'm also just curious and I look at the page source and I'm like, oh, I saw the best stacks of my generation destroyed by madness, a miracle, unable to aggregate their CSS files. And this is just... I pulled the source from my personal blog just for the effect, but oftentimes in production, I ask people, well, there's a slow query and we can help you with that, but why don't you have CSS aggregation turned on? And they'll say, oh, it's because one of the pages didn't look right. And I mean, that's a trade-off that I think at some point someone is making, but the developer who allowed that trade-off to be made failed. We are letting ourselves and Drupal and the internet down when we allow that kind of trade-off to be made, saying, well, this page doesn't look right, so let's just make it load three seconds slower. Let's just destroy the user experience so that the end result is fine. And I think it's like... We've made great progress of advancing our industry and craft away from like, here's a Photoshop doc, make the web look like it, but we're still not there if we can't explain that. No, we actually need to spend the time and energy to make sure that this web page both looks right and also loads in an acceptable amount of time. Your server response time, while fundamental to delivering a performance web experience, doesn't matter if your user experience is like this. I'm going to pick on these guys a little bit. It's pretty weak. It's a complete page load in 7.5 seconds, but it was really almost five seconds before I could even read the headline. And this is a website that makes all of its money from being a website. It depends a lot on infrastructure. It's actually on some of the best infrastructure you can get, and their user experience is still poor. And it's because this is hard, right? Performance is moving up the stack. The expertise that we have all developed in the Drupal community that started way back in the day with like, okay, what kind of disks do you want to have and how much RAM do you need to make sure that your Drupal site can scale in its performance. Or like, how do we tune PHP and Apache and where does Varnish fit in and what's the right buffer pool setting for my SQL? All those things are... That took a lot of energy and effort to figure all that stuff out, but those are mostly solved problems now. And even if you solve those problems, it doesn't mean you have a fast website, because the operative area for developer intelligence to be applied to deliver great user experience is moving up. So we need to be really thinking more about our Drupal architecture. Drupal 8 does some amazing things to this of our Drupal architecture and what that does, both for initial response time and for render time. The content architecture, this is where for those of you who do consulting work, like, it's very difficult to deliver great user experiences if you're not engaged in a kind of a strategic level discussion with your stakeholders and your clients. Because if you don't talk about what their objectives are with the content, it's very hard to optimize the user experience in a way that's going to blow everyone's minds. And ultimately, your customers and stakeholders want to blow everyone's minds, because that's how your message gets out. Fast websites matter not just because they frustrate users and people navigate away. Fast websites matter because you get better search results when your website is faster. You will get people to not just not leave your website, but a fast website will keep people on it longer, reading more of the content, getting more of the messages, converting at a higher rate. Those are the real reasons people have websites, because they're trying to get something done. And if the website is not performant, the chance that they'll be able to get what they want done in the world decreases. And then ultimately, of course, like it actually is a technical challenge of optimizing the DOM, the document object model, and how the browser parses it and renders it so that we can give a snappy user experience and make sure that everything is fast all the time. So this is my basic pitch. So all of us who care about performance need to start caring about performance closer and closer to the user, because that's where the real action is. That's where the market is moving quickly. That's where the fun stuff is, to be honest. And it's also the most important, because if we don't do the last mile, it doesn't matter what we did on the back end. Yeah, fast websites matter. I just explained that. So how fast? That's actually a really interesting question. So I'm going to talk a little about what kinds of thresholds in speed you should be concerned with and targeting. And this is based on research that actually goes back to the early 90s, which is really about application performance on like PCs. This has been backed up more recently by a lot of research that Google has done. Our page ranking overlords clearly care about this and they're trying to make us care about it again with the SEO kind of tipping the scales, but they have good usability studies on this and good front end performance resources. Really, all the research converges on this idea that there are kind of three thresholds. There's a 10 millisecond threshold and because it's done by engineers and scientists they just like pick the round number order of magnitude. I'll bet you that maybe there's like a 10.2 or 1.1. But just think of it as 10 milliseconds, a tenth of a second, one second, 1000 milliseconds and 10 seconds. These are the three basic thresholds that you have in considering what kind of user experience you're able to deliver to the person at the other end of the wire. So the 10 millisecond 100 millisecond experience is awesome. This is real time. If you're doing a first person shooter or something you want a frame rate that's higher than this because you're VR or something. But for our purposes, 100 milliseconds between a user doing something and having an interaction makes it feel like they are directly interacting with the product, directly interacting with the system and receiving real time response. It's fast enough that the brain just perceives it as being conversational. And that is a really high bar to hit. It's a very difficult bar to deliver for user experience, but thinking about how you can get something even if it's not the complete thing going and this kind of time is like kind of the, that's like the gold standard. Like if we can make our interactions with users feel like they happen at this speed we will have delivered the best possible web experience. In reality, oftentimes networking is involved in other stuff so like there's this one second time threshold. One second is pretty good. One second has been shown in studies to not break the train of thought of a user. So the user will notice that there is a pause and they will wait for it. They're happy to wait for it. They don't register any frustration. But more importantly, they don't start thinking about anything else. So if you want to think about like your website as delivering a kind of a cognitive flow with the person in front of the browser, the one second threshold or they're about is what you get to and you just keep them on task. And this is kind of like the magic, this is the magic tipping point for how fast your basic web page loads. Because when you are a user and you click a link or something like that, it's because you're interested in them. And if that seeing or reading can happen in about a second you won't, there's no boredom, not even beyond like frustration. You're still on task. The user is still focused on whatever they were doing before. And so for whatever you're trying to achieve in the world this is still a very difficult bar to reach, but it is a bar that I think we can all legitimately aspire to. And then finally there's the 10 second use case. 10 seconds, let's just watch this. That's excruciating. And what the research shows is that 10 seconds is basically as far as you can go before people will just say fuck this, I'm out of here. Or at a minimum they'll open another tab and start looking at something else or they'll put their phone down and do something. This is the point at which you've lost them. It's not that like 10 seconds is the number, but it's where in the research studies it's kind of a tipping point. It's all downhill from here. 10 seconds or more, it's over. You're not going to get, you're not going to be delighting your users, you're not going to be engaging with them, you're going to be losing them to the competition. And I'm going to pick on these guys some more. So here's a simulated mobile browser load of that same big web blog at 3G speed. And there's the click. Like that's really bad. And I, you know, it's like there's a reason why the publishing business is in turmoil because too often this is what's happening. Other usability research has shown that delays like this where people are on a mobile device waiting for content cause on average a 38% increase in heart rate which is comparable to watching a horror movie. And more importantly for a business stakeholder that is significantly more stressed than people experience waiting in line at a brick and mortar store. So again, if you're talking to a business stakeholder and you're trying to convince them that they should care about performance too, there's a wealth of research out there that you can tap into and if they have half a brain you should be able to make the case that this is far more important if this is the experience you're delivering focus on nothing else until you fix this because it doesn't matter how good your content is it doesn't matter how many articles you can cram into that listicle if it takes 27 seconds which is about what this is for someone to click the link 3G is like what most of the mobile world browsers on from time to time. Like even if you have better than 3G service between towers on a mobile network you can have packet loss which will require reconnection in the middle it can actually end up being slower than this so you really like we need to consider very carefully what we're putting users through when their internet last mile isn't optimal which is most people in a lot of the time trying to load our content. So real talk if this was easy I would not be here to talk to you it would be worth $10,000 of the community's time I don't have any simple answers there is not one weird trick your website can get totally jacked but the only way you get there is by like you know going and lifting a lot or the metaphorical equivalent of doing that so in particular HTTP2 is awesome but it is not pixie dust you can't simply sprinkle it across your web properties and absolve yourself of all these sins. BigPipe which I will talk about is amazing but it is built upon in Drupal Drupal 8 is going to change our lives and change what we can deliver to the world in terms of user experience but it is not magic it is not like you just connect the big pipe to it and suddenly all of this goes away you have to understand what is going on you have to consider how it is going to help you you have to test and verify that you are getting the results you want from a user experience and then you will be in this wizardy Munich sky in there and say like yep that is as good as it gets we are doing everything we can I have built this great platform at Pantheon and it is not enough it is not going to get the job done without an army of developers out here that really care about this stuff real talk you can't beat the speed of light let's just talk about how the internet works for a second light traveling through a fiber cable doesn't travel as fast as light moving through a vacuum it travels at about 66% and it is the best you are going to get over an unbroken fiber cable the distance between San Francisco and New York is about 4,000 kilometers that would be 42 milliseconds of round trip at the available speed of light in a fiber optic cable and an actual ping is 81 milliseconds so the internet at distance is already halfway to the physical limit of how fast it could ever possibly be which is awesome by the way, go internet half the speed of light but the point is this is something we are all going to have to confront faster internet speeds will not fix the front end experience we can't expect that more bandwidth isn't going to solve the problem it can be a component of solving the problem especially on a throttled mobile environment but more bandwidth doesn't fix it that available bandwidth in the last mile question there are lots of cases where average user experience is much more likely to be on I'm not using it now because I'm using tethered to my phone but how's the conference wi-fi in general yeah they warn them every time and then they're like no, no, no, it'll be fine we have conferences here all the time with people and computers and then they're like oh y'all really like the internet huh so sorry about that but this is much closer to the everyday internet user's experience it's the wi-fi router that your nephew set up three years ago that you know to unplug and plug back in sometimes when it stops working completely but it's not optimal or it's the your office IT situation is like pretty old school they're more focused on the copiers and printers and power cabling and other stuff and the network just is what it is you're still on a T1 line it's super fricking fast it's super fricking slow now relatively speaking or you're on one of these mobile devices you're like the modern american family which is doing more and more and more and more time on mobile and it's not coming at the expense of time on desktops and laptops it's actually mostly coming at the expense of watching tv and other things like that but the wireless network in the house with this many devices if they don't have a good router it's not set up well there's gonna be some lag there's gonna be some packet loss maybe the mobile networks like you could be you're driving down the freeway or you're on a train or something you're gonna face like it's not gonna be an optimal last mile experience so at scale, at distance you're already going half the speed of light as fast as it can possibly be and the last mile network is gonna be slower than that inevitably even under ideal circumstances it'll be slower than that but in most cases it'll be much worse than that so the network is not something that's gonna help us and we need to think about how we deliver good user experiences anyway in the meantime, the average web page is now the size of doom statistics that have been tracked by this researcher and front-end performance guide Ronan Kremen from Ireland just creeping up and up and up over time and what used to be like a $50 piece of software that would come in a box is now the average web page that you load this is not Drupal, this is across the internet the average web page has 30 more images 15 or more scripts, 4 style sheets 4.0 something style sheets if those things aren't put together in a way that makes sense and is optimized the end user experience is not great and I think we've been trending away from this so don't just build the average website we want to build a better than average website and again Ronan Kremen and his boys have a lot of good humor about this it's important to have in such dark times we need to make the internet great again so real talk the 1% using the phrase loosely the 1% of the web knows that this matters the 1% of the web are smart enough to declare a performance bankruptcy they've used the chapter laws to help the business and you can see it it's in the data the average web is getting bigger and bigger and around 2014 the top sites on the internet started to bend away from that because they are aware that they can't just keep bloating up the user experience and retain their position as the top sites on the internet the top sites on the internet will be the fastest sites almost inevitably and without exception but we are the 99% not necessarily figuratively not literally but without tools like Drupal to build fast websites and without developers of websites with Drupal that know about and care about performance the average website will continue to suffer and so it is incumbent upon all of us not this the internet is what we make of it and we can and we will make it faster so that's the end of my doom and gloom portion of the presentation and now we'll get into some like stuff that you can actually do to fix things and just some practical advice I will actually include a listicle at the end if you want you can print it out and send it to your boss okay so I like to think of front end performance as a hierarchy of needs the hierarchy of needs is just a neat little mental model that I like to imagine what it takes to do stuff and this is kind of modeled off the mazo's hierarchy of human needs so the high performance origin is a base a base level of need for a front end, good front end performance like what what Vim and Fabian were talking about with performance versus perceived performance often times in Drupal when we say performance we really just need how fast the server respond that is an incomplete conception of performance and I would put forth that perceived performance is the only performance that any of us should care about because what we are delivering is ultimately a user experience no matter how fast the server responds if the user doesn't see it then it didn't really matter however if the server is slow you're screwed what are you supposed to do about that if Drupal can't respond in like for 3 or 4 seconds you're just never going to have a great user experience so you need a high performance origin I think you also need the ability to test and iterate this is something where there are tools to use around this but I find often times like local development can be a little bit of a siren song here because local development is awesome because it's fast it's fast because you've limited the network from the equation and because you've limited the network from the equation you may have blinded yourself to a large set of problems and there are ways to get around this but you need to think about how you are testing how you are iterating because if you can't iterate you can't improve you need to be able to like make changes measure them, release them make changes, measure them, release them that's not one weird trick it's a lot of little things that add up to a big deal so once you have a high performance origin and you're able to test and iterate then you can start going about optimizing your DOM and your assets you can ascribe to like sub second paint that's like the one second get something in front of the user in a second or less and that's like pretty much like where everybody needs to be from a professional standpoint and then we can all aspire to the the gold standard of 100 millisecond interaction so the DOM or Dominion this is something that I think in the Drupal world a lot of us kind of throw up our hands and say like Dividus, what am I going to do and I think that we just can't that's not going to cut it anymore in this world especially with Drupal 8 coming out there's more and more power and control being given to front-end developers and we need to get behind that, encourage it and make the most of it because ultimately we are responsible for what gets sent down the wire to the browser that is our business that is our responsibility and we should take it seriously and not just kind of be like Drupal did that to me no, you let Drupal do that so we have to think about it and we need to think about like some of the times there's low hanging fruit like people don't optimize their images and I'm not saying that image optimization it's not one weird trick to fix your performance but if you haven't thought of this and looked at it it's a really easy thing to look at and possibly do which Red Square is better they're fine, they're equivalent here's some parrots those parrots could be 263 kilobytes or they could be 93 kilobytes or actually they could be 30 kilobytes if you wanted to get crazy can you tell the difference between these parrots I mean there's a little bit of image artifact in the last one but maybe that's okay understanding the needs and the requirements of your content not just for image optimization but in general is an important part of being able to do front-end performance optimization because once you understand the needs and requirements of your content you know the parameters that you can work with in terms of what you can optimize and what you have to deliver in a less optimal way because there's another good reason and far too often it's just like ah you know we don't have it's too much work to do that content editors user generated content everything else and like no you can do this you can set up image cache and the media module to do a certain amount of compression and you can look at how much can be done there and you can try to get better at that with your web pages even if you're developing locally for those of you who don't know all the major developer tools support this idea of having a simulated mobile experience on your desktop so in Chrome which is my jam but Firefox, Safari, even Edge you can click this little button you can disable all your caches and you can throttle your network and if you're not actually looking at your you should be looking at your web pages just to know this doesn't substitute for like actual real-world mobile testing because you want to actually look at it on the device you can feel the form factor and it's not emulating the browser perfectly here but it is giving you kind of a gut check on what your mobile experience is going to be like so I would say like on your next project early in the process don't leave this to the very end to check right before you launch and have a sinking feeling in the pit of your stomach because you realize you either have to launch something or you have to have the deadline early in the process start building this into your normal project flow to check in on and say like hey, how's our front-end performance looking you know I throttled it down to 3G and it wasn't so good is that okay? do we want to invest in fixing that? do we want to invest now in fixing that or do we want to get to that later? what would it take to fix that? why is it so slow on 3G? that's an interesting question why does it take so long to load? if you can understand a problem then you can fix it you can iterate, you can measure, you can deliver better results the waterfall in Chrome is another great one so this just shows you all the assets that are being loaded and sort of take it one step beyond the page speed or the Y slow that just gives you a letter grade and tells you to those are good things to do too but this is like dig into it understand what am I telling the browser to do how is it responding to the web page that I deliver what is going on down there on the user's desktop or laptop or mobile phone let's grok that so that we can make it better for them and in particular you need to know the time it takes to fetch the assets to build your page and this is a good one here where this asset took like .342 seconds 343 seconds to load but 300 of those milliseconds sorry milliseconds not seconds 300 of those milliseconds were queuing basically means that the browser knew that it had to fetch it but it was waiting to do so because it was already fetching a bunch of other things and this is the one of the most common downfalls of front end performance is just that there's too much to gather before the page can render so if you know all browsers have concurrency limits mobile browsers typically have lower concurrency limits than desktop browsers people try to get around this by like domain charting and they have www2 and www3 really only gets you so far because the browser itself won't run more than depending on the browser 4 or 6 or 8 concurrent requests and so if you have a web page that has like 60 assets on it that need to load before the thing can paint it's just going to queue those things and request them as fast as it can it's doing the best job that it can but you've given it an impossible task even if all those responses come in super super quickly you can't beat the speed of light they're still around trip involved and they're just going to be waiting in line before the web page renders and your users will be sad so understanding what your request times are why they are what they are and then what can you do about that that is really the key to understanding front end performance and like which ones of them block rendering and which ones of them don't that's really our business it is our business to understand that and make it better so the state of the art is we should be able to do this progressively right we should be able to think in terms of like understanding our content well enough that when you load a page it's going to be like boom now the great this is a great example right that first experience it's like it's not a hundred milliseconds but it's well under a second like you the page got loaded and there it was like I saw that the web page was going to be there like all already I'm feeling confident about this web page loading even though the lorem ipsum isn't even even in place like it gives me as a user a feeling oh okay cool this is working I'm going to stick it out I'm going to watch it and then the lorem ipsum comes in I'm like great the lorem ipsum is here that was the main thing I was interested in reading and then that sidebar thing popped in later and I'm cool with that because like I started reading the main thing and maybe the sidebar you know wasn't so important for me or it was something I'm going to look at secondarily so this is only possible if we understand what our websites are trying to achieve how their content is structured and then and only then can make decisions about whether or not certain things can wait for certain things to be loaded sooner so this again you can't achieve this if we're just like at the very end of the line as developers siloed away from the conversation about what the mission of the website is or how it's content is structured we have to be participants in that conversation to do our work here we should you know get in there and like we'll have good input like people should have us in the room for that it's really worthwhile you can't beat the speed of light but you can use a CDN I think anybody who's concerned with their user experience and front end performance unless all of your users are in the same town as you and so is your server you should be using a CDN like there are CDN services out there that are really cheap they're really they're even free they're easy to set up they're easy to configure and they can for many many tangible benefits to your users to the users of your website which is basically like for the you know it's obvious right if there's a point of presence that's closer to the user there's less time that the data spent as photons in a fiber optic cable and then the user gets to see the thing faster and like you can try to get your web page you know really lean down and like but there's only limits to how far you can shave down the requests that are in the web page making those web requests turn around faster is key to delivering a good front end experience right you need varnish on your origin for your for your anonymous users but you also can push all of the assets out to the edge much closer to them and that's how you'll be able to get the now that's how you can get below a one second render for most use cases pretty hard to do that without a CDN unless the place you're measuring from happens to be close to your data center. HTTP2 electric boogaloo is coming it's here this is actually pretty awesome this is this is stuff to get excited about it is not magic pixie dust it doesn't absolve us of all of our sins but it does materially change the equation of front end performance and it's the first major revision in a long time to the HTTP protocol it's been hammered out you know all over years through the the RFC process and there's a lot of stuff that goes into this and not a lot of really great easily understandable information about what why it matters so I'm not going to talk about how it's a binary protocol and and I could do a whole session on what it takes to get a good HTTP2 debugging set up set up on your laptop I'll do a blog post about that later but just to talk about why we should all care about this and how this matters okay so as we were talking about before in the HTTP1 world you have client and server and you have lots of requests back and forth right the original request for the HTML back it's delivered it gets parsed there's things in there like CSS javascript images and other items those are then become new requests every one of those requests is a TCP handshake which is actually a whole back and forth ahead of time to do the sin and act if you're doing HTTPS which everybody should be doing there's that negotiation that goes on and then there's sending the bits over the wire to actually get them back down to the client and there's concurrency limits on how many of those things can happen at once and you're paying the performance oh there's also a DNS look up potentially so you're paying some overhead for every one of those requests and that's a major challenge for running performance and everybody knows this like the HTTP protocol originally the way it was set up was like it's from the 90s and it was when the web pages were super responsive because it was just HTML and you could drag it back and forth and there wasn't that much else going on it was assumed that it would be one transaction per web page and as it turns out that's not how the web has evolved so HTTP2 institutes a request pipelining which basically says we will open one connection between the browser the client and the server the user agent and the origin and then we will use that one connection to do much business and that is beneficial because it avoids the reconnection overhead and allows you to push concurrency way up because you're no longer tying up a socket for each request it also HTTP2 introduces I'll get to that in a second so how this ends up playing out in practice is this is a little bit of an eye chart but I'll explain it to you this is a wonderful web page that a gentleman set up which is just designed to demonstrate the benefits of HTTP2 so the web page itself is just every flag in the world on a web page as an individual image so it's like something like 200 plus images and on the left you have that under HTTP1.1 and you can see the waterfall is just sort of pushing out and pushing out and pushing out as this queuing is occurring even though each individual image is small and it's not doing anything like it's not like a Drupal request it's just loading an image from the web server so it's turning it around pretty fast but because of the queuing it just pushes it out and out and out and out and it takes a while to load the whole page on the right it's under HTTP2 you can see that all of a lot of those requests start at the same time and finish at the same time and at the end it ends up being about 40% faster which is great like that is exactly what we want to get from HTTP2 like that is going to be a huge benefit to all of us and what it will mean in practice is many of the tactics that we currently use to improve front-end performance like CSS aggregation or spreading for your assets will become less necessary they may not become unnecessary because there will be there are still some benefits in terms of how you can compress things and there are still limits to concurrency so you know it's not like we're going to totally give up on like creating aggregated assets for our web pages but it will mean that we have more flexibility there and you know if you need to deliver a few assets you don't have to like sweat getting it down to one thing as much as maybe you might otherwise do also we can do away with domain sharding which actually will perform worse under HTTP2 than it would in the old world and it's also just kind of messy and you know kind of trashy it's like very old school web nobody wants to do that HTTP2 HTTP2 also introduces the capability at the protocol level of pushing to the client this is basically the theory here is when I request the web page the origin or the server in addition to delivering the HTML of the web page can know that the HTML also requires these set of assets and can begin sending those immediately without waiting for the client to parse the result and request the associated assets there are ways to do this now with if you have a web server that supports it there's like probably a there's a mod for a patching engine X basically you just set some headers in your response from Drupal they'll be picked up by the web server and if it's doing HTTP2 with the client we'll start that push I believe cloudflare which is one of those free CDNs that I mentioned just added this across you can turn this on for your site as well so if you again if you set a link header it's not in the head of the document it's actually an HTTP header you set that link header cloudflare will see that and when clients connect to it it'll just start the push right away and it's a fun thing to play around with there's going to be a huge amount of potential here in terms of what we're able to do to deliver more of these kind of sub 100 millisecond kind of active experiences one of the ways you can get under 100 milliseconds is like getting a browser to pre-fetch the content that you think the user is going to want to see so like you can you can do this now actually if you're clever like if you have a funnel on a website that's like five steps and you actually don't need to know all of what they put in a step one to render step two there you can just do a link pre-fetch and actually get the browser itself to request the second page before the user clicks the button and then when they click the button they'll have that sub 100 millisecond real-time interaction pupils dilating dopamine pinging kind of experience that we're all really going for this is this is still fairly experimental or not the at the protocol level it's no longer experimental it's there the applications of this are somewhat experimental because in a perfect world you actually want Drupal to be able to actively push to the client which is not quite possible yet since the you're not talking directly to PHP yet but maybe in the future we could actually do that and now big pipe big pipe did everybody anybody who here saw Fabian and Vim's presentation I apologize this will be a remedial for those of you but I'm very I'm unreasonably excited about this for Drupal 8 and I think it's important to get the word out so when I talk about big pipe I'm actually talking about I'm actually talking about a whole lot of things some of which are actually just what we did in Drupal 8 with getting cash metadata together and allowing for rendering and isolation so in the era of Drupal 7 we had this challenge which was the path by which any content would be rendered and then ultimately delivered to the user was indeterminate because anything could alter anything at any time there are these giant render arrays being passed around and you as at the Drupal system architecture level it was explicitly like I don't know you figure it out figure out what you want to do and that's why plugins or sorry could contribute modules like off-cache are kind of so complicated and requires a very site specific and truly deliver the value because Drupal itself as a system is not able to know deterministically what the rendering path will be for any particular thing that has changed in Drupal 8 as of the advent of Drupal 8 it's one of the great advances we got out of kind of the the big platform rebuild and big pipe is a very like tangible dopamine inducing example of what is possible want now that we have that underlying foundation and the great thing about big pipe is because it's built on this underlying foundation that all other things are is it's a general purpose performance improvement you will still not need to break it with your website but most websites building on Drupal 8 will be able to take advantage of this without needing to do anything special other than like what they would normally do with blocks and so forth so you haven't seen the demo Vim has a demo site up there bigpipe.demo.vimlears.com and it does that progressive rendering thing that I showed before in Drupal 8 so the you start a session because big pipe is about delivering dynamic content so like if it's totally cached page just like get it in a CDN or get it in a reverse proxy and that's as good as you're going to get but for dynamic pages you can deliver the non-dynamic part of the web page immediately and that can render for the user and make them happy and the parts of the page that are dynamic and take more time to generate can be inserted later this is actually something you don't need to write custom code to do this it works with Drupal's block system out of the box this is the type of technology that companies like Facebook and LinkedIn and Twitter invest like hundreds of engineer years in building up and like tons of infrastructure around and we're actually going to get it out of the box for all the sites we build with Drupal 8 there's like if this is the kind of stuff that excites you there's no better reason to take Drupal 8 really seriously starting now in my opinion this is a total game changer and how it works is kind of similar to the HTTP2 story a little bit, actually big pipe has an idea the moniker came out of Facebook and we should all just be like so glad that Vim did that internship there because he brought back a lot of good ideas classically in HTTP you send a response from the client to the server your browser and Drupal Drupal must build the entire page so the server can respond Drupal needs to figure everything out anything could alter anything until we're completely done building that page and it's all ready to be flushed out of the output buffer we just don't know so we have to hold on to it until we're all done and then we can send it down the wire which means the slowest thing on your page like the whatever little thing on a block over here or a little personalization thing in the header or whatever that will hold up the whole show with Drupal 8 because we have the same cache metadata and we can render things in isolation it's actually possible to deliver a whole lot of the page really quickly and then send down the other bits that to the browser that took more time to render when they're ready and this just requires you to have like a no buffer you have to have non-buffering between your origin and your client but like Apache does this out of the box so like actually this will work pretty much just like that in the use case I set up a thing on digital ocean just installed the generic lamp stack just installed generic Drupal 8.1 big pipe works like that's incredibly powerful like you can go a long ways with this if you have a super advanced use case but this is really inspiring from their talk the idea that this is something we're delivering that is super valuable for both the enterprise and the hobbyist level and that is to me the true promise of Drupal 8 that we'll be able to deliver we'll normally spend enormous amounts of time and energy on but it's also good for just someone like me who runs a personal blog and we'll have to see in the future what the next steps are with Drupal and HDDB2 and what we can build on top again of this foundation of stronger caching metadata and isolated rendering kind of like to I've stolen this slide for so many presentations this is like Drupal 7 Drupal is made of Legos and and it's cool because you can take the Legos and put them together however you want and if you just had like the big messy bucket of Legos that you end up with and you decided to build a cruise ship with whatever Legos you had available you would end up with something like this it's like kind of ugly doesn't really have much coherence to it but it is a ship so it has that going for it and in Drupal 8 we've kind of moved into this world where we still have Legos architecture around how we're putting these Legos together which types of Legos go where get the colors to match up and this is kind of like kind of more a pleasing and aesthetic to look at and if you're trying to extend your ship and think about a cool little feature it'd be more fun to build like a cool prowl on this with a few extra Legos than like deal with this thing so Drupal 8, very excited about it for all these reasons I kind of often have this metaphor of like Drupal 7 and the web in general one of the challenges for the open web which is like something I think about a lot is it's a jungle out there man there's like so many decisions to make and so few clear guidelines on how to make them one of the things that is astonishing to me when I was doing research for this blog post is do you know who the actual market leader for all open web stuff is it's GoDaddy GoDaddy is the market leader for open web things and it's like it fits because the GoDaddy experience is just like this of like like what are you supposed to do I don't know I clicked a bunch of stuff and now I have a website somehow and they've made that work for them it's an achievement but the GoDaddy model is not going to scale it's not a pleasant model to work with and I don't think it gives us what we need for the future of the open web which is you know we have billions more people coming online this has to get better we have to get better at doing this and stop wasting so much time with BS and focus on more important problems and so I think Drupal 7 was a little bit like this with the fact that everything was so indeterminate and anything would be rendered anywhere and like like no I never put a template it would be messy and you weren't sure where things were supposed to go there's five ways to do anything and one of them is probably wrong and two of them might be right but I heard this one guy say at the talk that we should do it differently it's hard and like the good news is a lot of us found our way through this jungle a lot of us found success and millions of websites were built with Drupal 7 but I believe Drupal 8 will actually give us much more to go on there will be infrastructure in place there will be correct ways to do things which is actually great because it allows us to focus more on what we're trying to do at the end of the road then like what's the meandering path we have to cut to the jungle and so initially the learning curve can be actually kind of painful because what you might find is that the path that you like to take in Drupal 7, like maybe you hewed it out with a machete or like you were just following Morton wherever he was going blazes a trail that guy you might find that that old path in Drupal 7, in Drupal 8 like it just runs straight into the wall because it's not on the happy path or it's not possible or you can do it but it feels super convoluted because you're like driving in the median but I think as we learn Drupal 8 and as we develop we can develop much stronger community best practices around site building that will lead to much more performant and delightful experiences for our users and ultimately that's what we're here to do and that's like one of the reasons I'm so excited about Drupal 8 I think there's a ton of value there real talk, none of this is free this talk is cost $10,000 you'll have to go and invest more of your time and energy if you want to do this if you want to make this work you may have to justify the time and energy it takes to get these sorts of things done and I want to help you do that and give you arguments hopefully there have been arguments in here that you can recycle and regurgitate to other people who maybe like look at your time sheets or determine how long you're allowed to work on something so that you can actually put in the necessary effort to learn and execute on this stuff but here's the checklist it's like the six things you've got to do to get front end performance actually it's just what the agile process looks like you should set some goals you should analyze your rendering waterfall you should do mobile performance testing early and often you should inventory and cost the elements of your page and then you can have a rational discussion with your stakeholders of is this element on the page worth the time that we're making people wait for it and that could lead to some very interesting discussions you might find low hanging fruit you might also find you need to declare performance bankruptcy that might be a hard truth to come to realize but my guess is that along the way to like doing your accounting and realizing your bankrupt you'll find some incremental improvements that aren't that difficult to make and that will be a rewarding experience you can target the next table say measure the change after release lather, rinse, repeat agile development is the only way to analyze performance in this way so I don't know anything I just repeat what other smart people say this is all just like a way to paraphrase Mark and like so many others that have said this is how do you do performance you get good data and then you analyze it and that's what like those of you who want to get into performance this is all it takes get good data and analyze it you can learn how to do this it's not black magic it's not even rocket science or brain surgery it's just getting data analyzing it making changes measuring those changes doing that over and over and over again it's super important for the community and for the web in general that we do this so I'd like to close I like things sound more revolutionary when you say them in Spanish so I'm going to try this somos todos deserradores desaplicaciones para usario desaplicaciones para usario we are all front end developers whether we like it or not so let's work on making this better I'm happy to take questions if you guys have them at the mics otherwise we can just hang out and chat later thank you for coming thank you for making Drupal great and thank you for spending $10,000 listening to me oh yeah and vote me up on the website so I get to do this again wait no questions oh yeah go for it I'll repeat the questions for the recording so the question is is it worthwhile to invest time in CSS rendering time to paint and so forth or should you just focus on the server response time and so they're like let me plug my thing back in so I can load the slide that's the best answer to that question so this slide is my best whack at giving a canonical answer which is if you are in a position where your server response time is poor that should be your focus because that should be easy to solve making the server fast making Drupal fast on the server is not necessarily it's not easy to solve but that is something where there are a decade plus of best practices you can buy this in many cases from different providers in different ways that should be something where if that's where you're stuck just focus on getting out of being stuck there and you should be able to achieve that relatively quickly and then you need to move up and focus on the next few things so if you're in a position where your server response time is slow fix that first you should be able to fix that there's enough stuff out there hopefully no one is still no one is people do still struggle with this but it's kind of a solved problem so just get one of the solutions and then spend a lot of time solve this fast so you have time to focus on the things that are further up the stack because there aren't necessarily easy wins like the browser render fast or other experiences does that help? yeah so what you need so it's hard because oh yeah repeat the question thank you the question is how do you convince clients that this is important because they want 50 fonts and a thousand images and you guys just figure it out so it's difficult because depending on the level of the sophistication of the client making a technical argument to them is not going to be very persuasive so what I would recommend is making an argument to them based on business value as developers I think it's important that we can all speak the language of business value whether that's with clients or with our colleagues or with stakeholders inside of our organizations because if we can't justify the work that we do in terms of the effect that it will have in the real world then we're it's about doing the right work so what I would recommend in general is to talk make the clients aware of the user experience research that suggests that if they don't deliver a performance experience people will browse away or not wait for their website and explain that there's just trade-offs here like if you want all this stuff it's going to be slow your users are going to be frustrated and if your clients are of the like maybe I find like a lowest common argument you can make is like Google will rank you down if this is slow do you want that? do you want Google to rank you down? because if so let's just throw all the fonts on there if you want a top search result if you care about your SEO which most clients should then we need to think about how to make this fast and that's at least a way to get people away from where they're demanding stuff that would put you in like the 10 second render kind of area you may have to make like a higher value argument to get them to like give you budget and time to go for like under one second but if you're struggling with like really unreasonable requests we need five more admins here it's never going to work out if we do that we're going to be racing to the bottom so I would say just try to make it so that they understand that the user experience performance is critical to whether their website succeeds in its mission yeah that's actually a really good point so you can kind of do what I did in the presentation where you're like okay let's just see what this would be and just like does this seem good to you? is that what we want to do? and they'll say no you have to make it faster well okay in order to do that I need to talk to you about which of these fonts we can cut because that's just how this works some people are unreasonable but you do the best you can yes so HTTP2 is ready to be implemented now that is correct so all of the browsers, the major browsers now support it and you increasingly can get support for it from the major web servers like Nginx and Apache fairly easily through configuration or an easy mod Cloudflare which is a free CDN which I recommend checking out if you've not used a CDN before they make it pretty easy and they offer a pretty good service they will do HTTP2 for you and there's some pretty what we need really right now I think honestly I should do this myself is more tutorials on how to set this up and then how to measure that it's working it's actually a little bit difficult to get a good HTTP2 testing and debugging setup going right now or it's not difficult once you've set up but there's not a good how to guide on that but it's ready today all the technology is in place we don't need to wait for some provider to do something or somebody to roll something out it's all there it's actually it's now on us to start implementing it and getting really good at it and socializing best practices around it ooh good question the question was when will HTTP2 be available on Pantheon before the end of the year so what happens when you're looking at your waterfall and you realize that the big problem is third party ads so ads are particularly worrisome in this regard but this is true of any third party asset what I would say is if you have third party assets in your DOM must be asynchronously loaded unless you have a really good reason not to because what happens if you put a third party asset in your DOM and it's not marked for asynchronous loading you have now given license to that third party to take your website offline basically that's what it amounts to you've said I'm just going to time my uptime to their uptime because if my users are trying to see my web page and the browser has to wait to time out on their thing that can take 30, 60, even 90 seconds so basically if you have a third party thing that needs to load for your website which there are legitimate reasons to do advertising is one that is hard to escape they have to you have to win the battle to make them asynchronously loaded and ads are an especially good one even TechCrunch was doing that by the way I don't know if you've noticed like the super slow page load the ad at the top didn't pop in until the very end it's actually their page load is too fat but yeah asynchronousness is the only answer to that just to say thanks the question is how big pipe help with that could you put the third party ad in a block and have it load later that might help except that usually if you're doing ad driven websites big pipe is you're going to be caching full pages anyway and so big pipe wouldn't have that much of an impact wouldn't be in play in the first place you would still want the content that is in that block to make sure that the browser understood that the third party asset can be loaded asynchronously that it's a non-blocking asset so that if it takes however long it's going to continue processing the rest of the document that's a good so the idea of using custom code but not very complicated custom code to deliver inline deliver place holders for your ad units that also have the right size and so forth so the layout doesn't jump around but then using Drupal behaviors JavaScript behaviors to say once everything else is done go ahead and start replacing those place holders by fetching from the third party and that would be a valid user experience that could be a whole session in and of itself so another strategy that's a classic strategy for doing this is just iframing your ads so that they're guaranteed to load asynchronously and they can do whatever they want and they're in their own sandbox that's another really good point any more for any more? alright thank you so much yep that'll be awesome that means we cache this thing and then it can populate from the ESI which could be from the edge cache as well no no no that would be booting up Google and sending all the things and even if the content had changed it would keep an update to the content and like that so there's something that's got from them that would be great that would be actually from what we were talking about earlier that might be a thing for us to work on this summer oh thanks for sitting up front yeah I think the point is to be bad but not so bad that it's cringe worthy it's like you want to be like funny which means that you can't be terrible but it's also supposed to be a little embarrassing that's a feature alright now I'm done do you have any relationship with the varnish people at all? no not with the varnish project directly although we're building a pretty good relationship with FASCLY yeah I think they're FASCLY