Performance and profiling Umbraco

Hello everyone, everybody good? Everybody ready to go take a nap after lunch? You've already gone through one session. We're going to go ahead and get started. I'm a minute early, but there's a lot of stuff that I want to talk about today. There's a lot of stuff that I want us to take a look at. Because at the end, we're going to do kind of an interactive deal where we're going to identify performance problems and show you how to diagnose those and how to go about fixing those. So let's get started. My name is Matt Schull. I'm the director of Aristotle Labs. And we build products and services for freelancers, individuals, companies that drive user engagement, that increase user engagement. So it looks like a couple of different forms. We have kind of this performance monitoring and consulting service where we help companies identify performance problems on their website. But we also work in the internet. A little ambiguous Internet of Things that no one knows what to do. We're actually putting some practical feet under it and doing some really cool stuff there as well that I'd be glad to talk about if you want to later. But today, what we're going to take a look at is performance and how to make things faster. And particularly on the front end side, the browser rendering side. Because around 80% of the load time is on the browser front end side. Not necessarily on the back end side. So if you have any questions or anything, or if we aren't able to talk here or after the talk or after this week, you can definitely reach me at any of these things. We love to kind of share what we've learned and to learn from others and just kind of all learn together. So if you want, you can follow along at aristotellabs.com.cg16. I've got these slides, all the references and resources. And everything to do. And once the video is available, I'm going to try to put it on this page as well. So if you ever need to go back and look at it, that URL is where you need to go. So kind of how I got here. Our company, Aristotle, we have a sister company called Aristotle Interactive. And they do a bunch of web development for tourism clients. So sanjose.org, Gulf Shores, the state of Arkansas. We do a lot of different tourism websites. And we kind of got in a situation where we were with this other CMS and things weren't working out and we had to let them go. And it was an easy breakup for us. So we were looking for another CMS. And our lead programmer, Andrew, who's here, was supposed to go to US Fest 2015. Something happened. He wasn't able to go. And so they sent me. I'm a PHP developer. I know nothing about .NET at all. Which probably gives you confidence for this talk. But I'm a front-end developer, PHP developer. And I was a project manager there at Aristotle at the time. And they were like, send Matt. And so I came here skeptical. I came to US Fest 2015 pretty skeptical and not really expecting much. But I was very surprised. I love the community aspect of Umbraco and everything about it. I went back and I was like, it doesn't matter what size website. We need to use Umbraco for everything. And so slowly but surely, we've been moving our websites to Umbraco. And it's really the first CMS. I mean, I've been doing web development for several years. It's the first CMS that the client and the developers both enjoy using. And that's very rare. And I've not seen that in any other CMS. And so we absolutely love the CMS Umbraco. Because it kind of gets out of the way. It lets you develop. It lets you do the code. So just so I can get kind of a sense for who everybody is and where everybody's at in the room, I've got a few questions. How many of you are just performance gurus? And you would do anything to shave off 10 milliseconds off the load time of your website? How many of you? That's you today. OK. Got a few people in there. Good. Good. How many of you are like, I don't care about my site speed? Try to convince me if you want. But I'm not going to learn anything about site speed. I don't really care to. Anybody like that? It's kind of an exaggerated question, I know. But how many of you just don't understand why performance is important? How many of you think, why should I even care about performance? Is there anybody like that in here? No? Everybody cares about performance? Oh, that's great. This is going to be a good talk, y'all. So let's take a look. For those that maybe didn't raise their hand, let's take a look. Let's take a look at why performance actually matters. So first and foremost, there's Fred Wilson, who's a venture capitalist, said, first and foremost, we believe that speed is more than a feature. It's the most important feature. And that really resonated with me because speed and site speed and web performance, whatever you want to call it, is all about the user experience. We want to get the content to the user as fast as possible. So in the old days, we had things like this. We didn't have to care about performance very much because we had flaming GIFs and some HTML and we eventually had a little bit of CSS. And we were happy and everybody was fine and things loaded fast on our dial-up connections. It was okay. But over time, we've matured, right? And things have gotten a lot better. Absolutely. We've added in JavaScript. So now we can do all types of interactive features. We have all kinds of images and responsive images. But along the way, I think we kind of got a little too excited as developers. And I think we forgot to ask ourselves, well, does the user need to download all this JavaScript? Do they really need all this JavaScript? Do they really need all this CSS? And that's kind of the direction that I want to move us in. That's the direction that I want to move us towards today. So we've got to remember what Spider-Man's Uncle Ben said. With great power comes great responsibility. We are the people that are building the web. And so it's our responsibility to make sure that it's accessible to the users that are trying to visit these sites. And in order to do that, you need to understand how the browser is rendering your page. So let's take a look at some numbers and understand why performance is so important. 40% of users will abandon a request if it doesn't load within three seconds. That's it. You have three seconds to get the content to the user, or about 40% of them will abandon. And who knows? They may never return. So for people that have e-commerce sites. That are trying to make those sales. That should speak very heavy to you. Because 40% of users may be leaving your site. So it makes sense too. I mean, which one of these sites would you want to visit? Would you want to do the one on the left or the one on the right? Let's see if we can get this to play. Nope. Let's do this. Come on. Just thinking about it. So here we go. Which one of these would you want to load? The one on the left or the one on the right? The one on the right, right? The one that loaded fast and got the content to you faster. And it's important for that user experience. But it's also equally as important for business metrics. So Walmart saw a 2% increase in conversions for every one second of load time. That was taken off. And for Walmart, that can mean a lot of money. Also GQ, which is a magazine, saw an 80% decrease in load time. Resulted in an 80% increase in traffic. And a 32% increase in median time spent on site. That's also very huge. But I think the biggest one is that train line. Because they decreased their traffic. Their latency by 0.3 seconds. Customers spent an extra 8 million pounds a year. Do you care about performance yet? Have I got your attention? That's a lot of money, right? So performance has a profound impact. And there's a site on that, aristotellabs.com slash cg16. There's a site called wpostats.com that will give you other stats like this to convince your boss or whoever you need to that site speed is important. So in order to actually care about performance, we have to understand what performance is. And so there's a lot of things out there. In the older days, we used total load time. And total load time tells us when all the assets and all the resources have downloaded and are now on the page. But that doesn't actually tell us anything, right? That doesn't tell us anything about the user experience. Like how fast does the user think the website is loading? Is there any problem with the server site rendering? So total load time, while it may be good to track just to have it for reference because a lot of people tend to say, well, what's the total load time? That's actually not a metric that we take a lot of stock in because it doesn't tell us anything about the user experience. So the three metrics that we kind of base things on, and these are kind of across all industries, across everything else, these are the three metrics that can really tell you about the user experience. The first is time to first byte, which is how long it takes that first byte of data to get to the user's device after they've made a request. And you can actually visually, if you go to a website, you can actually visually tell how long that takes because if you've ever been at a search results page and you click on a link and then you just kind of sit there for a little bit and you continue to sit there and finally it goes to this blank white screen, before things get on, that blank white screen is actually when the first byte of data gets back to your device. So you can actually kind of visually see what that looks like for your website. So time to first byte, it's going to talk to us about the rendering of server-side code. So if there are slow API calls or if there's slow SQL or any server rendering code, that could cause a long time to first byte. Also any connections to the server, memory leaks, poor service, poor server resources or anything else could also cause a long time to first byte. Oh, and I forgot to mention, I'm going through a lot of these things very fast at the beginning because I want to get to the end with the diagnosing and everything. So feel free to go to that link and take a look if you think I'm going a little too fast and I'd love to talk afterwards. Alright, hopping back in, speed index is the second thing. This is my favorite metric of all because it's also called perceived performance. How fast does the user actually think the website is loading? There's a lot of psychology that goes into this and I'm a psychology major. I actually failed computer science, but that's a whole other story we'll get into. A PHP guy failed computer science, it's just a long history. But speed index is something that we can actually measure through image recognition software and it tells us how fast the user thinks the site, the page is loading. And then page size, and this is probably one of the more important ones that people need to pay attention to today, especially on mobile networks. Mobile networks aren't as fast as being plugged into the wall. So that image, that big beautiful image that you're trying to push through that mobile network may take forever to load. We can kind of look at it and see how to measure these things later on. So as we go through these different techniques, that we're about to look at, and as we start diagnosing things later, I'm actually going to talk about how time to first byte, speed index, and page size are affected with each technique and with each diagnostic. So where do we start? Well, the first place that I always like to start is images because images make up about 63% of the page size online today. And the average page size right now is about 25 pages. So that is about 2400 kilobytes, which is actually larger than the number one selling Kindle book on Amazon. So I thought that was interesting. But you can definitely check that out. So images, they make up a bunch because of the different types of images that we want to show. We want to give a great experience and have this really cool design, but it comes at a cost. So there's a couple of different things. There's a couple of things that I want to look at in terms of image file types. First of all, there's a lot of image file types. So you've got JPEG, SVG, all those other standard ping and everything else. But we're not going to look at those today. We're going to look at two file types that you may not know about. The first is WebP. How many of you have actually used WebP in production or anything else? One person? Just one person? Two? Two people? Three? Three people. Yeah, so it's not very common to see a WebP image. But Facebook attempted to use this, but users got really mad when they tried to save the image and it wouldn't pull open their computer, so they stopped. But eBay still uses this to show its products on the homepage. So with WebP, it uses transparency, animation, and photographs. It's about 50 to 75 times smaller than the JPEG equivalent, and it's more for photographs. You can see, I think you can see that. Yeah. So there's a ping on the left with 100% quality, a WebP with 80%, and the ping is 897 kilobytes and the WebP is 27 kilobytes. This is a big extreme, but this is actually something that we used in a website once. So the only downfall is browser support, of course. That's the downfall of any great feature on the web. So right now, Android and Chrome are the only browsers that will render a WebP image, but there is the same thing. There's a slight possibility that Firefox may be bringing it at some point. The other file type is JPEG 2000. How many of you all have used JPEG 2000 in production? Yeah, so a few more than WebP. JPEG 2000 uses transparency. It's used for photographs. Sometimes it's smaller. Our designers have to kind of give a comparison, look side by side at the quality and the file size, but for the most part, we're seeing that it is a smaller file size. The great thing is that it's only on Safari. The reason that's a great thing is because if you take WebP and you take JPEG 2000, you now have smaller images for most of your mobile users who are on Android and on iOS Safari. So this can be a great way of optimizing your images, but like I said, make sure that your users aren't dependent on downloading those images because they won't be able to actually see them in their Windows browsers or file browsers later. So responsive images is also another great technique. How many of you all use the picture element or source set? Yeah, so a good number of people. So this is a great way. If you don't know about this, you can look up the picture element and see all the specs on it. But on here, we can actually use WebP in the picture element. We just do the type equals image WebP, and you can also do JPEG 2000, and it will work just fine. Sometimes there are still a few browsers that don't support picture, so you have to have picture fill, which is the polyfill for it. But all those links are in that talk link that I showed at the beginning, and you can check those out. We can also use WebP and JPEG 2000 as CSS backgrounds using Modernizr. You can take a look at Modernizr.com. This is what that example may look like. This is what it will look like for that CSS code. And that leads us into CSS. Now CSS only makes up about 3.5% of the page size, so it doesn't take up a lot, but there are some things that you can do to optimize the rendering path for the browser. And one great thing you can do is minify your files, which sometimes sounds like a no-brainer, but a lot of times, developers, we just kind of get in a hurry. We forget to do things. So definitely minify your files. We tend to split CSS files into three files. We have two main page files, the above the fold and below the fold, and then we have an interior CSS file as well. Also, we load the above the fold CSS, just like you would in the head element, but we actually load the below the fold CSS asynchronously using load CSS. And I've got a link and other things at aristotellabs.com. Where you can learn more about load CSS and how to asynchronously load some CSS. The great part about loading that above the fold CSS first is because CSS is blocking, so it will download the CSS file and it will stop rendering that HTML while it downloads and executes that CSS. So if you minimize how much CSS you had, overhead you had, then you can get the content to the user faster. We actually have, on that link at aristotellabs.com, we have something that one of our developers cooked up one day, where you can do all of your CSS, feed that CSS file into this tool for Umbraco, and it will actually split out your above the fold and below the fold. So you can check that out at that aristotellabs.com link. Fonts make up about 5.5% of the page size. And there are a number of things that you can do to optimize fonts. One is don't use them. That's always a good option. But none of the designers at work like that option. But we do try to use browser fonts as much as we can. Then you can strip out characters that aren't needed using Font Squirrel, which is a tool online. You can also use browser font loading events, which are starting to come in. We won't really talk about them today. But you can load them asynchronously so that you show the text, and then as it finishes downloading the font, it will actually show that text in the different font. And then you've got Flash of Invisible Text versus Flash of Unstyled Text. Which is totally dependent on you and your company and which way you want to go. Some people would rather it not show the content until that font is loaded and activates. But some people would rather get the content to them and then change the font later. And there's different techniques you can use to make that Flash of Unstyled Text a lot easier for the user so it doesn't jump on them. Then we have JavaScript, which is probably the main killer of web performance today. But we love JavaScript. JavaScript is great. It makes up about 16% of the total page size. And with all the great user experiences, we are kind of relying more and more on JavaScript. And this can be good and bad. But there are things you can do to optimize the rendering path for your JavaScript. First is, again, minify the files. Use HTML and CSS alternatives. There's a number of things you can do in CSS now with the different selectors that we have where you can actually do logic-based things. We recently created a website where instead of using JavaScript for the mobile navigation, it was actually an input box that was hidden and it used a label element in order to trigger the mobile slide-out of the navigation. And so definitely, I've got on that AristotleLabs .com link, I've got a lot of different resources you can check out of different alternatives for JavaScript. And then we split our JavaScript into main page and interior page JavaScript. And then we defer those JavaScripts. So how many of you all know about async and defer for the JavaScript labels? Yeah, so most. Good. So in case you don't know, the first is just a normal script. So what happens is that it starts parsing that HTML, it gets to a script tag, and it will stop parsing the HTML. And it will stop parsing the HTML until the JavaScript is downloaded and executed. With async, you can continue to render that HTML while the JavaScript is downloading, but it will stop to execute that JavaScript, which is what you typically see with your Google Analytics code. And then you've got defer, which I prefer, which is it will download the script, and then once the HTML finishes, it finishes rendering, then it will actually execute the JavaScript. And that's what we use for the majority of our JavaScript. Things like polyfills like picture fill to support the picture element, we'll put as asynchronous. And then, of course, Google Analytics is asynchronous. And we typically do jQuery as asynchronous as well. So some things that we've kind of learned about JavaScript in Braco. First is that the JavaScript libraries, again, like jQuery or maybe Angular or anything like that, we typically do asynchronously. It took a long time to convince developers that it was okay to do that. Most people thought it had to be synchronous. On Braco Forms, we noticed that we weren't able to defer that at all. And there may be somebody that's able to teach us how to do that. That would be amazing. But we put it at the very bottom. We were able to find some code that allows us to take the JavaScript for Braco Forms, move it to the bottom of the page so that it renders HTML as much as possible. And then we use Ajax for everything, especially on time to first byte. If you see a long time to first byte, it may be that you could Ajax some data on the page instead of doing it on a server-side rendering. You could actually use JavaScript to Ajax that data in later. But we'll talk about that in a little bit. Browser hints. We won't talk about all these, but there's two of them that are in most browsers, but aren't in all browsers. The first is prefetch, which is going to let you cache specific files. And you can put this link element in the head, and it will go ahead and grab a file and put it in cache so that when it visits another page that requests that file, it's already in the cache, it loads a bit quicker. We do this for some of our CSS, in the below-the-fold CSS. We've started experimenting with it a little bit, and everything's looking really promising. There are a few bugs in it, but for the most part, it's a nice feature. And then prerender is something that Google did with Google Instant Pages, but really all they were doing was prerendering the page. So what they would do is put this on the search results page for that first search result, and it looked like it loaded immediately. It didn't matter what type of page or how much the page size was, but what was really going on was that it was loading the entire page even on the search result page. So if the user didn't need that page, they just downloaded all of that for nothing, which isn't good. Because again, even on mobile networks, that can cause a real issue if someone's on a limited data plan. So Google nixed. It's just Instant View pretty quickly. But if you know for sure that a user is going to be going from this page to the next page, you could prerender that next page for them so that it does appear to load very, very quickly. So now we're getting into measuring performance, which is the fun part. Yeah? Yeah? Can you use JavaScript for that? Yes, you can use it for that. We usually typically would do it for the interior JavaScript, not the main page and not jQuery. But you can if you know that you're going to need some resources on the next page. And again, if you know that they are going to go to that page, it makes more sense to do it in that situation. So a lot of times, a lot of our tourism websites will have kind of a very large image, subhead image at the top. And so we know that 80% of the users go to this one particular page. We'll go ahead and prefetch that image so that it's already in there and it doesn't have to download next time. So yeah, absolutely. Any resource that you want, you can put it into prefetch. Yeah. All right, so let's talk about measuring performance. There's two types of ways to measure performance. RUM, which is real user data, and it's using some JavaScript APIs to actually capture the performance data for the user. when they come to your site. We're doing a lot of experimenting with this right now. And originally, I was going to try to fit this in, but unfortunately, for time's sake, I'm not going to be able to talk too much about it, but would love to talk about it later if you want. So the one we are going to talk about today is synthetic. And this is kind of like you're in a lab. It works well for diagnostics. So here, we can simulate a user from this particular location, on this particular connection speed, on this particular browser, and what does the performance look like in that particular setting. And quick note, a lot of people may use averages in their performance testing, but we found that it's been better to use median because it takes away the outliers. So if you have a lot of different tests, and for some reason you have one that's very, very long in the load time, then it may be that it skews that average number. So if you were to use median instead, it'll give you a more accurate of what the 50th percentile of users experience whenever they visit that page. And using median, you can go to what is the 95th percentile experience and what does that look like, and try to optimize for that. And for more information, you can go to the aristotellabs.com page, and I've got some articles that talk about why median might be better than average. I say might be because you never know. It may be that average is better. We're all learning from each other here. So on synthetic testing, we're going to look at two different tools. The first is webpagetest.org. How many of you all know about webpagetest.org? Oh, great. A few people. Good. And then we're going to use Swift Sage. How many of you all know about Swift Sage? Yeah, nobody, because we just launched it. But let's take a look at webpagetest.org. I'm going to go switch over. All right, so this is the website, webpagetest.org. It's a free tool that you can use, and it works great for diagnosing problems that you may be having. So we're going to look at some of the features that it has here. The first is a URL bar where you would just put whatever URL you want to test. In test locations, there are locations all over the world that you can test with. And so you can just choose which one of these that you want to test with. Certain locations have certain browsers with them. This one particular location in Virginia, U.S., has IE 8 through 11, Chrome, Canary, Firefox, it even has some mobile browsers. So the Nexus, iPhone 5S, iPhone 6, and the iPad Mini. And it actually does use those on the mobile devices. It actually uses Android and iOS devices to make these tests. So we're going to choose Chrome. And then here in test settings, you can choose the connection speed. So we can test from a 3G speed if we needed to. We like testing from a 3G speed instead of a 4G speed because most people are still on 3G speeds, which when you live in a city like we do in Little Rock, Arkansas, it's kind of hard to believe 4G is everywhere. But we did some digging around and some research, and 3G is the most prevalent still. Then you can tell it how many times you want to run the test. So we typically do between 5 to 9. You can do up to 9 per test. And this, again, gives you a median, so you can run several tests and then see what the median performance of the page is. First view and repeat view, that will show you what your first view looks like and then what a cache view, performance for a cache view. And then you can capture video, which I always check. You can keep the test private, and you can give it a label as well. There are a number of different features. There are a number of different tabs. There's one for scripting, where you can actually make it go to a page, log in as a test user, then go to another page and test the performance of that logged in page. There's a lot of things that we won't be able to cover today about web page tests, but I've got a lot of resources and links at that aristotellabs.com resource. So feel free to check that out. I think one of the biggest things that I would say I would want everyone to check out is SPOF, where you can, how many of you use CDNs to do jQuery or load in your fonts? So a lot of us do. And what you can do is actually tell it what host, what domain you want to block. So what you should do is go in, block your font domain, or block your jQuery CDN domain. It adds about 30 seconds or 40 seconds to your load time because it can't get that one file. And that'll really scare people. It's funny. So we won't look into all that today, but definitely if you want to look at it later, we can. But I'm going to pull up a test here. And this is for a site, an Umbraco site that we did for fortsmith.org. And I'm also going to run some tests while we wait. I'm going to do one for cnn.com, which I know has horrible performance. I can always count on it to be a good test case. And then while that's running, I also wanted to get a volunteer from the audience to let us test your website. Who's going to be brave enough to do that? Anybody? Any takers? All right. www.nufss. Half ss? Nufss. N-u-i-n-s. So we should... All right. We're good? All right. So we're going to let this run while we're looking at the others and see what it looks like. So I'll go ahead and start that. So let's look at this for fortsmith.org. This is a beautiful Umbraco site. Umbraco site that we launched about a couple of months ago. So on webpitchtest.org, you'll see that there's some letter grades up here. You see some D and Fs. Again, a great way to scare people. If you ever want to be like, hey, we need to focus on this. You've got Fs. People are like, well, I don't want Fs. It's that grade school mentality of I've got to make all As. So the first one is time to first byte. And there's an equation that goes into this depending on the round trip time. And it takes into account SSL as well. So if there needs to be anything loaded for that, it will add time for that. And we can actually click on this and see that the target is actually 400 milliseconds. And we're sitting at 261 milliseconds. So we're doing good. Then we have keep alive enabled. This is where you have persistent connections enabled. On the different domains. Compressed transfer is something where you enable Gzip. A number of these, we don't have it on FortSmith.org. Majority of our websites, we do have it. And so this is something that compresses the transfer over the wire and then gets uncompressed whenever it comes to the browser. Then on compressed images, usually this will, if it fails, it'll tell you there's a potential savings of this much. And you can go back to your designer and they can tell you you're crazy, that we can't compress it anymore, that you'll start seeing artifacts, and then you'll go into that whole long discussion. But it's also, it's just a great resource to have to see if your images can be compressed anymore. Then cache static content. That's where you have caching enabled on each individual file type. And you can do that through the config as well. Effective use of CDN isn't really a grade, but it kind of tells you what could be on a CDN. But typically a lot of times we don't have these particular ones on a CDN because for our clients that care about, a lot about their international traffic, we use CDNs all over the globe. Looking down here, we can see, again, what we care about is time to first byte, speed index, and then the number of kilobytes or the page size. So here we have first byte, which is again 261 milliseconds. Speed index, which is 2,242. That's in the number of milliseconds as well. So that's really 2.24 seconds is how fast the user perceives that page to load. And then the bytes in is the number of kilobytes. That it takes to download that page. And you can see we're about 400. So typically we want the time to first byte to be an A. So we're good there. We usually want to keep the perceived performance around two seconds, give or take about 0.5 seconds. So we're good there as well. The reason for that is, remember, if you go back to what we looked at earlier, 40% of users could abandon that website if it doesn't load in three seconds. So we definitely want to have them perceive it load faster than three seconds. But a number of websites, I think the average speed index or perceived performance right now is around seven seconds. So definitely something to check out. And then on page size, we usually like to stay around 1,500 kilobytes. That's kind of our goal that we've set for ourselves. But again, the average page out of the top 1,000 sites on the web is 2,400 kilobytes. So you can definitely set goals for yourself. Yeah? What's that? No, those are things, those are goals that we've set for ourselves. But I do have it on that aristotellabs.com link. You can look and see what we set for ourselves there. Also, there is a link here, what does my site cost? And you can actually see on a particular data plan how much the site costs to view or how much that page costs to view in different countries. Again, a really great tool if you're trying to convince somebody that performance is important. So you can take a look at that. Moving along here, we've got the waterfall, which we'll look at in a moment. And we've got just an image of what the website looked like at the time of testing. And then we have film. Then we have filmstrip view. Filmstrip view lets you see the actual performance and how the page loads. So right now we can see, okay, our CSS is loading first. We have everything that we want there. Then we have the image load in. Then we have this background that loads in. So right from this, I could see that this kind of tan background, maybe we want to get that to load a little bit sooner so the perceived performance drops. And then, of course, fonts as well always play a big part. So filmstrip view is very helpful in telling what the user experience for this page is. If we go back, we can also see, we can watch a video of how the site loaded. And we can actually do a video comparison as well. So a lot of times what we'll do is whenever we make some changes on the dev site, we will do a couple of tests and compare it to the dev site and the live site as a video comparison. And we'll look at how to do that in a moment. So if we look at the waterfall, we can see again for this particular test, remember the test ran five different times, so now we're into the specifics of this particular test. And it shows us all of our information again. But here we can actually dig in and see how each individual resource loaded. So the green that you see there is time to first byte for that particular resource. The blue is how long it took the content to download. So there's some resources on that aristotellabs.com link where you can look and I talk about how to, I dig into a lot of this. But just for instance, I can click on this particular resource and see that it took, it's 131 kilobytes, so it's one of the images. And if you click on object, you can actually see what image it is. But if this had like a 500 kilobyte page size or file size, then I would know, okay, this is something that we could probably optimize. And so this just kind of gives you a waterfall view of all your resources and how they downloaded. These green lines here, our start render and the first paint time. So you can see when the browser started painting pixels on the page for your user. And that's important for perceived performance. So definitely something you want to track. All right. And then let's take a look at the video comparison. So in the test history, once you've run a few tests, you can actually go in and select a couple of tests and compare them. And then you can create a video. And now you have a video comparison side by side. So one of the most powerful things that you can do to convince your boss is to take your website and take your competitor's website and do a video comparison. And they'll basically just tell you what do you need. Like fix it, make it better. So it's a very powerful tool to use video. Because once people actually see the difference, all of a sudden they start caring really quickly because you don't want to be slower than your competitor. So definitely use that to convince your boss. All right. So let's take a look at CNN now that we've kind of got it. So we see that everything looks good except that there are some images on CNN that could be compressed. So if I click on this, I can see what images. This one really failed. There's a 45 kilobyte savings right there. So I could go back to the designer and say, Hey, this particular image, is there anything we can do to compress it any further? So that's very helpful. And then cache static content. Again, that's browser caching. And so you can go back to the developer and say, Is there anything that we can do to set up caching for these particular file types? So here you can see the repeat view, which I didn't have on the last one. But this is a cache view. So cache, they're still downloading 1.1 megs to see this page. But for the first view, they're downloading 4.5 megs, which is quite a bit. Especially if someone's on a 500 megabyte data plan, they don't want to download that. So definitely be careful with that. And then we can see that the perceived performance speed index is around almost five seconds. And so I know that the perceived performance is definitely something that we should check. So automatically you can see that the waterfall chart is extremely long. And one of the things that you would want to check is the number of requests that are being made to load this page. Because if you can reduce the number of requests that are made, so if we've got 10 JavaScript files, but we could reduce that to two or three JavaScript files, then it's not having to make a request back to the server for that. And it's saving some time. So that's, again, that's another place where I would start to say, is there any way we could reduce the number of requests? Because it's very rare that you see a waterfall chart this long. So in here, if we go into the waterfall chart, can look for any long loading images. And there aren't really any long loading images. They're just tracking you a lot. And that's what it is. It's a lot of JavaScript that's being used to track what you're doing and load different ads and everything else. So, again, another problem that we have is with Google Maps. If we try to load in Google Maps, that can also be a problem with how Google Maps loads. And so you want to be careful with how you do that. Remember to put, if you can, most of your JavaScript at the bottom of the body element, at the very end, and try to defer that JavaScript so that it gets the HTML to the bottom of the body. And that way, it can load the HTML to the user as fast as they can. Then on, if we look here, we can look and see the film strip. And nothing actually starts loading until 2.7 seconds. And it's just this little red bar right now that's loading. And that's what they see for a couple of seconds, which doesn't really make sense. After the fonts load in at four seconds, do we start to see some content. And for a news site, that doesn't really make sense, right? Like, for a news site, you want to get the news to the user as fast as possible. So it may make more sense then to do the flash of unstyled text, where it shows them the text without that pretty font for just a few couple of seconds. And then it kicks in and shows it in that new font. That may be something that they're willing to do. But one thing they did do was asynchronously load these images. So you can see that it's taken quite a while for this image to load. But eventually it gets there. So it's kind of a sacrifice that they made, because maybe this image is really, really large, and they can't do anything about it. So they'll just asynchronously load it later, so that people at least get that text and can start reading the news. So that would be something that could be used to reduce the perceived performance, is have these images load a lot sooner. And we've run into this ourselves a couple of times, with those big hero images that everybody, all the tourism destinations, want these big, beautiful images at the top. And what we've done is not deferred the JavaScript to load that image, because that image is so important. So you can make that trade-off. within your team, and if you all decide to go that route. So then we've got FSS, which is our other site. And it's looking pretty good. We've got a 3 second perceived, 2.9 second perceived performance, which is great, and 1400 kilobytes around there for the page size. So that's actually really well. And in terms of how it loads, we can look at this, and there's a ton for a spite of an F, but it may have been a rare case. Sometimes also we notice that if our sites don't get a lot of hits within a certain amount of time, it may take a minute for it to kind of kick in, but then the cache kicks in. So here we can see that this is like the longest image that we have. It's only 123 kilobytes, which isn't bad at all. And so typically I'll just kind of disregard that long content download time if it may have just been kind of one of those rare cases where it took longer to load. But you can kind of see that these waterfall charts for each test are pretty consistent with each other, and that's what you want to make sure of. So let me go back in here. So we've only got a few minutes left. But what we want to do... Let me go back. If I can get it to work. There we go. All right, so it's great to diagnose things, but one of the things that WebPagetest doesn't offer is a way to monitor performance. And that's what we wanted. We wanted all of this information, and it's a lot of information, I know, but we wanted all this information to be monitored every hour. And so we created something that does just that, and we're actually launching it today, and it's called SwiftSage. And SwiftSage is a performance monitoring tool that actually works with WebPagetest and lets you monitor the performance. So your time to first byte, your speed index, your page size, all of that can be monitored every hour for any number of pages that you want. And you can go to this link and get a special pricing just for CodeGarden attendees, which we've set up. And we also have... If you go here and sign up, we actually are giving away our pro package where you can actually monitor the performance from a few different countries, multiple locations, and on mobile as well. So SwiftSage is something that we've really been looking forward to launching, and I'll quickly show it to you. So when you log in, you get a dashboard. You create projects, and you can kind of get a quick view. Again, here's our three metrics that we care about, and I can go in and quickly change the different pages to see... Am I on Wi-Fi? Yeah, I'm on Wi-Fi. Quickly change the different pages to see the different metrics for that. I guess my Wi-Fi is messing up right now or something. Everybody must be on at the same time. But these will change as you go throughout. Actually, I know what it is. It's kicked me off. There we go. So there you go. So now I can see different things. And you can see it's green, red, and yellow. Green means, hey, you met your goal. Red means, hey, you didn't meet your goal. You need to look at that. And you can actually set your goals for each of these. You can set your goals for each individual URL. And then once you click into the project, you can go for each individual page and test it from the East Coast and West Coast in the U.S., Australia and Ireland. And of course, we can look at it in different browsers as well and track that over time. One of the things that we've been working with different clients, and you may be thinking, oh, they didn't meet their goals. They're not doing very well. But if you look at it over time, and let's just look at three months for this particular page, you can see that we were actually a lot worse at one point. So with this particular client, they kept having trouble with this one particular page. You can see the time to first byte was up to about 2.4 seconds. And sometimes it would even reach up to five seconds. So we deployed some things, some fixes to help that. And it made a difference. You can see it made a difference in their perceived performance as well. So that's that speed index that we talk about. And if I want to send this to the client to say, hey, check it out. Everything's looking good. I can definitely do that here. And then we look at page size, but we don't just do page size, but we look at HTML size, CSS size, and how each of these things contribute. And the first paint, one of the things you could do with first paint is see how many resources are loading before that first paint time, try to optimize that, and it will tell you what resource it is, what the file size is, and at what point it started loading. And then with deployments, you can add deployments. So you can see here that on April 8th is when we fixed that JavaScript error and things started rendering better. Then I can edit the project. I can add a URL to my project. I can change the goals here and change the URL, even remove the URL if I need to. And so this has helped a lot of our clients. One of the biggest, just last week actually, we had a client, Kentucky, who they noticed that, or we noticed that their page size had jumped up by quite a bit. And we're like, oh man, what happened? We went in and we saw that there was a parentheses that was causing the image editor to not crop the image properly. So we went in and changed the code. So the Swift Sage tool has really helped us internally go from reactive to where things are in chaos and we don't know what's going on and the page isn't loading properly to proactive, where we can now tell clients, oh hey, you had a problem one day, but now we fixed it and you never even noticed it. And that's a valuable service to them. So we wanted to share that tool, so we turned it into a software as a service product. All right, I am unfortunately out of time, so I'm going to run through the rest of these slides very, very quickly. But there are a couple of things to keep in mind. I'm going to let this catch up for a second. So beware of performance false profits. Things like Google AMP, Facebook articles, and Apple News, they talk about how they make the performance much, much better. I have a blog post where I talk about how you can achieve the same great performance without using that. Because really, if you optimize your rendering correctly, you shouldn't have to use these tools to do that. So definitely check out that article on that aristotellabs.com link. But I think if there was one thing that I would want everybody to walk away with today, it's that everything should have value because everything has a cost. And this is what I have to teach our clients. It's that, okay, I know you want to add that new great feature, but we set a performance goal of this, and that's going to put you over your performance goal. So can we take something away from this page so that we can add this image? Or what can we do to make sure that you're still meeting your goal? And sometimes it even comes down to, do you really need this feature? Or is it just something you saw one day on another website and thought would be cool? But definitely keep that in mind. Everything has a cost, and so you should talk to your clients about having value. You should definitely create a performance culture. So it's kind of like, how do I go back and apply this to where I am? You can go start creating a performance culture, and it's got to come from the top down. Remember, we have a lot of cool tools now to convince our bosses. We've got videos, we can show them waterfall charts and everything else. Create a performance budget or a performance goal, and set like a specification. So internally, we have a specification that says, when a site launches, it's not going to be above 1500 kilobytes, and the speed index is going to be no more than 2 to 2.5 seconds. Then recognize developers and designers, that do great work. So performance budget, this is kind of what ours looks like. You can go back and look at the slides later to see how we do this. But we also have a monthly performance award, where we actually give an award. There's a Sonic the Hedgehog that gets passed around the office, and they've got a plaque that has their name on it, and what they did to do such great performance. So recognize that in the developers, the designers, even the project managers get performance. They get performance awards for selling great performance. And so that's definitely important in creating a culture of people that are aware of performance. And with tools like Swift Sage and with web page tests, you can, as you're developing, start testing your performance along the way. And now what we have at Aristotle is a performance specification document that talks about how JavaScript should be loaded, how images should be loaded, and what file types to use and everything. And I'll be glad to talk to you more about that later. What's next? JavaScript APIs for detecting connection speed. So based on connection speed, we could send certain things or not send certain things. That would be amazing. Detecting speed index and real user data. And how does performance impact conversions and user behavior, which is something that we're studying at Aristotle Labs right now. We're just scratching the surface. There's a lot of cool people that you can follow. And learn more about web performance and site speed and how to optimize. And definitely make sure if you have any questions or need to look at the slides or any of the things that I've talked about, you can go to aristotelabs.com slash cg16 and take a look at that. Thank you very much. Thanks for coming. So we're kind of over on time by seven minutes. Awesome. But if you want to come up and ask questions, we can talk out there or later this week. Or again, find me on Twitter and everything else, and we can talk about whatever you'd like. Thanks. Good work. Thank you. Hi. Hi. Yeah. Thank you. Yeah. I think a lot of these tools are . They are. Yep. All right. Thanks, everyone. Thanks, everyone.