 Good afternoon Close enough to go time to get started. I think hi delighted to see so many of y'all here Do come up the front. I'm expecting heckling and shouting and that'll be more effective if yous are closer My name is Anthony. I work for Irish web development shop Anartek and I head up the support team So I care quite deeply about performance Cause set slow sites make my clients sad and it's my job to keep our clients happy It's my job to keep them happy after Anartek delivers a site But it's also my job to make new clients happy when we inherit sites that other people have built so one might say that I'm a combination of a cleaner and a rubbish man and Dreammaker so What you're about to see is Well, I've basically taken a vanilla install added a few modules and broken a website So that it's really awful and all of the evil That I've committed like a James Bond villain with the white cat and the shark tank It's all been inspired by real-life examples of stuff that I've seen on production sites and Some of it is mind-bogglingly stupid but I've Contrived some examples to show the sort of thing that we've had to fix over the last few years And we've fixed them and ripped them out and cried into our beer over them so Many production sites were harmed in the making of this talk, but you'll see none of them today. It's all the fake site We're talking about Performance in terms of how to build websites and it's the stuff that anybody can use on any hosting platform We're not talking about server side magic like engine X and varnish and then cash and all that sort of server voodoo We're looking at the basics from the browser to the server and communication and All the stuff that really matters the stuff That you can't fix very well by putting varnish in front of it So this is where it gets hairy. We'll do some live demo And this is where I'm expecting shouting and heckling so I'll be asking questions. I'll be looking for suggestions shout I Will repeat the suggestions and we'll see if we can fix this site so here is a site I prepared earlier now imagine you're in my shoes and you get the call from a client our website is down say 503 error or 502 maybe the database server isn't available and They're going our side is broken our side is broken So you go and you look at the server logs and you find a couple of URLs They coincide with a side outage And maybe this is one So you load it up and you wait and you wait and you wait and Then sure enough something falls over This won't fall over, but it will take over a minute to load so What's your first protocol if you were in my shoes? What's the very first thing you might which? Slow queries, okay, and he advances on slow queries What's the first page on the Drupal admin screen you might go to? Reports Yeah Anything else Go again Okay, well, let's have a look. Let's have a look at the logs. Shall we? so we've got Reports and we've got recent log messages Let's have a look so I cleared the logs before this talk. Oh my goodness You will note that the logs are dark and full of errors So that's not a good thing, right? So we know we've got problems Why or else could we look to get information? Where could we look for clues? Definitely slow queries we can look at And there's a cool tool while you all have to think about where we might look there's a cool tool That I will turn on now Called web profiler. I will turn on now if the extend button works Yeah, right, so here's where profiler and this is part of develop and it's New in Drupal 8 because I think it comes from Symphony. I wish I had this in Drupal 7 But it is wolf wonderful and I'll show you why so web profiler in concert with Say actually, let me stop this The built-in browser tools like web inspector and Chrome is a godsend and specifically the network tab So if I reload We can see everything that is being downloaded as it's being downloaded. We can see how long You have to wait for every here check it out see this This is the HTML and it took oh my goodness. This is crashing my browser It takes about It takes 12 seconds for the HTML that just ain't cool Now whilst that's loading here's web profiler. It gives you this cool toolbar It shows you how much RAM is being used just for this request and you might not care but think of this an average Amazon virtual machine Has 256 meg of RAM for PHP out of the box, right? I think it does anyway If this request takes nearly a hundred meg of RAM and you get three requests The server is gonna start complaining and people are not gonna get their responses So that's something we need to look at Then we've got we've got database queries this big red error here is showing two and a half thousand database queries So we got to do something about that too, right? So what can we do? I Guess we should I Don't know maybe we'll look at the performance page See what we can do there. Let's stop This one actually because it's slowing everything down. Okay, you just stop and We'll look at performance. We'll see what we can do so configuration performance We'll see what we can do Okay, so we can aggregate some CSS and we can aggregate some JavaScript That's okay, right Why does that matter? Any ideas? Exactly few around trips each HTTP request involves Around trip to the server and overhead to the server and time So we want to minimize that right so I Happened to know that we had who I don't know two thousand requests in on that view so Aggregating our CSS and our JavaScript that's gonna help right But What I've come across a lot is people listing Stuff they don't need to list or listing stuff Say hey, give me all of our events ever and you maybe have 500 nodes So that's pretty dumb So let's have a look at the view Because this is nicely named broken view is a clue What are you your performance here's our view here's our view So what can we see that is wrong with this view? Any suggestions Okay displaying all the items. Well, that's an easy thing to help Put less rubbish on our page So we can display a set number of items Say, I don't know 25. It's probably better and we can give it a pager Yeah, that's probably fine What else can we do cause in the interests of time because you know, this is a short show and tell right? In the interest of that we'll do everything we can here on the view before we run the page again Things that will slow down your view are needless sorting Now Respect to Jochen and Frystall box for this He was explaining how an unnecessary sort on a big enough result set will crash a database server And by default views will give you a sort So don't put it on unless you need it oftentimes We're only using views to pull out data and then we're processing it and sorting afterwards So Don't do it if you don't need it. So let's get rid of a few of those We can get rid of that we can get rid of that Sort of let's get rid of that be extreme another thing that's worth checking for is in query settings Distinct will slow things down when I started writing SQL first Back in the dark ages. I loved distinct So that might all help Um But what else what else is this actually showing? I wonder We've got What whole nodes? We've got ooh All of this share messing We've got images We've got comments we can show less We can show less because our Did anybody notice how big the HTML was I? I expect That it is Oh, no, it's gone Oh, well, it doesn't matter We'll show will will fix our view and we will run it again so let's show Hey, let's show feels they're more lightweight than a full node Let's make sure our image isn't showing the original image Because why would you want to derive damage? Why would you want to use an image style? Make it smaller, but also make it physically smaller as in like pixel dimensions, but also Drupal will compress it It'll only do jpegs. I think but if you use something like re-smush it and Get it to compress your derived images Then that's a win. So it's all about reducing the amount of data that has to come down the wire So let's give it a large image. So we're reducing our size of our images. We're reducing the The weight of all of those assets Save that and we'll see What difference this makes? So if we recall this took a minute to load it had 2,000 requests and it was about 20 megs in weight So let's go Still not great It's doing something stupid in the background. So our HTML is still taking six odd seconds To be generated There we go, so we've got 67 requests hell of a lot better than two and a half thousand 700k transferred. So that's good. That's down from 20 meg. We're finished in nine seconds That's good Okay Why else would it? Why is it taking 691 queries there's a question Next place to look I guess is gonna be custom code There's always some Somebody's always done something stupid Happily I have a module full of stupid so Here's something that I saw in real life that made me cry They're loading up menus any any node that was in a menu Loaded the menu traverse the menu and loaded all the nodes in the menu I can't remember why but it was mind-blowingly done So we're we're doing an awful lot of node load here that we don't need to do so. Let's stop Let's just kill that dead That ain't good, right? Okay, we'll try that We'll do it again See what difference it makes Oh, that's better. That's given us a third of our DB queries Another stupid thing That you see around the place is leaving log messages in that you don't need Every one of these log messages is a right to the database and if you're just serving something Like you're making a request and you're getting a page back You don't need to be writing to the database and writes are expensive. So let's kill them. Oh Oh My goodness, what if you've got undefined variables? That's a right to the database. We should kill that Where are we loading nodes? Oh, we're iterating over our result set. Maybe we're gonna Maybe we're gonna process it somehow Chances are the data is already in views in the view that you've just gotten the results from so needless node load nodes are Great great evil and more useless logging. So we'll kill that We'll kill that and we'll kill some more undefined variables And we'll have a look and see what we can find We are now down to 68 requests. We're finished in three seconds Can we get faster? What's fast enough? three seconds is too slow Because think of this you're in a conference center with You know world-class Wi-Fi and it's fast What if you're in a field on your phone? In a 3g area. Oh, it's not that bad. It's not that bad. It's only six seconds What if you've got a bad connection on slow 3g on your phone? It's a lot slower. It's still coming down the wire It's all about the payload because Drupal's done its job. It served all of the stuff But it takes ages for your payload to get down the wire 10 seconds so Let's have a look at what else can we do I wonder is this being cached? Because caching your browser will cache stuff as much as it likes it'll cache images It'll cache static assets like CSS and JavaScript Your Drupal install will cache pages unless it isn't doing and You can check here in the headers. You can see. Oh My goodness something's making Drupal never ever ever cache this page So even though we could go to views And we could tell views Hey, let's oh, sorry. It's not in query settings. We can tell views and this is not a bad practice. We can tell views Cache this please you can do it like Every so often refresh the view or whenever there's new content or stuff like that refresh the view So we can get views to cache, but we can also make Drupal cache Now Drupal is not caching Any ideas why there's two? Obvious modules that are common culprits for this that'll stop a page cache Any suggestions and it was the same in Drupal 7 Blocks Don't think so I suppose it depends on the block or honey pot honey pot will catch you out a lot Don't think develop will necessarily But honey pot does if you have honey pot protection the time-based Protection from honey pot on any form and you say half. Oh, I don't know a login block on every page And it's protected by honey pot then no caching cyanara So let's kill honey pot and there is also another module that is useful, but dangerous that'll set HTTP headers and That can be Useful Except when you set don't cache headers. Here we go. HTTP response headers use this with caution because if you tell it don't if you'd like say don't have cash it won't cash if you say Set the the time for caching the expiry time to zero it'll never cash anything So that sucks But it looks like I haven't turned it on so that's okay. Oh, no, I haven't Let's kill that so When that finishes saving and honey pot is gone We should start to get more results We're already down to only 137 queries Let's run the second time cuz doubtless. It was clearing caches There we go 102 queries Now see this time to first bite 800 milliseconds so content is hitting the browser in under a second And you can see down the bottom here The Darm is loaded in one and a half seconds and the whole kit and caboodle is loaded in two and a half seconds Down from a minute. So not too bad If we wanted to further improve it We could look at what is going on here. There's something crazy going on here Where we could Trim all of this Ridiculous HTML There's no need for an entire body I'm also conscious that we've only got three minutes So the things we could do to make it better is compress our images More compress our CSS more get advanced aggregation going on compress all of the CSS the JavaScript minify it Trim the body text Maybe use smaller images And it'll all add up to more payload savings fewer requests faster site happier punters and with that I Will just go through the principles over the next minute or two Principles that I've just talked about so But less rubbish on your page You don't need to show all of your events all the time minify your assets compress your images You want the file size the total page load down small small small remember the farmer in the field with the crappy 3g connection Every HTTP request is an overhead You want to aggregate your assets you want to make as many as few requests as possible Get views to do the hard work once and save what it's doing get the browser to cash your assets Caching for the win and then of course get a proper posting environment and use varnish and engine X and that Get to know web profiler get to know web inspector and The network tab in web inspector because it is a godsend don't forget about the farmer and This is nearly the most important in any build any interaction with a client any interaction with You know back-end team or God forbid the front-end team Champion performance tell them no they don't need that extra image show less put less rubbish on the page and Users will thank you for it As I thank you now, so we got like a minute So if anyone has a question rock up to the mic and shout Otherwise, you'll have a nice day Okay. Well. Oh, do we have one? Do we have one we do? You switched from full content to fields. Yes. Is it faster if you switch to let's say a teaser? I suspect Fields are a bit faster, but I I haven't done scientific tests Really, I just knew that I had three fields ready to go. So it was convenient. I could have died teaser was the other option, but There's I guess there's more setup because you have to go into the teaser in the content type and Mess there as well. Whereas I could just do everything in the views UI By using fields, you know So I don't didn't have a good reason for using fields, but okay. Thanks a million for listening you guys I hope you learned something useful. Oh, yeah, and go to the sprints tomorrow and evaluate the session