 Thank you. Can everybody hear me? All right, so that takes care of my intro. I am an engineer at Google. I focus on developer relations, specifically on web developer relations, encouraging a healthy web ecosystem, making sure that people are making fast websites, but also accessible, secure, and discoverable. And in my prior role at YouTube, I was there for four years and I worked to help make YouTube fast. So I really like this new role that I'm in. I've been there for a year and a half in my new role. I really like this new role because now I'm encouraging the web to be just as fast as I try to do. We'll get into web page tests a little bit later, but I co-wrote that book with a few other power users. And we're going to see how web page tests, among other tools, can help us understand the performance of our websites and the web's home. So if we're going to be talking about web performance, first we need to address why it even matters. Why do we care if a website loads in five seconds as opposed to ten seconds? And the answer is really easy. It affects our user experiences. When users have a faster experience, they're happier and they convert more. Whatever you want users to do on your website, if it's to sign up, to read your project, to buy things, they're going to do more when you deliver a faster experience. This website, wtostats.com, is full of case studies of businesses improving performance and seeing positive results. Engagement going up, conversions, sign ups, ad revenue. These things are all correlated with web performance. WPO is standing for Web Performance Authorization. So for example, Pinterest improved performance by 40%, and they saw a 15% increase in their SEO traffic and conversion rate to sign up. WTO stats is full of case studies just like this of companies ab testing performance and measuring the results. And I highly encourage you, if you're going to do performance testing on your own websites and you see similar improvements, or even if you don't see an improvement, the performance goes up, but conversions go down. Post your results to this website. It's a weekly format. Anybody can submit their content. So bottom line is users like fast websites. SQL also made this tool where if you haven't improved performance yet, you can kind of get an estimation of what type of return you can see. This is called the revenue impact calculator. You plug in a few different variables about how your website performs in terms of how many users access the website, what your conversion value is, the dollar amount, and what your conversion rate is. And it will kind of guess, if it could, what your performance is. And I can tell you a little bit later about how it guesses your performance. And it will give you a dollar amount. If you were to improve performance by, let's say, half a second in this hypothetical example, example.com, you can see over $100,000 in conversion revenue. But it's not just a dollar amount. We can also see it in search. The Google Webmaster Center blog in January wrote that they're going to be rolling out a change of the speed update, where page T is going to become a ranking factor in search results for mobile. And if you read further down, they say it affects only the slowest websites. There will be a motion for the slowest websites as opposed to a promotion for fast websites. So this is a big deal. A website will appear, or may appear, lower in search results. If it's slower, all other things will be available. That's not a big enough incentive. If you remember AMP on the search, there's this carousel of news results. And before that was limited to only AMP pages, AMP being Google's accelerated mobile pages framework that ensures speedy delivery of web pages. And Malta Rubel, the tech lead of AMP, a few months ago said that they were looking into changing the requirements for this carousel to be not just AMP pages, but objectively fast pages. And you'll see that he mentions the Chrome user experience report as one of the tools that we can use to measure objective with fast websites. And I'll get into that below the video. Okay, so these are all things that happen when the website is fast, but what happens when the website is slow? 60% of mobile connections worldwide are 2G speed. That's really important. 60% are 2G. And do you remember what 2G was like on your quote? No, not even. So it doesn't help the case that the median web page is about 1.3 megabytes on mobile. So over 2G, which is... I don't have that speaker in front of me, but I think that's 70 megabits per second. So if you do the math, 1.3 megabytes at 2G speeds would load in over two minutes. This is the median web page. So half of them are slower than that. 53% of users abandon sites that take longer than three seconds to load. We also have data about how fast or slow web pages load. And on mobile, it's 3.1 seconds up. So 51% of mobile page load experiences are greater than three seconds. And if half of the users abandon a website that loads slower than three seconds, and half of the experiences are slower than that, I think a quarter of our users are abandoning websites on mobile. So this is a big deal. They're not reading your content or clicking your conversion button or seeing your ads. So this is a big deal. And when we look at web performance, this golden rule by... hired by Steve Satter, he's kind of the godfather of web performance measurement. Steve says 80% of the response time is on the front end, as opposed to time spent waiting for the backend to serve the web page. So when we're looking for areas to improve web performance, front end is usually where we're going to be spending our time. Okay, so hopefully you all care about web performance now. Now how do we measure it? To help answer that, I have this grid of tools. On the left side, we have what we call lab tools. Or synthetic, as it's also known. On the right side, the right column, field tools. The field tools measure the user experience. The real users are getting measured. The top half are kind of personal tools. These measure our own websites or one website at a time. The bottom half, these are our tools as a community. These help us... These are almost like public utilities that tell us how the web as a whole is performed. When you combine lab, the field, and the personal and public, you get an interesting view. So lab or synthetic tools analyze how a web page is built. It'll tell us if a web page is built on WordPress. How many bytes does it load? Does it use a CDN? Are the images optimized? It can tell us everything about how optimizations should be done. Field data represents the real user experiences. Are the users on desktop, on mobile, Wi-Fi, 3G, or 2G offline? Was the web page load experience faster, slower? And which pages would be... What was the user journey like? Did they enter on one page and leave on another? Did they leave on that entry page? Did they interact with certain UI on the page? There are a few personal tools that can tell us about particular websites. If you've used Chrome and web development, you're familiar with Chrome developer tools. One page test is probably the premier web performance testing tool. Google Analytics was a new brand on that list. Public tools tell us about the state of the web as a whole. And I'll get into each of these later. So I want to make this... This is a workshop, so this is supposed to be very interactive. I hope I'm not talking for most of it. And we can all kind of collaborate. So instead of just telling you about web page tests, let's exit the slides and look at it. So I think it's a little bigger. Does anybody have a website that they would like to audit in web page tests? NetsRepublic. Can you spell that? N-E-T-S-Republic.com NetsRepublic.com So on this simple testing tab, easy slash easy.hp, it gives us the fewest amount of configuration options. So it's really, really simple to set up. The only things you need to decide about the connection would be slow 3G. So as they get there, it'll appear a little bit slower. It's important to click this lighthouse audit tab. This is going to give us these optimizations. I'll leave this on track for you. Let's start our tests. The capture of... So this is your website? NetsRepublic? My client's site. Do you actively optimize performance? Yes, right now I just go to Cloudflare. So you use Cloudflare. All right, so we'll see what we can identify for performance here. When I talk about web performance tools, there's two categories, and this speaks to the lab versus field. First, we want to know how fast is our website? And secondly, how do we make it faster? We'll see on web page tests, they'll give us performance timings. They'll say, your website loaded in 9.5 seconds. You may be tempted to look at that and say, wow, my website is really slow. It's 9.5 seconds. But that doesn't necessarily represent the user experience. This is just one test from one location over one connection type when really the user experience is a very diverse distribution of experiences. So resist the temptation to read too much into the results. So this is taking quite a while, so I'm curious if this is going to be a slow page load. If it is, that's more that we can look at for performance applications. It should be less than a minute. We can also look at all of the tests being run on web page tests. By default, they're private, but for anybody who makes it public, we can see their results. And someone has another website. Okay. I mean, if you want to end that one. I'll let it go. I'll do another test. Open another. What's the website? It's suburbanforagers.com. Okay. Yeah. Okay. So I'll start that one. Did you build this one? So we have one of the public tests is already done. I'll go back to the others so we can see. So this is what it looks like on web page tests. At the top, it gives you suggestions for things that you should be doing. These are the most inexcusable performance optimizations. Everybody should be doing these things. If you're getting a D or anything in red, then you know it requires your attention. So in this case, first bite time. This is actually the back end performance. We could see just from like this bird's eye view of resources being loaded. This is the first request. And it's taking a noticeable amount of time. So a second. So this is one second that the user cannot see anything on the page. Nothing has... It's just a plain white screen. Keep alive and able. This is a back end configuration. So as we request resources on the page, does the browser need to open a connection to the server every single time a request is made? Keep alive enables the browser or the client to reuse open connections. And this shows up in this waterfall chart as an orange bar. So right now we can see that there are a few orange bars, but not one for every connection. So we are working for lunch at 12 o'clock. I want to make sure that we have no time to get through. So this is suburban foragers. And I can tell you just from at a glance, there are things popping out color-wise here. The waterfall will highlight in yellow things like redirects. This is where, let's say you hit example.com and that redirects to www.example.com which may then redirect to HDTPS www.example.com. This chain of requests is bad for the user because they just want the content. They don't want to know how to get there. So if you, as the website, can just tell the user in the canonical URL, then that will cut out this middleman on all these redirects and you can just get what they wanted it at immediately. In red, these are bad requests or broken lengths you can think of. So if there's an image that can't load, it'll show up in red here. So we can dig in and see exactly what the problem is. So broken images. There's quite a few of them. So these wouldn't even appear on the page. And you can see that there's still a cost. So x-axis here is time. So you can see this is pretty, it takes a minute to load. It's still loading after a while. We'll come back to that. Actually there's a first one. Because the x-axis is time, I can tell right now that images in purple are taking a very long time. So about a minute to load an image over 3G and slow through the first one. And the size of these images bites in it, not that big. So there seems to be a server issue on this page because the lighter shade is the back-end time to respond to the request. The darker shade is just the time to download the request. So it's pretty small, 70K. But maybe this is on a shared host where it's busy responding to other requests. And it looks like there's a significant problem with response times. So do you need to call your server host thing in order to fix this? Do you need to talk to your host to fix this problem? Yes. You would need to show them results like this. And they actually really like to see results like this because it's reproducible. They can see logs of exactly what happened. And these URLs are shareable. So they're like a permanent link. So it's definitely a problem for the host to fix. This in particular is a back-end issue. Front-end issues that I can see, just looking at the resource type, JS, JS, JS, lots of JavaScript. We can actually count, actually the test isn't done yet so it won't tell us. For example, content breakdown. This will tell us how many of each type of request and how big they are. So this is a megabyte of JavaScript. And right now we're back on the server before it's done. JavaScript should be minimal. And on WordPress websites, WordPress sites don't need to do much. Maybe you have a carousel, that's the most common thing that I see. WordPress sites ship with jQuery, which is pretty compact when GZIP and minified. But one problem that I see on WordPress sites is people just throw in a plug-in at every problem that they see. Carousels are the first to come to mind, but they're actually one of the most common things that surprisingly users don't even interact with. They see it, they don't slide around, they just scroll right past it. So if you have a designer or the customer that's working with you suggesting let's put a carousel on the page or a slider, push back a little bit. I'm jumping around, but one of my take-away slides at the end is create a culture of performance where you work. Always push back and say how fast will this be? How slow will this be if I implement it? And if it hurts the user experience, is it worth it? In many cases the answer is no. So performance is another part of the user experience. And if you slow it down, then users are frustrated whether or not they can slide around a carousel won't really matter. So I do want to get to some other tools and we have about 10 minutes left. So Google Analytics, there's not much to say here. If you have it, you can find out how fast users are experiencing your site. One complaint I have about GDA is it tells you the average page load time. And like I said, performance is a distribution. And it happens that when you take the average of a distribution, it's not representative. The average, there's an old adage or an anecdote of Bill Gates walks into a bar. The average income in the bar before Bill Gates walks in is some normal math. Bill Gates walks in, now the average income is in the billions. It's not representative of the bar as a whole. On the other hand, if you take the median of income at the bar, it doesn't change when one person comes in. So that's my complaint about Google Analytics. You're looking at averages. So if somebody had like a four minute page load time, you're going to see that spike in errors in your average graph. I do know for a fact that they're changing this and it's going to get much better soon. So Google Analytics will tell you how fast your website is. Web page tests will tell you how to make it faster. I have a few other tools I'd like to show you. This is a tool that tells us that the median web page is one and a half, or 1.3 megabytes. The graph is actually interesting because it shows you how it changes over time. This tool has been operating for about eight years and the lines are showing you how that median has changed and it's growing. And these red numbers are telling you by how much? 220% on desktop, 778% on mobile. The lines are converging, which is kind of frightening because mobile users are paying for their data. They're on slow connections because they might be out and connected to cell towers and their data could be capped as well. So it's especially important that we shift more lightweight experiences to mobile users. And this graph is telling us that we're not really doing that. We're almost shipping the same experience to desktop and mobile users. Another fun thing about the HTTP archive is that people use it to identify interesting trends like when the average web page exceeded the size of the game Doom, if you remember that. Doom was 2.39 megabytes, but the average web page was exceeding 2.3 megabytes at a time. And somebody made a prediction if you plot that trajectory, you can see when exactly they'll exceed it. This happened in 2015 and, like I said, averages are kind of misleading, so we have subsequently changed over to mediums and I think we're still below Doom, but that doesn't help the case. I'll skip this. The Chrome user experience report is one of these field tools that enables us to understand the web, but the real user performance of the web. So, for example, you can plug a website into here and see what your user distribution looks like. Green is fast, orange is average, red is slow. You can see what percent of your users are experiencing fast, in this case, first content full paint. The first content full paint being, I actually have a slide for that too, something useful being displayed on the screen. A paint is just something. Your background color changed. The user is not going to be like, ah, the background color changed, I'm happy now. They want to read content, they want to see that something's happening. Dom content loaded is more about the HTML rendering on the page and on-load is when all the images are loaded. You may be tempted to think that on-load is the great metric because that's when the paint is loaded, but if you do things like lazy-loading or deferring resources, then on-load is going to be much faster and not necessarily representative of user experience. We've also added this experimental metric, first input delay. So everybody's experience is where you're on a website, you see a button, you press it, or you tap it and nothing happens. And you wait, maybe you tap it again and nothing happens. And maybe a second later, the modal opens up or it does something and that's a really frustrating experience and first input delay is measuring the first time you try to interact with the page, how long did it take for the page to respond? And this is a really good indicator of having too much JavaScript. The from your user experience report will report the distribution of what we call FID on your website. And the cool thing is that it's completely open. So you can see across four million websites, we'll jump into... Does anybody have a website that has maybe medium-sized, a lot of small websites maybe are too small. And by medium-sized, like you get visitors in the thousands per month. Does anybody have a website that's smaller? You know they're not robots. Sorry? How do you know they're not robots? The users? Yeah. Google Analytics. A robot generally doesn't interact with the page, so that would be a good indicator of... The user agent also. Google Bot has its own user agent to identify that it's a robot. Sure. French women don't get backed up. The page speed is unavailable. So I'm using page speed insights just as a quick test. So it might be too small. Well, I can show you something I know is in here. Developers. It's possible there are a few other caveats for how... Is that how you spell Coyote? Coyote. Coyote. Coyote, ugly, saloon, saloon. I know, I work at Google. No, there's one animal. He knows saloon. There is a saloon. Oh, I have no idea. No, there's two O's and one animal. I was saying you know saloon. Yeah, we do map data. Okay, great. All right, so on page speed insights you can plug in a URL and it will show you not just how fast the website is as experienced by real users. It'll tell you how to improve performance. So things like you need to reduce your server response time. It doesn't necessarily tell you how to improve your server response time because that differs by host and what exactly is going on. But more actionable things like you're loading too much JavaScript or you have too much CSS. And it'll tell you exactly what it is. You can see a lot of jQuery, a lot of jQuery plugins. Redirects, we talked about those. Those are the yellow bars on webpage tests. This is actually a good redirect. So this is from HTTPS. Or it's actually just going to dilly-dilly-dilly. So what I want to focus on is this. These colors here represent user experience. The URL for this is g.co-chrome-ux-dash. g.co-chrome-ux-dash. This will take you to Data Studio. And you can create a dashboard that's totally public. Anybody could use it. And you can share it. You can embed it on your websites. And you can see how your user experience has changed over time. Right now we have first content for Paint, but we're going to be adding tons of metrics here. Another really cool thing about this is the breakdown of whether your users are on phone or desktop. 4G, 3G, 2G. In this case, hardly anybody 2G is accessing this website. And that's kind of at odds with the stat earlier. 60% of users, low users, will write are on 2G. Keep in mind those users are probably not on the web yet. They're probably using Naiv apps. They might not be using Chrome, which this pulls its data from. So keep these in mind. But you could see exactly how users are accessing the website. And the key thing here is not only your website, but your competitors. If you have a direct competitor that's also large enough to be in this dataset, how do you stack up? Do you have similar user demographics, connection, and device stack-wise? And if so, what does your performance distribution look like? In this case, 38% of users experience fast first-contact folding, fast being less than one second. One second is really like what we try to aim for. Obviously, zero seconds is the holy grail, but we're far from that. In the final minute... What is average? Average is between one and three seconds. And slow is anything beyond three seconds. I'm going to jump ahead to what we can do to improve performance We need to monitor it. There's an acronym. I know there's so many acronyms in web development. This one is MOM. Measure, optimize, and monitor. So once you measure your web performance, you work to optimize it. And then you have to continuously monitor it to ensure that you're not getting slower, you're not regressing. Tools like WebPageTest, Google Analytics, these will tell you how your website is performing and how to improve it. Celebrate performance. I mentioned this earlier. Create a culture of performance. Push back whenever somebody says, hey, I've got a great idea for user experience. Let's put in another carousel or something. Hey, how fast is that going to be, really? And make performance another part of the user experience. Publish your case studies if you do improve your performance. Praise good examples of performance in public. I say in public here because sometimes we have a win in performance. We improve the user experience. And this kind of goes unnoticed. This is great from the top down. So if you can correlate web performance, think back to that revenue impact calculator. If you can correlate performance with revenue, then you have a very good reason for your CEO or webbers calling the shots to care about improving performance and making more money for the company. And something that I've seen being very helpful is making a little dashboard for everybody to keep an eye on the web performance and just show that at all times in the office. Or if you work by yourself, having just a web page that you visit periodically and track the performance, you want to see that performance improving over time. And incentivizing developers, and this course goes along with the next one, working with developers. The developers being all of you from my end as a developer relations engineer, we need to make it easier to make fast websites. It needs to be hard. You have to try to make your website slow. It's too easy right now to throw into the plugin on and not know that that plugin not only degrades performance, but is wildly unpopular with users. So we need to do a better job of identifying these well-lit paths to performance. Creating good documentation of how to improve performance, what are the plugins and themes that are fast, and one of the projects that I'm working on is to try to take as many of the WordPress themes and plugins as possible, and running them through tools like this, like web page tasks and page feed insights, to understand objectively how fast are these plugins and themes. Which are the ones that slow down the user experience, unless tell developers when they install them what the cost is going to be. Not just dollar cost, or how many stars it has, but how is this actually going to affect the user experience? Are you going to be posting these results somewhere? Yes, definitely. Any idea where that might be? There will be probably a blog with WordPress and on the Google Developers blog. The last thing is performance is just one part of the user experience. Like I mentioned earlier, there's so much more to the experience. People tend to focus too much on design as the user experience. If it looks good, if the colors are popping and the pictures or the images are of high resolution, that's great user experience, but it's more than that. Is the website accessible? Can people even use it? And along those lines is it fast. If they're going to be abandoning, it doesn't matter how high quality your images are. So here's the one-page error. HTTP Archive has a WordPress lens where we have a bunch of stats about WordPress specifically. You can access that at WordPress.htparchive.org. The Chrome user experience report here's a link to the documentation. Also, my contact information is on the left side if you want to reach out to me for a reason outside of business cards if you'd like, reach out to me on Twitter. So that's it. Thank you.