 also jump in. I don't think it's, you can probably still do this by the end, but there's lots of time for questions. So even as we're going through, if there's anything you question you want or want some more detail about something, want to do, beer off on a bit of a tangent, just shout out and let's, you know, make this interactive. My name is Martin Anderson Klutz. I'm from Digital LeCidne, in case you couldn't tell. And yeah, here to give you all a sense of what we can do to make Drupal fast with our Drupal websites. So first, let's start about talking about why is it important if our site is fast. I mean, as long as it does the right things, it doesn't really matter whether that page loads in 12 seconds or 6 seconds or 2 seconds. Well, here are some business examples of where making some small technical adjustments actually made a quite sizable and measurable difference to the business. And, you know, you can look at these slides afterwards. I won't go into reading all of them, but to me the big one that calls out is Netflix as an example where by tweaking a single optimization, they were able to cut their outbound network traffic in half. And if you can imagine what Netflix as a company pays for outbound bandwidth, you can imagine how much money that single tweak managed to save them. So think about some of these optimizations and the difference that they could make to your business, whether it's in hosting, as well as some other things that we're going to talk about. But not just in terms of why important or speed is important to you, think about why it's important to your users. So here are some stats around what users expect from the speed of a web page. More than half expect a page to load in 2 seconds or less. Lots of them say that they'll abandon a site that takes more than three seconds to load. And as soon as it goes one second beyond that, you start losing customer satisfaction. Again, almost half of online shoppers say that a slow site is one that they're not going to return to. And one that I find really startling is that almost all mobile users expect the page to be faster on their mobile device, even though lots of times they may be accessing it over a slower network. So think about that in terms of how you build that page and that experience for your mobile users. Definitely one of the culprits here is bloke of web pages. So here's an article that was in Wired last year talking about how the average web page size had now reached, actually in this case surpassed, the original size of the Doom application. You know, the game that people download and install on their computers and play for hours. Every single web page on average was bigger than that whole application. And the irony here is that actually at the time the Wired home page was even well in excess of that average. So they were as guilty as anyone. But back to the benefits of being quick, there's definitely a user experience part of that. And I guarantee that whoever paid for your website to exist wants it to do more than just exist. They have goals for it. And as we've talked about, to the extent that you're making the site better for your users, you're going to improve your conversions and your ability for your site to do better against those goals, which in any commerce standpoint may translate into sales or dollars. But they're also SEO benefits to having a fast site. Since 2010, Google has cited page speed as a ranking factor and also indicated that anything above two seconds to load will slow down or impede their ability to crawl your site. So think about those two factors and how much SEO traffic could be losing by having a slow site. So let's talk about performance from more of a conceptual standpoint and understand some of the deeper topics within performance. So this is a very crude model of what a typical request to a web page looks like. The user sends a request to the web server for a page that goes through Drupal, which then pulls information out of the database, gets that back, does some more complicated things, sends that back to the user. And then based on that information that it's retrieved, then the browser goes out and fetches a bunch of more assets. You know, images, JavaScript, all of those kinds of things. This is demonstrating some typical elements that you would find in that scenario. So the browser maintains its own cache, so if it already has loaded previously some of those assets, for example, then it might not need to go out to the web server to get those. And Drupal has its own caching mechanism so that to the extent that it has some of these things pre-rendered, it can serve them up again without having to go deeper and retrieve more data or do more application logic. PHP has what's called an opcode cache. So PHP is runtime compiled, which means that it takes all of the readable code and compresses it down to things that can run more quickly. And an opcode cache just saves that compressed code so that it can be reused again and again and make the page load faster. And then in a highly optimized scenario, we start to get a bunch more elements. So Varnish is a reverse proxy server. It basically will store this fully rendered page and serve that back to the user to the extent that the request that it sees is the same as one that it's seen previously. There are different things that we can do in terms of caching not only the whole page, but even some data. And so this is sort of within the web server or also between the web server and last while there's some optimizations we will talk about those later. And then the other thing you can do is a content delivery network. And what that does is it has a network of nodes across the globe often. And the idea is that those requests can be satisfied from a point that's physically much closer to the user so that rather than having to retrieve assets from let's say a data center in Atlanta, if they're in London, England, they might be able to get those assets from a data center in Manchester, for example. So it's that idea of reducing or increasing the physical proximity of those files. But the general thing to think about when we look at this is that the closer to the user you can satisfy the request the faster it's going to be for them. So in general you always want to put the mechanisms in place to satisfy as early as possible before they have some people all the way up to the database and pull all of that data out fresh. So in terms of measurement, how do we measure performance? So an early one was page load which is just from the time the browser requests the page how long does it take until that page, the fully rendered HTML page comes back from the server. But that incorporates only the page as opposed to a more holistic way which is the full page load which includes things like JavaScript, images, maybe third party assets, all of those kinds of things. Page render starts to look at from more of a user experience standpoint in the sense that page render starts to look at not only the time for all those things to come back but then for the browser to actually render out all of the different CSS, execute JavaScript and all of those kinds of things. First paint builds on that idea by measuring what's the first point at which the browser starts to render something. So where the user isn't just seeing a white page but actually starting to see your site and time to interact builds on that by saying what's the lapse then before they can actually start doing things on the page. And if you're looking at performance on more of a macro level then request per second is useful by starting to see what's a bulk number of request per second that that server is capable of serving. So in terms of the tools that we can use for measuring there are online tools like webpagetest.org alert site. I think there are even some Amazon instances you can spin up for remote monitoring but basically the idea is you point it to a URL you tell it how many tests perform and then it'll go out. Oftentimes you want to give it a number of them to do so that you can average out any kind of network effects and then it'll give you a sense of how fast is it, where are the bottlenecks, are there certain elements that are slow, why slow and Google page speed are both kind of browser extensions you can use that will give you a sense of where the problems are, give you some recommendations on how you can improve speed and Google Analytics there's some information there that you can mine in terms of understanding page speed more from the perspective of your user which is useful because remote monitoring you're picking a location to measure from why slow and Google page speed are giving you data versus where you are but Google Analytics is really from the perspective of your actual customers you know how fast is it taking for them and so that sometimes that's important to look at too and then New Relic can give you a sense of performance but actually starting to dig down new code. So let's look at some of these tools quick here's a webpagetest so you can see across the top we've got some of those average kind of scores and then it's also drawing vertical lines that correspond to some of those things that we talked about so the the first paint you can see is on there to the far right document complete is is when everything is fully rendered and so as you look down on the report and you can see all of the various parts of the of the single page the home page of a website all of those various elements being loaded it's showing you all of the the different domains that they're loading from in the file and and you can see based on the bars and let me just flip back to the top so you can see the green is the time to first byte so that's the delay before anything starts to come back and then the blue is the actual time for the asset itself to load so for a number of these there's actually more of a weight than than the time for the asset itself to load and that really talks to the the power of things like aggregation because rather than having to make a bunch of requests each of which has its own delay you can load one aggregate asset that then you know satisfies the same end goal here's another thing that you can see further down in the report which is taking all of those things but looking at it on a connection view which is useful because you can start to see what are the actual elements or domains that are giving you the biggest slowdowns so when we ran this report for one of our clients the thing really jumped up for us was this one here and we did some dating that ytimg is actually youtube assets the client had asked to have the youtube youtube video embedded on their home page and what we started to realize when we looked at this report was that all of the assets that that meant loading on page view were dramatically slowing down the actual low page load so we were able to kind of dummy it in with the static version and then on hover swapping in for the real player and that dramatically improved our page load time this is looking at yslow so you can see here it'll give you kind of a letter grade on all the different aspects of your web page it'll make some recommendations you know where it sees discrepancies against what it would consider best practice and then it'll also give you a breakdown in terms of the types of assets and then if you expand it the way javascript is expanded here it'll show you the individual ones both uncompressed and if it is compressed what was the compressed size so the again you can start to see what are the different elements within each of those categories and which ones are contributing to the load of your web page and it gives you this nice pie chart so you can also see which ones are well suited for caching so on a return visit you know what would be the difference in speed for you know empty versus a prime cache here's a similar view of what the google page feed insights would look like one of the nice things here is that it actually has recommendations specific to both mobile and desktop but again you can see that it has very specific places where it'll say you know we think you could make your web page better by fixing these you know specific things so here's an example of google analytics and you can see some of the elements here where again it's giving you and this is more site-wide in this particular case average paid load time average server response all of those kinds of things but on more of an aggregate level it is possible to drill down so you can see here where it's actually looking on sort of a per URL basis um some of the gotchas or potential gotchas here are that sometimes depending on which variables you're telling it to ignore it may aggregate up together a bunch of things that really from a user experience standpoint feel like different page loads so the top one here is index.php which I think for this particular site and you can tell by the number five down there that this was an older web application that took parameters almost as really the true page URL so to the extent that it was ignoring ones it was rolling up together a whole bunch of pages on the site and you can tell by the drop off you know from that one to the ones below that really what you'd want to do is is have it break some more of those out. This is looking at new relic which is an application that um gives performance monitoring but really more from a server perspective and the benefit there is that it can actually tell you what parts of the code are starting to slow down or or cause things to run slower which ones are taking most time so here's an example of where it's showing the transactions that are the most time consuming overall for the for the site and it gives you those nice charts I mean one of the things that's nice about new relic as well is that because it gives you that time basis you can also pay attention for example if you're launching modifications to some of your code if you see a corresponding spike you can start to know you know that looks like it may have negatively impacted the performance when we launch that thing so there are some some things that way where you can look at it you can compare it to prior measurements and some of those kinds of things and here's another example again based on the transaction which is really sort of the PHP function with some of the charting but you can also look at it on a module basis so to see you know in this case views was number two but there was this um looks like a custom module that was that was really chewing up resources and slowing things down. Show of hands was anybody in the the previous session on PHP profiling next door so all that stuff on Blackfire was great I mean that's even a deeper view in terms of you know the code and being able to look at very specific measurements not only at a function level but but even you know the child functions so if this this is the kind of work that you're going to get really deep on then then definitely something like that could be useful. What are some of the ways that you should look at performance in terms of understanding your audience I mean certainly geography is one if almost all of your customers or visitors are going to be coming from Canada then you know it makes sense to to look at measuring the the site in ways that relate to that geography in a similar way if they are all going to tend to be using using let's say older browsers or handheld devices um you know calling in from rural networks those kinds of things then understanding your audience can help you to measure the site that are appropriate to your particular application and what are some of the key factors in terms of performance what are the things that can make your site faster slower well as we've already talked about page weight is a big one so if you have giant images and you're you know rendering out 18 pages of content every time the home page is loaded those things are going to slow down your site the number of requests as we looked at you know if you've got 300 elements that have to be loaded in from 60 different domains for every page request that's going to slow things down and third-party assets that touches on that too because particularly for what are called blocking elements so the things that have to be retrieved and rendered before the page is visible the slowest of those things will impact the user's perception of your site so you may be loading things that are part of the layout engine that are coming from a server that's really slow and even though your server is really fast the user's perception is that the site is slow even though it's not anything that's specific to your server so to the extent that you cannot rely on third-party assets you're probably going to find you do better with performance delivery so you know the the speed of your server and the connection that it has to the internet all of those things will definitely be a factor server we just talked about and then also just the complexity of your code so if you're running you know a Drupal application with 300 modules and a bunch of front front end widgets all embedded in it all of those things are going to negatively impact your speed so does anybody have any things that we haven't talked about in terms of you know methods or tools that they like to use for diagnosis speed issues all right well let's move on so let's talk about what are the things that we can do to to improve speed so the biggest one is to just keep it simple to the extent that we don't have to have you know you know 60 images on the home page and you know an interactive chat widget and you know all the latest you know javascript ajax headless sex to the extent that we can keep it simple it's going to make our life easier in terms of keeping the site simple so trying to understand that as part of the overall site concept is definitely very important so part of our strategy should really be to do less so to the extent that we don't need a bunch of libraries that we don't need to load you know 50 fonts from a google that we don't need modules for things that really aren't required for the core user experience that we're trying to create try and leave those out of our site strategy and some people have even gone so far as to build what's called a performance budget so to set up the outset what is our goal in terms of how fast the site should load and then any time there's discussion around should we add you know this gigantic image on the home page or you know some other new site element then that can be tied back to this performance budget and say if it's so critical do we add that then what can we give up to maintain our budget because we understand that we have this goal that we're being held to um to that extent um has anybody ever been to this site should I use a carousel dot com that's great right so so the whole idea is it prevent presents a lot of you know relevant facts around you know the effectiveness of web page carousels and particularly on home page and I'll give you a spoiler that you should never use a carousel is basically what it amounts to so from a front end perspective what things can we do to improve site performance you know definitely a big one is around images so we want to compress images as aggressively as we can without really visibly degrading them don't make images don't load images that are bigger than you're displaying them I mean oftentimes you'll see sites where they use CSS to shrink them and really we're loading much bigger images than we need to even lazy loading an image might be a consideration for some sites if you have to have a lot of images use javascript to make them only load as the user action scrolls down so that they don't have the sense of waiting for all of those images to load some things particularly CSS libraries like bootstrap may have all kinds of CSS in them that never actually gets used on that particular site so to the extent that you can use CSS that's really pared down to what you're actually using that will help same thing with JS if you don't need a bunch of dynamic elements or things to be done in in such a complicated way if you can keep it simple and really only need the things that use the things that you need then that's going to help and then also there are there's a technique around putting again elements particularly things around you know more advanced styling if you can put those in the footer of the page then it'll let the page be rendered as it's still downloading elements as opposed to forcing everything to load and then you get that sort of flash where everything appears and so then again from that first render perspective you can help the user to feel like your site is fast even though it may still be elements of it loading and being more refined we mentioned caching before so this is actually I think it's originally from Acrea but it's on Drupal.org to sort of give you a visual sense of how cache works again ideally as much as possible we would want to give the user a fully cached page so you know a reverse proxy you know the exact page that the last anonymous user asked for let's give them the exact same thing and it never even has to hit the web server varnish can satisfy that directly but then moving down you know if you've got at least page cached within Drupal that will be relatively fast and then if not at least parts of the page you would want to have rendered so again ideally as much as possible of of the overall page you want to have cached so from a site build perspective definitely caching is a big one aggregating CSS and JS is another important one again from that idea of reducing the number request to the server and and we'll talk later about some fairly advanced ways to do that and then also not having modules enabled that aren't even in use statistics is a big one oftentimes that's enabled by default for sites that can really slow down the web server and oftentimes people aren't even using the data but it adds a lot of extra sort of database traffic to the overall website UI modules is another one that we see in production how often are people really tweaking their views oftentimes they're really just going into sort of update and edit content so to that extent leave things like views UI or field UI disabled so that you're not creating that extra memory overhead and then search is another one if you're on let's say pantheon or aquia or even if you just want a better search experience for your users you might look at using something like solar at which point you're really you're typically offloading all of the the sort of computational overhead of indexing your web content and searching against that from the web server off into your solar application and so that can definitely help your website some modules that you can use include the site audit so that sort of renders out this long report about your website has a lot of information about caching as well as a very variety of other best practices so that can be a really good one to to start with in terms of showing you where the gaps are and where you can potentially have some really low hanging fruit there's a module called advanced aggregation that can be really powerful so you've got in core the ability to aggregate into single files but in terms of making the best use of your connections between the browser and the server sometimes people will find that it's better to have those broken up into two or three files but you know again that's the kind of thing that you'll want to tweak and find our find what's works best for your particular application I think it can also do some things like keep local copies of some things like let's say Google fonts so that again you're not having those extra connections that your user has to go and like negotiate SSL with another server and you know get that the lapse again in terms of establishing those connections APDQC is a module that does a lot to optimize the connection between your web server and your MySQL database so that one can be quite powerful too if you're using entities on your site in Drupal 7 you would want to add entity cache that's actually part of core in Drupal 8 fast 404 is good especially if you're transitioning from a non-Drupal site to to one that is Drupal in the sense that if you're expecting to have a lot of 404 errors you know web addresses that don't exist anymore rather than have Drupal serve up those 404s fast 404 basically reroutes reroutes those two static files so that they can be just served out of a patchy cache as opposed to rendered through you know the more expensive Drupal engine and then in a similar way syslog rather than writing through the watchdog system which goes into the database this log actually writes to the like the patchy error log instead so it's again much less overhead and in terms of the hosting environment to the extent that you have the ability to go in and sort of tweak the server you can do things like making sure that gzip is enabled for things like css and js files having a reverse proxy like varnish or boost is a huge help often content distribution network as we talked about can be really really powerful also can be kind of expensive so it's probably not for everybody having a data cache like APCU is really good and can again provide a really huge performance benefit by reducing the amount of traffic between the web server and the database and then even the version of PHP that you're running so PHP 7 is often much much faster than older versions of PHP so let's talk about what's new in Drupal 8 that's related to performance as of Drupal 8 we now have full support for PHP 7 which is a big win as we talked about before entity cache is now in core and there's also cache for login users so Drupal 7 below had a really good caching mechanism for anonymous users but the minute somebody was logged in essentially all of that was being rendered on every page load and unless you use something like off cache but then that was a contrib module that could help solve that but sometimes would run into sort of some configuration issues so Drupal 8 has put a lot of work into that and it's much better you can declare asset dependencies so things like let's say jQuery Drupal 7 and below would load jQuery for every page whereas as of Drupal 8 it tries to only load it on those pages where it thinks it's actually necessary based on what's been loaded into the page so again from that idea of trying to keep things down to the actual minimum assets that are necessary in terms of cache can be much more granular in terms of what gets cached and under what context and to that extent there's actually this cache context API where you can even do custom declarations around if you have a certain type of customer or a geographic region that's custom to your particular company you can declare what gets cached and when in a way that's really tightly suited to your particular application and then Drupal 8 also introduced this notion of post render cache the idea of putting an element into the page load for the sake of being able to send it back to the user but it's actually going to get re-rendered after the page load and the idea being that if for example you have some elements on the page that are going to be dynamically generated let's say it's you know most recent content and you don't want that to be you know cached for a set period of time rather than having it so that the page is never cached in Drupal 8 you can have it send sort of an empty block element that'll get replaced and the best example of that is actually in big pipe. Does anybody here use big pipe on other sites? If you've used Facebook you're probably actually familiar with big pipe okay let me just show you guys since we've got time for there's a demo that is on and see we're showing that there are elements on the page that are not cached so normally that would cause the overall page to not be cached. What big pipe allows is for the overall page to be sent through and then as the slower elements are actually rendered out by the server then it can push those elements and it replaces those placeholder elements with the actual you know customized slower actual content so you can see that so it's not actually in the examples they're showing it's not actually reducing the render time so much as dramatically improving the user's experience of of seeing that content because they see most of the page right away and then as those slower elements are available then it's pushing those through as opposed to making the user wait until the overall page is ready and then pushing that through as kind of a whole piece. That's what I was going to cover on Drupal 8 and then I was just going to sort of open it up and say you know beyond what I've talked about here does anybody in the audience have some thoughts around other things that they found helpful in terms of making their Drupal site fast. Well I will then throw it open for questions yeah so one of the things that the Google page tool recommends is taking the link elements that your CSS page has on the head and the JavaScript link down to the bottom and I don't understand why it is that that would be blocked because I kind of understand why JavaScript does it because it has to execute the JavaScript before it continues but CSS it's a lonely page which just doesn't have a thing has a style. It's because the CSS sometimes will have calls out to other things so from the browser's perspective it's waiting until it has those it hits those it sees those it makes those extra calls and then it's waiting to get those back before it's going to do its render so by putting them in the block it then it's going to go ahead and render what it has so far before it makes those calls even but again that advanced aggregation module can do some of that for you so you can basically check a box and say move those things down and it'll try to do some of that for you any other questions yeah yeah Google does actually have I think if you if you read in there there's a link off to the tool that it's using as sort of its baseline but yeah it it expects a very aggressive level of optimization and you know especially in those ones that have like the Google one where it has the numerical evaluation you'll probably never get a score of a hundred percent so it's sort of understanding trying to aim to see progress as opposed to saying like you know I have to hit 98 to to consider my optimization of success so it's again it really comes back to understanding what does success look like for your particular site um I was looking at a site recently where like the homepage took 12 seconds to load and so you know from there even if you can get that down to you know four then that's a huge win for them um but it's still well above what Google talks about as guidance of two seconds or less right so but progress is definitely always important so questions all right then I'll give you the rest of your day