In 2008 Amazon reported that an extra second of page load time would cost them 10% of profit. A decade is an eternity on the web, and Amazon was already the largest online retailer, but that wasn't an anomaly. Countless studies by other organizations have since produced similar results. You don't have to sell billions of products - or any at all - to see the effect that performance has on engagement. You also don't have to spend a dime to see where you might be able to shave time off of a website or application.
We will share how to audit page performance through the lens of user experience. We'll touch on which metrics are relevant in today's landscape and how to measure them. We'll also learn how to identify and measure the competition, both direct and indirect. We'll then combine those results with industry standards to create aggressive yet realistic goals. From there we can start identifying the low-hanging fruit to help us achieve those goals. The end result is an improved user experience that realizes lost engagement.
This session extends its welcome beyond those typically keen to User Experience. It will not include code examples and will benefit both a technical and non-technical audience. Every tool we'll discuss is free and easy to use. A basic understanding of web requests will help, but it requires no prior knowledge.
Transcript
Gus Childs: Can someone in the back close those doors? That would be much appreciated. Awesome. I think I'm pretty loud at this point. If anyone in the back can't hear me, wave your hands, do whatever you need to do. Thanks for sticking it out through the end of the day. I know it's been a long day. This is a late session, so I appreciate your attendance. Here we are for Everybody Loves Performance: Easy Audits and Low-Hanging Fruit.
Going to hit you right off with the same statistic that's in the session description and that is one of the most well-sited web performance statistics that's out there. Amazon sees a 1% decrease in revenue for every 100-millisecond increase in their load time. For every 100 milliseconds they're slower, that's 1% of revenue they're losing. What isn't always mentioned when people cite that statistic is that it's actually from 2008, so it's basically almost 10 years old.
That said, not much has changed with regards to web performance in the last 10 years. BBC just last year cited that they lose 10% of users for every additional second of page load time. BBC is a different organization. Obviously, they're not selling products in the same way that Amazon does, but time and time again organizations that are running these studies are finding very similar results to this. With all of these numbers, obviously, this isn't always the case. What we're starting to see is that one second is about 10% of your engagement and, quite often, your engagement is directly tied to your revenues. One second slower on your page, 10% of your revenue could go just like that.
Google's even got some numbers that are a little harsher. On this one, they like to say 53% of users abandon sites that take more than three seconds to load. While you might be losing 10% every second, once you hit that three-second part mark, you might lose as much as half of your user base and, of course, they're going to continue dropping off from there the longer it takes. For that reason, Google has actually stated that their PageRank algorithm is going to start punishing really slow websites starting in July 2018. We're only a few months away from that. At this point, we've got to speed up or we're going to lose the race.
Really the reason that it's so important and the reason it's in this track, the user experience track, not necessarily a track that performance might normally fall under, is because performance is user experience. Google is punishing slow sites because their users are going to get a worse experience. They're in the business of giving people a good experience. We all are, hopefully. That is why performance is so important. With that, we're going to talk today about what was promised in the title and the description. Two things; easy performance audits. Then we're going to talk about once we've done those audits, how we're going to improve our performance.
I'm Gus Childs. I'm a technical project manager and front-end developer. Gus Childs is my handle basically everywhere, Drupal.org, Twitter, GitHub. If you end up with any questions at the conference or later and don't get a chance to track me down or ask them, you can find me there. I work for Chromatic. Chromatic is a fully distributed design and development and DevOps and support agency. You can find us on the web at chromatichq.com. I've got the Twitter handle in the bottom right of every slide, so feel free to reach out to us at the same time with any questions.
Let's get right into it. Conducting easy performance audits, I like to break down my audits into five different pieces. We're going to go through each one of these individually in greater detail. Those pieces are metrics, tools, benchmarks, goals, and results. First up, of course, out of those are the metrics. What should we even be measuring when we're conducting our performance audits? Again, I know I'm going fast. The slides will be available online. I think they're pretty helpful on their own, so I apologize if I go with a little faster than notes can be taken. Again, first part of our audit is our metrics. What are we going to measure?
We want to measure these five, or at least these are the five I like to measure if I'm paring it down. We've got our speed index, our time to first byte, our start render, our load time, and then our fully loaded. Once again, let's drill down into each of these one by one. First up would be speed index. This image right here explains it best. That's what's called a filmstrip. What that does is it's loading the DrupalCon Nashville site on a slow connection really only about five megabits per second, so maybe equivalent to what we're experiencing here at the conference. It's a real-world example of testing on a slow connection. This is showing what the loaded site looks like after every half of a second.
You can see that users are seeing nothing for about a couple of seconds, and then they start seeing something, and they're thinking, “Okay, I'm actually getting somewhere. This is loading.” Then after 3.5 seconds, most of their mobile viewport is filled with the content that they're going to get. That's what the speed index measures. That 3.5-second mark, when is their viewport fully visible. This goes along with a term that's come out, I think, in the last few years called perceived performance. Perceived performance is important because users don't care what your actual load times are.
The metrics we're going to end up talking about in just a bit, they don't care about those. They only care about having a good experience. For that reason, we or I at least like to focus on speed index when I'm doing my audits. That's the one number I look at the most. That said, all of the older metrics, they still matter. The rest of the four. Going through those, the time to first byte, it's a measurement of when you hit enter on your address bar or tap go on your phone, between there and when you get the first byte back from the server.
Then you've got start renders. Once you're getting bites back, when is there actually pixels that are starting to get painted in the browser, the first non-white content being painted in the browser? Then you've got load time. That's when the browser actually fires its window load event to say, “Hey, this page and the content that's on it, that's loaded,” so anything that's waiting for that can act. Otherwise, the user should be good to go. Then there's fully loaded. That starts measuring after the load time. It figures out when there's been two seconds of no network activity including everything triggered by JavaScript.
That's the keyword here. Including everything triggered by JavaScript, because, as we know, most sites have plenty of JavaScript being triggered. I'm not necessarily talking about react and those kinds of things. I'm talking about third-party requests. That's normally what ends up showing up in fully loaded. We'll talk more about that as well. Just a quick recap, there's the metrics, our speed index and then our four or more traditional older metrics. Now that we know what we want to measure, we got to figure out how we're going to measure that.
What tools should we use to grab those numbers? The three tools I'm going to talk about today ARE WebPageTest, PageSpeed Insights, and Lighthouse. They're all free and fairly easy to use, available online. Before we get into them, though, I'd like to say be aware of hardware and network specs for consistent results because if you're testing a site, maybe you're just looking at dev tools or testing a site on your local machine and saying, “Oh, that loads pretty fast on my machine.” We all know how that works on my machine. The saying is so dangerous.
If you're just using your fast network or your fast computer and you're not throttling them, you're going to get first, inconsistent results. I can't run the same tests as the stakeholders that I'm telling them their site is fast. They might experience different stuff on their hardware and obviously, our users are going to have a different experience on their hardware. We want all of the hardware and the network specs to be consistent regardless of who's running them, when, where, why.
First up, we've got WebPageTest. You can find that on webpagetest.org. It is free and it does have a consistent hardware and network because it's going to be running on their own remote servers every time and those servers and their specs are consistent. This is what it looks like when you go there. This is one of the oldest tried-and-true sites for all this, but it's super helpful. Fairly straightforward form. There's a lot you can do with it in the advanced settings. You don't even have to really get into all that. All you have to do to get started is plug in your UR and hit start test.
You can do interesting things like change what server it's testing on the browser, the connection, which by default is that five megabits per second, so fairly slow 3G almost. That's super useful, so I leave that. Then hit start test. It does its thing. It runs the tests on that server and then it comes back with the results. The most helpful part of those results for me are what's under the header performance results right there in the middle. We can see right there the metrics we were just talking about. We've got peed index, first byte, start render, your document complete load time, and then your fully loaded time.
Also, you can see in the top right, it gives you some grades for various aspects. How it thinks you're doing on those pieces. It works by running what's called a synthetic test. It's not a real user, they're running your tests. It runs three of those. Also, this is underneath what we were just saying, it presents you with the results from those three tests. You can click into the waterfall, you can go super in-depth. There's a lot you can dig into. You can click those grades I was showing in the top right. If it says you're not doing that great of a job at leveraging static assets, or the caching of those assets, or compressing your images, it'll tell you specifically what files it thinks you could be doing a better job with that on.
A little bit, in summary, WebPageTest is good to obtain those official metrics, the measurements we were just talking about, the ones that you're probably going to be sharing with your stakeholders, or maybe you’re the stakeholder and you want to measure those yourself. WebPageTest is really good for getting those metrics, but you can find your potential improvement. You can dig into the waterfalls and things like that. Then also it's a little bit more advanced, but if you're a developer, or have developers at hand, you can actually automate repeated tests on what's called a private instance. That can be super powerful and helpful as well.
Next up we've got PageSpeed Insights. It's a longer URL, but it's first result on Google when you google it. It is also free and also has consistent hardware and network. What it does it, once again, runs the synthetic tests on your site. It does it both in mobile and in desktop. It'll give you the information for those separately. Right now, we're on our mobile tab, we've got our desktop tab. What's really helpful with PageSpeed Insights is what's here, what I've zoomed in on. What it does it'll give you a 1 to 100 score on how well it thinks you're doing with optimizing the performance of your page.
On mobile, it says 62% so we're doing pretty good, but there's a decent amount of room for improvement. I think desktop was at 47% so even more room for improvement there, it thinks. Like WebPageTest, you can scroll down and it'll start to tell you exactly what it dinged you on. You can click into those and see lists of specific files and things you can improve. Again, super helpful. I like to use PageSpeed Insights to get that 1 to 100 score. Maybe as a stakeholder or for your stakeholders, you don't want to digest and learn about all the different metrics, and exactly what they mean, and worry about them, and even have an understanding of what numbers are even good.
Whereas here you can say, “Oh, how well does Google think I'm doing, 1 to 100?” If we're at 62, or whatever it was at, and we improved to 80, we know Google thinks our site is faster. If that's influencing search results, that's probably going to be a good thing for us. Then also finding those potential improvements again because you can click into those lists that it tells you where the remaining 38% is.
Next up would be Lighthouse. Lighthouse, if you have Google Chrome, you've already got Lighthouse. It is in the dev tools of your browser, but then it is also open source so you can grab it on GitHub and use it in different ways as well. Also free, but it's going to be inconsistent hardware and network. You can throttle the network. You can say, “I only want it to run this fast," a simulated slowed connection, but you can't really do the same thing with hardware. You can say like, “I want it to run twice or at two times reduction in my processor, four times,” but you can't necessarily throttle it so that if I ran it on my machine, and everyone in here ran it on theirs, they'd be the same exact numbers.
We use it for different reasons in that regard. This is what it looks like. If you do open up dev tools in the bottom of your browser, there's a small, I suppose, blue button at the bottom that says performance audit. You click it, it does its thing, once again, it's simulating a page loading in mobile. I guess as a side note, the reason all of these focused more on mobile is because if you catch all of the problems that mobile is having, you're probably going to solve for the other screen sizes as well so you want to default to mobile. I actually think there's a session on that tomorrow that looks really good. I would recommend it. I think it's all performances, mobile performance, but I could be wrong.
It does its thing and then it actually also gives you 1 through 100 scores not only on performance but on other stuff like accessibility, best practices, SEO. Again, I don't use these as my 1 through 100 scores because of the inconsistency, but it is helpful. You scroll down, you get more filmstrips, more of that speed index perceived performance thing. You also start to see some of the metrics that we're seeing in speed index. They've actually got some beta stuff in there for newer perceived performance metrics like first interactive and things like that. Again, scroll down, it tells you why it dinged you on your scores, lists of files that you can improve on, all of that kind of stuff.
If you want to take it one step further, if you do want to introduce that consistency, or use this in more powerful ways, you can clone it on GitHub. There's a ton of really interesting and exciting things you can do with it that warrant their own session on their own. I'm not going to go too deep into that, but it's definitely worth checking out if you're comfortable with node and that kind of thing, and are interested in this. Lighthouse to find those potential improvements. We don't focus a ton on the score and the metric from there. We're just really trying to dig into more the nitty-gritty.
Again, if you're a little more on the advanced side with the development, you could automate repeated tests. You could run bulk tests, you can get JSON back and do all sorts of things with it. What is funny to me is that all three of those tools are operated by, if not were originally written by Google, so it's silly to me that I end up using them all. Why do I need three tools made by Google? Why don't they all tell me the same thing? They don't. They say slightly different things, they're useful in different ways, so I like to use those, all of them, just to make sure I'm getting the bigger picture of everything.
One tool I will say I did not list originally but I will talk about is SpeedCurve at speedcurve.com. It is not free, but it can either run synthetic simulated again tests or real user monitoring. It'll literally sit on your page and pay attention to all the network requests and everything that your real users are getting. Then it'll spit it out into this really clean, and pretty, and fun to look at UI. It'll map your performance over time across devices. You can plug in your competition and keep your eye on your competition. It's got all sorts of bar charts and everything, and also waterfalls. A ton of cool stuff in there. Again, it's not free, so I'm not going to go into a ton of detail.
If you're looking to continuously monitor your site across devices over time against your competition and you want a really polished UI to see all that stuff in, I would definitely recommend looking into SpeedCurve. Those are our tools that we're going to use to measure our metrics and figure potential improvements. Again, WebPageTest, PageSpeed Insights, Lighthouse, and SpeedCurve. We know what we're going to measure, we know how we're going to measure them, but how do we even know what numbers are good once we start running our site through and we're getting three seconds for the speed index? Is that even good? Could we do better? We've got to establish some benchmarks here.
The way I like to do that is I like to identify the competition. I like to figure out the important pages I want to pay attention to. Then I'm going to measure those pages on my competition. When I say competition, this is what I like to use. We've got our current production site. It could be your current production site that you're trying to improve, or maybe you're going through a redesign and a rebuild and you want to be totally sure that you're not going to launch a site that's lower than what you've already got. Then you also want to make sure that you're going to do better than your competition.
I like to gather three direct competitors that are in a very similar space to what you do and then three indirect competitors that are absolutely killing it with regards to performance. As an example there, one of our recent clients, they sold sunglasses. They were going through a major software upgrade, a redesign, all this work. Again, we wanted to make sure their site was going to end up not only faster but way faster because it was pretty slow at the time that they brought us on. We looked at their site. We had them identify three brands that they're always keeping their eye on, comparing themselves to, competing for actual shelf space and retail stores. We got those brands from them.
Then we measured about 30 different brands in a relatively similar space, and then we found out which were the most performant. We ranked all the speed indexes and figured out which sites we were going to aspire to match or even beat. In our case, these ended up being a watch manufacturer, an outdoor gear retailer, and a handbag fashion accessory retailer. These seven properties are what we are going to measure to figure out where we needed to be. Then we're going to identify our important page types. We could but it's not really worth it to measure every single page on the site. Which one are we going to focus on?
We can't really just measure the homepage if other pages are critically important to the user experience. Again, e-commerce, we're selling sunglasses. These are the pages that are important to us. We've got our homepage, the product listing page, it lists a bunch of products, the shop all page which is really important to them. It's their PLP but it lists all of the products they sell, which apparently a lot of people use that page for them, the product detail page so the individual product with the most important part of the site, the add to Cart button. Then a collection page which is just like a content-heavy page speaking to a specific collection of sunglasses that they had.
Then we started to measure these manually at first at least. We went to WebPageTest and started plugging them in one by one. We got the results and these are still DrupalCon's results. We got the results and we put them in this hard to see or understand or digest chart and started looking at those results to boil those down into an easier graph here. We're looking at speed index. I've taken it from the five pages to three so we're looking at our homepage, PLP, and PDP. The blue bar is where we're at right now. Before the rebuild, launch, and everything, that's what their site was already at.
Then the green is the average of their direct competition. You can see they're actually already better than their direct competition. If they hadn't looked at the next one, the yellow, the indirect competition, they would have been totally satisfied and not really taken much effort to improve where they were currently at. You can see by the indirect competition, there's still a ton of room for improvement. Again, speed index, the line going across is the average. It's at about 4400. On a slower connection, all of these pages are taking about 4.5 seconds before they're fully visible on the viewport.
Time to first byte, similar situations, sometimes we're already faster than the competition, sometimes we're not. In general, yellow is fairly low. We're averaging between three and 4/10 of a second just to get that first byte back. Start render, we're hovering closer to two seconds. Again, the specific numbers here aren't super important because you'll start to understand what numbers make sense for you. Just the general patterns you're seeing among these. Start render about two. We know we've got room for improvement. Then same goes for load time which again on a slower connection is upwards of nine seconds.
You can see the PDP was taking maybe 11 seconds to load on a slower connection on their current site. Then fully loaded so the JavaScript was doing its thing. It might be 15 seconds or more before all that's out of the way and the user can just do whatever they need to do without being obstructed. We've got numbers now. We understand what are good numbers, where do we want to be. Now it's just a process to pin it down to very specific goals. How fast is fast enough? You can keep tweaking performance forever but when are we at least going to be happy with our efforts and be proud of what we're launching and feel like the client is going to have success with this improvement.
The general rule of thumb that a lot of people like to say is to beat the competition by 20%. Again, we might have already been beating our current competition by 20% or the direct competition. While I keep that in mind, I would just like to say look at the numbers you've got and just be ambitious. It's not going to be the end of the world if you don't hit every single goal so you might as well shoot for the moon, whatever that saying is. We took all the numbers that we were seeing before, we ran some stats just to figure out what's the best speed index we were seeing on the homepage, what's the best time to first byte across all the sites. Then how can we create our goals from there?
More charts, same chart but we've added the orange and that's our goals. This time the line going across is actually the lowest value that we saw across all of the pages for this metric. Our minimum speed index here was about 1600 seconds and our goals were about 1500 milliseconds on the homepage and then 2250, I think, on the other pages. You can see here we're being ambitious. Our direct competition that we thought was killing it, we're saying, "We'd love to be even better than that then we'd really feel good about what we had going on."
Same thing goes for time to first byte. We said, "Okay, point two might be better than what most of these sites are rendering on average but that's where we'd like to be about one second for a start render instead of 2, 2.5 seconds. Again, better than most the other metrics we measured. then load time. we want the browser to think it's loaded within around three, four seconds. Then fully loaded, we want the JavaScript to be out of the users way within about five or six seconds. You can see this is pretty ambitious compared to the other results maybe a tiny bit too ambitious that came to bite us a little bit. Again, there's no harm in creating these ambitious goals in the first place.
We've got our goals, we know what we're measuring, and all of that. Now it's just a case of figuring out how are we doing with those goals? Of course, if you're intensely focusing on performance you're probably running tests all the time. What we like to do is run an official round of tests every week and then communicate those results with the rest of the team. Again, this was totally manual for quite a while.
We would just dump the numbers into yet another spreadsheet. The colors are very faint it looks like at least from up here. What we would do is highlight cells where we were actually slower than our current production site. We'd highlight those in red to say we can't launch with this. Yellow was better than what we already had but still not reaching our goals. Green was where we started to get our goals met. Green was actually we met our goal or exceeded it. You can see it starts off fairly red, a little yellow and as it goes more to the right, the red starts to go away, maybe more yellow, and then maybe more green.
What's really helpful about this especially as you're in the later phase of rebuilding a site or redesigning it and implementing all that stuff is when stakeholders come to you and they say, "Okay, we want a mobile window that pops up immediately when the user visits the page. We want to ask them to sign up for our newsletter. We want a big image carousel at the top of the page. Instead of one image, it's going to load five or six and there's going to be a video and it's going to autoplay and it's going to have a ton of JavaScript powering it," or, "We need every third party script under the sun for marketing, analytics, and user tracking and all that."
When these requests come through, they're all fair requests but what you can do is judge them by the impact that they're going to have on performance so you could say, "Are they worth that impact in revenue?" If you go as far as building that feature, and it adds two seconds to your speed index, that could mean 20% of your revenue. Is that feature worth it? Is it really gonna increase engagement as much as you think it is to overcome that? Not so sure. With that mindset, again, it's hard to see I know but this is the latter half. Before you were seeing this side. Again, less red, more green if not yellow.
It was those decisions that got us here. Both those kinds of decisions and also of course focusing on what specifically can we do to improve it which is the second part of this talk. Where did we end up by the time we launched? Again, same chart but this time we've added red and that is where we were at during lunch. You can see with our speed index, we set pretty ambitious goals but we exceeded them. Our site was loading in the viewport much faster than any of the competition that we measured and two, three, four times faster than the previous site was.
Time to first byte didn't necessarily hit all the goals but we hovered around 0.2, 0.3 seconds, which in the grand scheme of things, that's pretty good, that's totally fine for time to first byte. Start render, similar, we're hovering right around our goals. Right around one second. Instead of on that PLP, almost three seconds before a user even sees a pixel, now we're down to one second. Load time, we're starting to creep up there a little further from our goals, not super excited to see that, but still hanging in there with the indirect competition, and even more extreme with the fully loaded time which we will get into a bit. A bit of an improvement but not nearly as much as we would like.
Mission accomplished. At least, for the most part, many of our goals are met or we got really close. A drastic improvement regardless. We're ready to launch. How did we get there? That's the second part of the talk which I promise will go quite a bit faster than the first. I know it's nearing the end of the day here. When it comes to improving performance, I just want to start with a bit of a warning. This is yet another often cited quote in the world of computer programming or web development. That is premature optimization is the root of all evil. You can't necessarily just expect to write fast code as you're writing that code.
You can't micro optimize your four loops when there's so much more going on with the rendering. You can optimize them but that's not going to be what makes the difference. What you need to do, instead of just being like, "Oh, I'm going to build it and pay attention and hopefully get it fast as we build it," you need to dedicate pre- launch time that you can focus on improving performance. Maybe that's a sprint, maybe that's two sprints, maybe it's a couple of sprints before you launch you say, "Okay, these two weeks, this chunk of time, this is for performance."
Again, with a premature optimization thing. Your custom code is a very small piece of the performance pie. There's so much more going on that you got to look at the bigger picture. You've got to look at everything involved with the requests that the user is interacting with in their browser and that's what we're going to do. You've got to determine what each of those metrics we talked about is telling you. Why is it higher than our competition? Why is this specific metric the one that's higher than our competition? That probably means there's something up there.
To go through each one of those metrics starting with time to first byte. The reason I said point 0.2, 0.3 is actually good enough, fairly good at this point is because it's been thought that for quite a while, Google's already probably been punishing time to first bytes that are higher than 0.4 seconds. If I don't even get a bite back for about half a second, Google's not going like that and it's probably going ding you. Also, I think it was on a little about podcast with some Pantheon folks. They said, "Think of time to first byte as your race's starting line. When the user gets their first bite back, that's when the race to load the rest of the page begins."
Why would you let this number get out of hand, this time to first byte if it's only going to keep you at the starting line until that byte comes through? How can we lower it? How can we win that race? The first thing to look at and think about, of course, is my website cache and is that properly configured. There's a ton that goes into caching, there's a lot to think about, a lot of configuration. One thing to just point out and highlight is assuming that a lot of us are working with Drupal, Drupal caching can be enabled but it can be broken.
The caching for a specific page could be enabled but something on that page is actually breaking it and you're having to rerender it every time, or maybe the configuration isn't where you thought it was and a page it should be cached isn't or vice-versa. There's a lot to look at if your websites being cached and if that's configured. Do you need to upgrade or tune the server's hardware or software? These are things like disk space and RAM. Is there enough of that on the box that's serving your website? Have you gotten away from shared hosting, hopefully? Are using PHP 7 instead of PHP 5 which that alone is quite a bit of a performance improvement? Have you tuned MySQL? All things like that.
Am I using a CDN? should I be using a CDN? That's going to lower the round trip distance of that time to first byte. Every request is going to have to travel through less pipe, if you will if the internet was actually powered by pipes. There would be a shorter distance there if you're using a CDN and that would reduce the time to first byte. Should I have things like Varnish or Redis in front of my site in situations where the CDN gets bypassed or the cache has expired, things like that? Could I reduce the number of redirects? Time to first byte is after all of the redirects.
If a user for whatever reason a nodes alias has been updated four times and when they go to visit it, they redirect four times, each one of those adds that time to first byte so we want to reduce redirects by as many as possible. One hopefully less than one, that would be zero. Then our start render time. We're getting bytes back, how can we get the pixels painted on the page as fast as possible? Maybe they're not important pixels, but if there's something, our user is going to think, "Okay, this is loading. If I wait a little bit longer, more pixels are going to appear." There's a lot to this slide, I'm not going to go into all of it. Again, these slides will be available online, or you can always reach out.
There's a ton you can do in terms of requests. You can have less requests. You can maybe move render-blocking ones that are in the head that don't need to be there like certain JavaScript, you could put them in the bottom, that's been a common practice for so long. You could defer them instead. You could tell the browser to fetch them before it normally would to have them ready. You could get a service worker going if you were in the progressive web app game which is definitely something to look into. Again, a whole other presentation.
There's a ton that you can do to look at your request in that waterfall and think about how can you handle those better so that your content isn't blocked from rendering. CSS and JavaScript by default, the browser is not going paint anything until those are fully downloaded because they don't know if the CSS is going to impact that performance piece or that piece up top. We don't want flash of unstyled content. Having as little as possible as render-blocking is the way to go. Then load time.
How can we get a usable page as soon as possible? A big one here is enabling HTTP/2. It requires HTTPS. If you're able to pull it off and flip that switch, it significantly reduces the impact of individual requests. Because it doesn't require a whole other handshake and all the technical stuff that goes on with the typical requests, opens up a pipe and starts streaming those. Again, a whole other session but there's huge gains to be had there. That's definitely something to look into. It's the common stuff we might all be familiar with.
I shouldn't say we might all because I'm a front-end developer. As a front-end developer, you're always thinking, "Have I optimized my CSS and JavaScript? Is it aggregated? Is it minified? Is it properly compressed? Is it being cached? Same thing with images. Are those being compressed? Are they serving in the best formats they could? We now have formats like webP that are way faster and smaller file size for browsers like Chrome. Are they sized? Are we using image styles to deliver a small of an image as possible for our users? Are they properly cached? Should we be lazy loading the ones that are showing up under the fold? A ton we could do with images.
Images alone probably should be your starting point when you start rendering fully loaded and stuff like that. The same thing goes for fonts. Fonts warrant their own slide because we don't often think about it. Again, at least as a front-end developer, you don't, you say, "Oh I'm getting this font from Google. That's super helpful. I don't even have to put it in my project." Actually, a lot of those Google requests end up being super slow. Should we deliver those a different way? Can we have less characters in our font because we're not actually using all the characters? That would reduce the file size as would compressing it. Are those files even being cached however we're delivering them?
Then fully loaded time, last one. How can we get out of the user's way as soon as possible? Again, this is where we got burned on our site just because there were so many third-party scripts. I talked about modal windows and image carousels. We won that battle but we didn't win the third-party script battle, unfortunately, and it showed up in the results. This is something we showed to the client and we said, "You can have all the analytics and the tracking and everything, but this is what it's going to do the page." At least they're aware. When it comes down to fully loaded, that's typically the culprit you're going to want to look at, are my third party scripts under control?
When going through each metric one by one, I didn't necessarily go into speed index. That's because fixing the older metrics are largely going to fix your speed index. You don't really look at the speed index and think, "How am I going to get that down by 100 milliseconds?" It doesn't really give you much insight into that. What does give you the insight are the traditional metrics, you fix those and then that's when your speed index starts to come down. As the slide says, there's some techniques that can shave time specifically off speed index like inlining some critical CSS so it's not render blocking on the top of the page and lazy loading the images that are below so the ones above load much faster.
There are things you can do there but those are things that you think about when you're thinking about those other metrics as well. Mission accomplished. What did we learn? We learned that performance is super important. One second could cause 10% of users to drop off, and in most cases, that would be very detrimental to our business. We learned about audits, all the metrics that we like to measure, how we're going to measure those metrics.
Getting our benchmarks so we even know what numbers are good numbers, creating ambitious goals from those numbers, and then tracking results weekly so that we can follow the progress on the improvements we're attempting to make. Also so that those numbers can inform the decisions of where we want to focus our time on next. Again, with that time, we're dedicating pre-launch time to focusing on improving performance. We're figuring out what each metric is telling us. We're identifying ways to improve those specific metrics. Only you can improve performance. Go forth and conquer. Thank you for your time. Any questions?
[applause]
Speaker 2: Will you provide a link to your slideshow?
Gus: Yes, I'll upload the slides to the node on the DrupalCon website, and they should be available there. The question was, can I provide a link to the slides?
Speaker 3: Hey, Gus. Let's say I'm somebody who doesn't know how to deal with all this, I don't have a lot of budget. I'm running a Drupal site serving a lot of anonymous users. What's the first two things I should do to speed up performance? CDN, PHP 7? What are the quick hits that people in this audience that are in that boat might say, "Oh, I can go back to my team tomorrow and we can do these things."
Gus: Sure. First, I would recommend running WebPageTest because the things you listed PHP 7, CDN, those are all definitely going to help, but maybe that's not why your page is hanging. I would first recommend to look at WebPageTest, see what metric is so big and then do a little research on what you can do to improve that. Sure, for many things PHP 7 might be a huge win, but I think you always want to have those metrics to inform that. I know that can be difficult when you're not super tech-savvy, but finding the happy medium there is what I'd recommend.
Speaker 4: The first two tools that you showed looked really interesting.
Gus: Yes.
Speaker 4: We run a B2B site that's nearly 100% behind the login, which is a custom SSL integration. What options do you have for those free hosted tools to get in?
Gus: That's tough, I don't know. We had a situation where it was behind HT password authentication, htaccess that you can plug into WebPageTest. I don't know if the free web browser base, you could give some fake credentials and get it to log in. I think what you might have to start doing is running your own private instance of WebPageTest, and there's an API along that.
Even Lighthouse, a ton of CLI options. I don't know specifically because I haven't had to do that, but I would not be surprised if there's a way to say, "Okay, here's where the test has to log in. Here's some dummy credentials that will get them logged in." Then from there, we want them to go to a certain page and measure it. Lighthouse you can because it's in your dev tools. Again, that's inconsistent so you want those.
Speaker 5: The code [unintelligible 00:43:46] available to run?
Gus: Yes. WebPageTest you can do your own private instance. You can host your own copy and then Lighthouse you can just clone on GitHub and it's fairly straightforward to use. Not straightforward, but it's easy to go from there.
Speaker 6: Do you have any recommendations or insights into cache warming, and specifically for sites that don't get hit a lot? If somebody's always a first time user, they're always getting the uncached version. Even if the cached version loads really fast, if uncached version is the de facto user experience, how do you solve that?
Gus: Yes, definitely. I will say on the project I was giving the example of I don't think we thought enough about cache warming. It's something I've experienced in the past. I think there are Drupal modules that attempt to do it, but it's been a while since I've looked. You answered it to the extent of my knowledge. I'd say, yes, look into cache warming, but unfortunately, I don't have specific recommendations for that.
Speaker 7: You plugged one presentation that's tomorrow. I was also going to plug another one on Thursday. That's how to get a 100 out of 100 on PHP test.
Gus: Is that yours?
Speaker 7: That's mine, yes.
Gus: Okay, cool.
[laughter]
Speaker 7: If you want to know exactly how to accomplish what he's talking about, I go through it in detail. I have a demo that takes about two minutes. It goes from a 54 up to a 99.
Gus: Yes, and that's Google's tool and they're the ones that are going to start dinging.
Speaker 7: Exactly. Thank you.
Gus: Awesome. Appreciate it. Yes?
Speaker 8: You showed your weekly page audits and you said you did that manually for a long time, and you're doing something different now. I'm in central IT for our university and we turn sites over to content authors who then upload a gig of testing the carousel in the performance test.
Gus: Been there, yes.
Speaker 8: Do you know of a tool that I could use to passively monitor?
Gus: There's SpeedCurve. The last one I think would be useful if you're willing to fork over a little bit of cash. Otherwise, WebPageTest or Lighthouse, you'd probably have to spin up a server and get those on there. I don't know the structure of your team and all of that. You'd have to do that if you're trying to go the free route. You could use a WebPageTest API or Lighthouse to just generate numbers. Then the tracking and what you do with those is up to you. That's why SpeedCurve is so helpful is just because it does the tracking, it gives you the number. I think it's $20 a month, you can do quite a bit with SpeedCurve. That's where I'd suggest looking first.
Speaker 8: Thanks.
Gus: Yes.
Speaker 9: Thanks for the excellent session.
Gus: Thank you.
Speaker 9: There are two ways of looking at page speed. One is the traditional way where you analyze the waterfall of the resources, and the second is the visual metrics where you actually render it in a virtual browser and see the diff, right?
Gus: Yes.
Speaker 9: Now applications with a lot of react and angular coming up, the JS is getting monstrous on the front end. All the third party JS, they are recommended to be loaded in asynchronous way so they do not affect the rendering for the end-user. What do you prefer? What is your personal choice on going forward? Do you prefer the visual metrics or do you go for the traditional metrics?
Gus: I prefer both because you could go for the visual metrics but those scripts that are loading in the background, while they're not affecting the visual page, they're going to slow down your experience. You're trying to scroll, and there's 1000 things that are trying to track what you're doing and executing or loading themselves. That's why I like the traditional metrics fully loaded especially for those kinds of things. Then speed index I still consider super important because, again, aside from janky scrolling or whatever is happening from the traditional metrics, the speed index reflects when a user actually thinks their pages is loaded. I like both.
Speaker 10: Is there anything that changes when you're working with a single page application? The tools that you recommend, the measures that you recommend?
Gus: I don't have experience with that. I would assume in many cases, a single page app you're still going to have URLs that are changing, I don't know, in which case you could still hit them. If not, I think it'd be a little trickier. That might be when you start to really get into using Lighthouse again, pulling that down. It's powerful. It's JavaScript-based so you could probably have it do things like execute certain interactions, or at least use something else to execute certain interactions, get you at a certain point and measure the performance and that kind of stuff with Lighthouse.
Speaker 10: Thank you.
Speaker 11: For the WebPageTesting page speed especially when you're working with a client on a project, do you run multiple tests in each one because we've noticed occasionally we'll run two or three in a row and the numbers will be wildly different?
Gus: Yes. That's tougher to the point that it was made earlier when the cache isn't getting warmed. Your first test, especially as you're developing a site, and it's not like you're having a ton of users hit that site, your first results could probably be cache, or not cached, and then you're going to get way higher numbers. Which again you should worry about that too, of course, but you want to think, "In an ideal world when we got the warming and this and that, what are our metrics?"
I found that the closer you get to launch and the more people are actually using it, the more they stabilize. The fact that WebPageTest runs three tests and averages them as well, I think, if you were continuing to get a lot of erratic results, I would start to be curious, and maybe that's not necessarily WebPageTest fault. That's something you got to dig into and start to figure out which metrics are showing wildly different results. Why? Maybe in a certain situation, some function is getting hung. You know what I mean? Really start to dig in there.
Speaker 11: Thanks.
Speaker 12: If using a CDN is not an option, do you have any suggestions on other low-hanging fruit methods to improve image performance?
Gus: Yes, image performance is a big can of worms. Responsive image tags, for example, we're all building responsive websites, most of us are serving the same markup to any device regardless of what it is. If you’re not careful, you could be sending your huge image to every single device. Responsive image tags that use image styles in Drupal, if you're working with Drupal, then the mobile users get that version. That's huge, that's your biggest one. Then server-side compression, Drupal again, I don't know if you're using Drupal or not, but you can tweak the number like, "Oh, I want this 80% compressed or every image to be that compressed."
I think I cheat sheet one sec. Oh, I had to go much farther back than I expected. Sorry. Formats are tricky, I mentioned WebP, but it's pretty tough when you don't have a powerful CDN to switch those formats out for you based on the browser. Then lazy loading also a huge one, I don't know if you're familiar. You're going to implement some JavaScript that's going to only load images as you need to see them. It's running through all that stuff. The compression, it's going to help you on those time to first bytes with those images and then the lazy loading is just going to help the overall page.
Speaker 12: Is there a compression percentage that you recommend?
Gus: It's tough. You have to test, I feel like 70 to 80% is where a lot of people land to have significantly compressed images but not to where they start to look terrible. If you start going to 60 or lower, then it gets pretty messy.
Speaker 12: Thank you.
Speaker 7: I was going to help you here.
Gus: Go for it.
Speaker 7: There’s a module called ImageOptim. It’ll give you a image style that can then compress lossless compression. That will take care of basically zero quality loss, but it'll still shrink the image size down. Then also if you don't have a CDN, HTTP/2 really helps with that anytime. Absolutely huge.
Gus: Yes, if you can flip that switch.
Speaker 7: Yes.
Gus: That's not limited to images. If you can get HTTP/2 on, it's huge. That would be my biggest. If you can't do anything else but you can flip that, that's the way to go. You have to have HTTPS but soon enough Google wants everyone to have HTTPS, so I would hop on that train. Cool. Thanks again. Appreciate it.
[applause]
[00:52:57] [END OF AUDIO]
