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.  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.  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


Morning with Super Bowl MVP, Cooper Cup, and every single Madden that he's ever been in. And yes, I know this isn't a Joe Burrell video, but I'm keeping the shades on. Now we don't have to hike this back to Madden like 05, like in some of the previous videos. So I don't gotta get the PS2 or the Xbox 360 out, but I do think this will be hilarious. Number one, I wanna pay homage. Cooper Cup, 99 grit, highest motor I've ever seen. Real lunch, pale type of guy. I would definitely let him date my daughter. So I wanna pay homage to Super Bowl MVP with the greatest wide receiver season of all time. I'm sorry, old heads, but this season was better than any season Jerry Rice ever had. I'm sorry, I don't think Cooper Cup's better than Jerry Rice. It's just a better single season.  Either way, the first Madden that Cooper Cup ever appeared in was Madden 18. It was this year that Cooper Cup signed a four-year $3.83 million contract that included a signing bonus of $950,000.  Like that is highway robbery. But at the time, he was competing with a lot of stunts. He was competing with Sammy Watkins, Tavon Austin, and Robert Woods. So it's at this point in the year that McVeigh named Cooper Cup the fourth string wide receiver for the Rams. He had had a spectacular, spectacular career at Eastern Washington, but it's Eastern Washington, right? So I understand why he wasn't super hyped up. Let's be nice. Name a video game with over 600 plus champions, massive player versus enemy boss battles, and global PVP.  You shout out to Raid for sponsoring today's video. Let's talk about one of my personal favorite bosses in Raid. It's the Guardian of the Voidkeep, Malak Kavar. The main trick to fighting Malak is dealing with all of the poison that he puts out. You're gonna need shields and heals to counteract all the damage that's being done to your squad. But if you can do that, you'll be good to go and you can reap all the crazy rewards this boss has. Plus Raid has a ton happening this month. There's a fresh rotation of the brutal hydra boss and a ton of events happening where you have a chance to get a new legendary champion. This is absolutely the best time to get started in Raid. And if you click my link in the top of the description or scan my QR code, you'll get insane bonuses. We're talking a free Epic champion, Ana, 200k silver, one energy refill, one XP boost, and one Ancient Shard so you can summon an awesome champion right away. And all this treasure we'll be waiting for you right here at this chest icon. Check it out, link in the top of the description and enjoy the rest of the video. In the first game of the season, Cooper Cup had four receptions, 76 yards, and a touchdown against the Colts. The Rams won 46-9, a utter blowout. We're gonna hop in.  This is back when Jared Goff was getting better and better too.  But where's Cooper Cup? We're the, oh he's in here, okay. Whew, it's actually been, wow. Dude, Madden was very gracious. 81 overall Cooper Cup. Now keep in mind overalls fluctuate throughout the years of Madden. So when he was first put in the game, the first ever roster update, he was a 74 overall, which by the way for a rookie, he's actually really good. Like that's a really good rookie wide receiver rating at a 74. At the end of the season, which is what we're looking at here, he's an 81 and he's the third string in the depth chart, which accurately reflects real life. Robert Woods at an 84, Sammy Dubs at an 82. He's got 87 speed, 65 strength, 92 agility, 90 excel. Honestly, pretty solid. For some reason I'm not seeing the grit stat. I'm pretty sure it's a 99 in this game. So I don't know why they don't show it, but it's a 99. Ah! Ah! Oh my God, we have Todd Gurley. Ah, I'm sorry. I know this isn't a Todd Gurley video, but I wanna see what Todd Gurley's at. This was not the year that he won offensive play of the year, is it? 89 overall, 92 speed. There's gonna be a year where he's like a 97 overall. It'll be that year. All right, first in 10, Booper Bump, are you open? He's not. All right. Tyler Hickby, take us down the field, buddy. Hey, I'm just going to touch down a Cooper cup. Doesn't mean all the yards. Oh, I love this, Ralph. So my favorite plays middle, high, low. I don't know how good it is in Madden 18, but I'm gonna look for Booper Bump coming across the middle. Oh, good catch! He's got it! And a face mask, don't mind if I do. The refs saw how high his motor was and they had to call a... Is that joke ever not gonna be funny? I'm probably gonna keep making it. I say we go for the aggressive catch here. Let's motion him down, send him straight at that safety. I think it might be Malik Hooker, although I don't know. And go up, baby! Splits the double touchdown as a ram, let's go. Hell of a touchdown. All right, boys, we're at some at 19. Let's get cruising. Oh, we can play the Super Bowl. Damn, it's so crazy that in Madden 19, the Rams were in the Super Bowl. They relocate, build a God squad, like in actual, they're basically playing Madden Ultimate team and then went back to the Super Bowl. All right, I'm playing as the Rams. Wow, we're gonna have two Super Bowl presentations in this video, this'll be fun. Jared Goff now in 85, at 23 years old.  Yeah, you know, I think this was the year that he got offensive player of the year. Oh, it went into the year prior, but you get what I mean. 95 overall, 92s, he's so good. Oh my God. Brandon Cooks, 88, Robert Woods, 87, Joshua 75 and Cooper Cupp is not in, but he's in 84, so I don't remember him being injured this Super Bowl, but he must have been. But Cooper Cupp went from an 83 to an 84, but that was end season. So really what he did is he went from a 74 as a rookie to an 84 at the start of his next season, which is really good. 88 speed, 94 agility, 91 excel, 92 awareness.  So his run block is a 51. We need to check this stat as we go on. Cooper Cupp this year for the Rams was a spectacular run blocking wide receiver, a very slept on part of his game. So his run block is 51, his run block power is 32. Obviously I don't think it should be 99. He's not an offensive lineman or anything, but I would not be surprised if in like the later Madden's, like Madden 22, I think it should be at least in the 70s. It won't let me put Cooper Cupp.  It literally won't let me put Cooper Cupp in because he didn't play in the Super Bowl. That's sick. All right, nevermind. Hey, there he is. All right. Well, we're gonna try that again. We're in the old, we're in the old LA stadium. We're in the old Rams stadium before they got the bread for so far. I think Cooper Cupp on PA Crossers could just split right over the top, baby. He's open. Yes sir, we got him in a window, but we've got some more yards to go. Now we're not the sun looking McVeigh getting amped. I'm gonna send him to the end zone. Cooper Cupp, you wanna just mosh somebody? I know that's not really your play style, but that is single coverage. Come on, Cope. Come on, Cope. Let's go. Don't hit that. Don't hit the Fortnite dance, bro. Stop. No, he ruined everything.  Hold up. I gotta run that one back. Oh. Who's that on? Oh, that's on McCordy too tough. That's an excellent player. He did that on. Sorry, bud. I think if Devin McCordy was a grittier player at a higher motor, he'd probably get it, but taking one peek at Devin McCordy here, I can tell that guy does not have a high motor. No grin. Onto Madden 20, my favorite Madden of all time, and where Cooper Cupp is gonna have abilities. So he went from a 74 to an 84 now to 80. If I had to guess, I'm gonna say 87. 85 overall, Cooper Cupp does have a superstar as well as Whitworth and Aaron Donald. The God squad begins. Depth chart, Jared Goff has now, Jared Goff has officially started his descent. He went from an 83 to an 85 to an 83. Hold on, Goff. Todd Gurley up to a 97. Jesus. Now this is a crazy descent. Todd Gurley, start of Madden 20, 97 overall half back. Not even two years later, I literally don't think he's on a team. I'm pretty sure he's a free agent right now. That's insane. Oh, and Cooper Cupp, I overshot on Cooper Cupp.  Brandon Cook's 87, Robert Woods 87, Blooper bup, 84 overall in Madden 20. Same stats, let me see the rub blocking. Did they do anything with rub blocking like what I was talking about? I doubt it. I'm pretty sure they copy pasted his stats now that I look at this, 51, 32, 28, 34. They literally copy pasted his stats. Which is okay, I'm pretty sure this is when he was injured. He was injured last season before this. So not much change. He just came back from injury. So I understand, but I am really hoping at some point they do mess with his run blocking.  It's best while I receive it in the league this year and it's not even close, but whatever. I think he's a man here. Yup, he's a man. He should get that. Cooper Cupp. Oh my God.   Oh my God. That was basically triple coverage. This is nasty. Another one-hand snag. He uses the other hand, he uses left hand last time on the one-hander. This time he uses the right-hander and just shreds the safeties. All right, I'm not complaining. That was bad eyes. Let's go. What are his abilities actually? Before we go anywhere, let's see what abilities they gave him. He has cross specialist. Better route running and catching on cross routes. That's it. Nothing too special. Oh good, Madden 20 in the books. Let's go to Madden 21. I'm hoping he makes some form a leap. Does he do literally everything in Madden 22? So this is the season where Cooper Cupp finally gets paid when he's deserved. He signs a three-year, $48 million contract with the Rams and at the time the media gave the Rams a lot of flak for this decision. A lot of people thought he was getting significantly overpaid. Clearly that's not the case now. He did get injured before the playoffs and that is when they played the Packers.  So we're already pretty much caught up.  This is when they signed K-Makers who sadly had that Achilles injury pretty early on and he was out for the whole season. Cooper Cupp has gone up to an 86.  So 74 to 84, he stayed stagnant around 84, 84, 86. And now he's gonna lightening speed too. I think he's a 97 or 98, but we'll see for sure in Man 22. 86 overall, Cooper Cupp is 30 year in the league. He's 27 years old. It's got 95 agility, 88 speed, 91 excel. There's some reason they do not put the grit stat. I don't know why it's not in here. 90 catching, 91 short, 90 mid, 84 deep. Now let me see these blocking stats. I think they finally caught on just a little bit, okay? Now normally I'd say it was just random, but Robert Woods is a higher overall, but has less run blocks. I think someone did consciously put Cooper Cupp's run blocking a little bit higher, but his power, finesse, and league block are the exact same stats, 32, 28, 34. Not that I actually care, but I am interested to see if these go up in Man 22 because that's when they're really gonna go up. If his run block is not at least 75, I will be pissed in Man 22. But he's an 86 overall, the highest he has been yet. Ooh, is that open? Uh-oh, a little lofty there, Jared Goff.   It's hard to say I could score a touchdown off of this, but clearly I can't. We'll send him down this seam, he's in man coverage. I think he'll aggro back. Oh, he's in double coverage.  So we just gotta send him to the end zone and have him catch it. Aw, he could have ended up much cooler. I thought it'd be sick.  And that spike wasn't a very good spike. All right, the moment you've all been waiting for, let's get to the God tier, Cooper Cupp. Rams versus Bengals. You know we gotta do it, you know, it's crazy. The Bengals made all of his Super Bowl men doesn't have them with a single X-Fact, whereas the Rams have like four, I think.  I don't get how Cooper Cupp is not a 99, right? Like how? He was better than any wide receiver this entire season. I know he's a really high overall though. Let's check this Dev chart and see just how broken he is. Dev charts, Dev is an 83, I take it back. He's definitely not an X-Factor. K-makers is an 82. Cooper Cupp is, oh my God, he's so close.  Just give it to him.  They only give him 89 speed. Fastest wide receiver on the Rams is Odell. Ben Javison, 90, Robert Woods, 90, and Cooper Cupp, 80, 90. He's at 66 strength. He's hardly any stronger. 95 agility, 93 excel. 99 awareness, 84 break tackle, 55 trucking, 91 change of direction while Odell is like better than the open field based on this. 89, bulkier revision, Odell's got 96. So where is he better? I'm actually getting frustrated. Odell has more stiff arms. Odell has a higher spin move.  Carrying is a 76. Okay, catch it, okay. Now we're getting into it. Catching is a 99. Short route run is a 99. Medium is 98. Deep is 93. Catching traffic is 86. I'm low kilo mad about that. I think that should be higher, whatever. 81 jumping, probably true. He's a high grip player. Okay, he's white as fuck, so we'll keep it at 81 jumping. I am actually so mad. He's the highest run blocking receiver on the team. He has more run blocking than the tight end. Okay, so maybe Madden just keeps this stat really low no matter what, but I am a little upset. They never changed these at all, 32, 28, 34, just copy pasted it. Well said, 98, almost a 99, booper bump. And ability wise, Cooper Cup has rack him up as his X-Factor Red Zone Threat Slot-O-Matic and deep in elite. All very good abilities.  There's Cooper Cup in a window. Good looks, good looks. All right, let's roll out, let Cooper Cup clear.  Hey, we'll take that, we will take that. Second and 10, he needs to learn to not press cover. Let's bomb him over the top for our final touchdown.  Is that Eli Apple? That better not be Eli Apple, we just got torched like that. Eli Apple is, oh, it's no, it's Trey Waynes. Oh, I feel bad, I just use Eli Apple. I should run it back, but I wanna run it back to where Eli Apple's on it. I love making fun of Eli Apple, it's my favorite pastime. This is basically the play, what I'm cooking up right here, okay. Well, the Bengals aren't even gonna adjust to it, but this is the play, this is the touchdown play in the Super Bowl. The Outro, oh, Eli Apple dropped the interception. Is anyone surprised? All right boys, that's it. I wanted to score a touchdown with Cooper Cup in every single man that he's been in. He ends it as a 98 overall, it's absolute stud. I hope you guys enjoyed, I know this wasn't a crazy one, we didn't have to hike it back to whenever, but had to pay homage to my boy here. All right boys, I love you, thanks for watching as always. I'll see you in the next video, peace out.


Well, thank you guys. Good morning everybody. My name is Olivier. I am one of the first guys that also started with development foundation. And the idea here is to discuss about the hub content. And I use this Latin word, covattis, means where is going the hub content. I'm doing that because of several reasons. And I will explain why it's, for me, it's very important. Well, the history of hub content is the following. Until 2011, hub was exported to WikiHealth by a work of Kendi. The source of the hub content was still in the old help XML files, no HPE. There is constraints of some countries that cannot have good telecom service to accept WikiHealth. And also, as far as Sophie told me, there are some legal constraints that you need to have the help with the products. So this was the situation. And from 2011 to 2014, nothing absolutely happened with the hub content. I mean, it was marginally updated. Very few additions to the hub content. The feature between, the gap between features and documentation was widening. So many features absolutely no documentation. Okay, for instance, let me just give you an example. Where is the Impress Remote documented? I was supposed to use it here, but this is not documented in the hub. How do we activate this? You have probably to go to Google and find a Wiki page in the Indacment Foundation where some lines were written about that. Okay, and this is a very interesting device when you can go through your presentation with your Android telephone. Lots of new features with no hub content. For instance, personas, the personalization, the basic IDE, which was a work done by some of the Google students. The card statistics implemented by, I think it was Tomas Wangel, was not the documentation. The card XML streams, I don't even know how this works. Okay, I'm not a programmer. I'm just a very advanced user, but this is something I don't know how to make it work. The card XML filters, the card new functions, there is a lot of new function being brought to the office from Microsoft functions. The writer front pages, one thing that was implemented very early, but there is no documentation on how to set up the front pages of a writer document. The CNIS, the Palatial 12 Frisco, and other documents repositories, new format filters that are done by British. So these are examples of missing information. Okay, so if you don't document the features, user won't find the first date assistant. Oh, of course. Okay, then press F1 and you are sent to a page that doesn't say anything about your doubts. Okay, the second, they get lost. And when they get lost, they will think that they will office themselves as software. Okay, this is not good for us. There is loss of productivity and you get angry users and happy managers, CIOs and CEOs. And users can do bad things, you know, they can really screw up their files by not knowing what they are doing. Okay.  And if there is noise, no help, you can say that just press F1. Okay, there is no F1. Well, worse, an undocumented feature for me is a hidden feature. Liberal Office has hundreds of dozen features. Some of them are totally obscure. You don't know what is it. Okay.  You don't have assistance from the community. Your work as a developer will pass unnoticed. You will shoot yourself in the foot. Liberal Office must be more than a personal developer or person. It has to be professional. We need that, you know. If you are going to make, to give support, you need to get documentation. Okay. And worse, there is no reference for good but fixing. I mean, if you don't know what a feature is doing, it's not documented. And all of a sudden, the behavior of the feature changes. You don't know what changes, how it changes, and if the feature was really implemented correctly or not. You lose ground. Okay. So this is in a consequence of the fact that Liberal Office and other open source software has a very fast developer rotation. People come and go into development. When they go, when they leave, they don't leave information about the feature. Okay. And also the people that of the ODF author team will suffer to write the proper user guide. Okay. For instance, give examples. Document write an example. Tell us how it works. Okay. It has to be, I expressly use Latin words. It must be a situation for the Google students. The basic IDE implementation, the autocompletion of the basic IDE. I did it myself. I wrote to the students. He never answered me. What I got is one line of Miklos' presentation in Berlin. One line. And I had to write a page about that. Thank you, Miklos. It was a poorly referenced basic IDE. Okay. So what to do? At the moment, it seems that we will continue for the timing to use our old health content technology. Okay. There is an alternate technology to write the health content. It's not in place. This is a discussion that grows and comes and grows. But we don't have a documentation, a specific technology for the health. There are alternatives. Yes. And there will be some conditions to use it. Okay. Instead, I'm sorry. Instead, the health author extension is close to be fix and usable. We have a rescue from an open office. An extension that allows us to use writer to write health pages. Okay. At the beginning, it was not a good one. We had to fix it. And thanks to the work of Kendi, Yusuf Phillips, J. Phillips, and Regina Vigina, that it started to be usable. At the moment, it's much better than before. So you can use writer to input your text and get a health file. Okay. So we have many improvements in usability. And we have also corrections in the XHP filter. Yes. How do I use writer to edit it? Can I open a health file in the program and then mark it, connect the text, and make a new file on it? Or how does it work to edit with writer? In that case, as a developer, you open a health file, you edit, change, or add information, and you save it in the code, and then you compile the health. You do make health content, and it will put your changes inside the health. Okay. So it's an extension. It's a UNO extension, so you download it from our repository. You install it in your vanilla copy of library office, and then you can start using it. Okay. Well, I have opened the bug 80430, which is a meta bug for the gap between the features and the health content. Features that has no documentation, for instance, interest remotes. And the others I've already mentioned here. Okay. It also report changes in the features, menus, and dialogue. If a dialogue is changing, it's content. It has to be documented. Okay. There is a lot of options, new options coming inside library office and no documentation. I had to spend a couple of hours with Ohai because he implemented a feature on reading Excel files without having to recalculate the formats. And I had to understand what's used for, what's the purpose of that, you know? So he helped me on IRC, but it's not the right way. It has to be written somewhere what the speaker is doing. So you as a community member, or maybe even developer, you speak about independence in this and you write the health content. There is about 30 to 40 dependencies, I mean, bugs or gaps to fill in that situation. It's an easy hack for members of the community. It's not that difficult to write about a feature. I mean, it's maybe time consuming, but it's not that hard. So properly managed, we can have the community to help us. Okay. And if you find a difference, a gap between the feature and the health content, you should add a back to this list as a dependent. Okay. So we get the list of the features that are missing. I mean the documentation that are missing. And the other number to retain is this one, 9350580. It's a meta bike for the health authority extension. And all that we think that we can improve in the extension we put here. Okay. So what is the health authority extension? It's the set of liberal office model, several modules. It has two LXST filters for reading and writing XHP files. And there is one writer template with specific start for the health content. Okay. So what it will do, it will map this filter, will map writer styles into XML properties. Well, where to focus? Okay. First is to focus on reference documentation. We should have really a reference on what the feature is doing. Okay. This is the first thing. We need to describe the feature. We need to document the dialogue options. Okay. If you have options with checkboxes, radio buttons, buttons, text area, this has to be documented. Okay. We can, we should insert internal references or external. I mean if, in the case for instance, for the statistics that Thomas did, I had to go to Wikipedia and to borrow knowledge from them to write a couple of sentences. Okay. And the reference, the reference is the Wikipedia. It's better than nothing, you know. I'm not an encyclopedia of statistical functions. So add the page to the entry, page entry to the tree file. There is a file in the health content that contains all the entries of the help. And this allows you in the screen of the health on the left page, it will list your page. So to list your page there, you must put into this tree file. Okay. And then you set the ground for later bug fixing because if you describe the behavior of your feature, and later the feature does not behave correctly, then you know the reference. Okay. Wow. And the step two is to write a user guide. This is debatable. This is really debatable if we have to write, I'm sorry, this is a bug. I'm using 502. So it's debatable if you have to write a user guide. Okay. Because it takes time, it's not the best technology to write, and we have the ODF authors that writes very good books about using library objects. Okay. What is left to discuss? Should we insert media in health content? Because the health content is 99% textual. So it's the matter of if we can insert images, screenshots, or things that will help us or help the user to understand what it's going. Okay. Also, should we write the user guide? This is to debate. Can we improve the English writing? Most of us here are not English native persons. So my English is not good. I don't like to translate my English into Portuguese. Okay. I feel that I write very bad. So sometimes I think that we should have someone skip it in the linguistics of English linguistics and properly write the content. Then the translators will help us. Okay. And how can we bring the health content XML reference to library office? I mean, we have a documentation on the health content XML. There is a documentation. This documentation was written by Sun Microsystem about six to seven years ago. Okay. And this book, this paper, is, I mean, it's, it should be able, we should be able to improve it and, and, and update it. So it should, apparently it's a PDF file. Can we import the PDF file into a wiki page? Well, I'm finishing. Yes. Another issue is to use the dialogues properties for health content tips. There is a possibility that part of the health content tips can go directly to dialogue. And as I have an issue also, which is the health content as a separate package for download, what I discover is that people download the main program but doesn't download the health contents. And then we see on the list questions that are very easy to answer because they don't have the health installed. And for some reason, they don't get into the wiki page, the wiki pages. And also the worst of library office. Okay. What is really an horror is this one. Have you, have you met this guy? It is absolutely unusual. Okay. Not even try to find what is a cell object in the API. You won't find it here. It's crazy. I had to go to open up his API description to get it. That's it guys. Well, that's it. The demo I will try to do the demo later. Okay. About the health contents. And thank you for your patience and excuse me because it took too much time to fit the computer. Okay. Thank you guys. You can have one or two questions. So when you indicate what would be a good way for a developer to make a video or something of the future? Because video is visual. You don't have to translate it. And this would be a good start to go from. But I don't know how to do that. Maybe the developers know and we should just tell them that maybe even a developer is questioning himself how to do it. I don't know. Do you know what to do? The question is, can we insert multimedia inside the health? It would be nice. Where would you refer to the place where the media is going? Yes, eventually. Or more only for you who writes health files. So you know what you're writing about. Okay. That would be nice. A screencast about the future. Yeah. My answer to that would be also, on the other hand, what are the best views of the developer style? Again, it's enough to draft something. And for the presentation people would be able to publish that based on the information produced, also videos and stuff like that. If the developer spends time doing the videos, he cannot develop the next feature or fix the next part. So I think it's also important to find some runs. On the other hand, I would really encourage everybody from you to try the health content or that health offering extension. It goes really great. Thanks to Jace, and like every, especially we are pointed out like every even small description as he has used the one line from MiGlosh to write the health page. It just helps. So I would like to encourage you to do that. And if you're wondering, do you know how much mishap we have to get away from measuring that? No. No, I don't have. You have the button list. I have the button list. There is some open box because documentation is not there. That is not that much. Because when we switch to the new technology, we brought all the connections to the health content and we didn't change too much. But new features get inside the code and there is no documentation. So it's not that much, but there is quite a few. The new functions in Calc that I, Radke, and with free donkers are doing, for instance, I had to go to Microsoft documentation to get it. And it's not that easy because I cannot just copy-paste Microsoft documentation. That's not fun. We get trouble after that. So we have to write something new. Okay. More questions? Would it make sense so that you have this list of areas which are not documented? Yes. One thing that works really well for bugs is that we try to find the developer who to blame for something. And once you have a blame list and your name is on the list, you try to do something. Okay. So maybe would it make sense to build such a table with areas and next to the and some name. The developer can just go to that list and see if he or she is on the list. I can do that because I follow the development closely every day. I know who is doing what.  More questions? So just that I got it right. So there's the weekend and there's the health content and it's maintained separately now. What's going on? So it works so that the XHP files are still the source and the L is generated for that. Okay. Excellent. Because that will be the next disaster. We are not duplicating the work. And also the XHP file directly affects translators mostly. Okay. Yes. In the health file which you open in the office, I don't know if you're here now, but if there are people that we can paste it in the health file, what would that be implemented if it's not existing? I think I press F1 and how to open a document saying there would be an explanation in the health file, but it's not necessarily that. It would be in the online version, but in the version on the computer. If you download the help locally, you will get the local help. Yes. If you don't, you get the wiki help. It's supposed to be the same. Good. It's supposed to be the same. But in the local help, there should be a link to the online health in the health file. So I can press that and then read and maybe add it to the online health. Right. At the right place. No. The problem is that the online version is not editable. It's still the... Sorry? I did not know. Yes. It's still that the XHP files that I have compiled, either to the online version or to the offline version, still have to be edited separately. Unfortunately, it did not have to make the online version editable. It just didn't come to the end. So the XHP files are still the source. So when you add the offline version, it's the same. That is what you would have in your online version. So it probably doesn't make much sense to have that link. On the other hand, Jay had some good idea that we probably could get some online editing, some easier writing, compared to what was done earlier today. Using some online, it's not editable. But you can see it as the pop-up. I think it helps. So people are likely to do the same thing.