 Hey there, I'm Case. This tutorial shows you how to use Chrome DevTools to find ways to make your pages load faster. You don't need to know anything about load performance, but I do assume that you know the basics of web development and that you're vaguely familiar with DevTools. But you're welcome to leave me questions in the comments if you get stuck on anything. Our goal today is to help my good friend, Tony the Cat, speed up his site. Along the way, you'll learn a lot of useful tools and workflows. But first, let's get set up. I recommend you use an incognito window because it ensures a clean testing environment. Chrome extensions, in particular, often interfere with the auditing workflow that I'm going to show you. Go to Chrome colon slash slash version to check what version of Chrome you're running. I'm using Chrome 68. If you're on a different version, the DevTools UI may look different. In general, you should still be able to get through most of the tutorial. Just keep in mind that some features may be missing or the UI may look different. To open the source code for Tony's site, go to glitch.com slash edit slash pound exclamation slash Tony. Click Tony, then click remix this. You now have your own editable copy of the code. Throughout the tutorial, I'll refer to this tab as the editor tab. To open the demo, click show live. I'll refer to this as the demo tab. Open DevTools by pressing Command Option J on Mac or Control Shift J on Windows, Linux, and Chrome OS. Whenever you set out to improve a page's load performance, always start with an audit. The audit has two important functions. One, it creates a baseline to measure subsequent changes against. And two, it gives you actionable tips on how to improve. Open the Audits panel and you see a set of config options. Update yours to match what you see here. The mobile option simulates mobile by changing the user agent string and resizing the viewport. The desktop option pretty much just disables the mobile stuff. The audits option controls which categories of audits to run. The throttling option simulates how the page performs on a mobile device, which I'll explain in a moment. And the clear storage option deletes all storage before loading the page, which is essentially how first-time visitors experience your site. When you want to audit the repeat visitor experience, you should disable this option. Click Run Audits, and DevTools measures the page's load performance and looks for bottlenecks. Earlier, I mentioned that we're using simulated throttling. Right now, DevTools isn't actually throttling your CPU or network. It just extrapolates how long the page would take to load on a mobile device based on how long it's taking on a desktop. Now we've got a report. This is our baseline. The number at the top of your report is your overall performance score. The higher, the better. Below that, we've got the metrics section. Each metric provides insight into a different aspect of the loading experience. For example, first contentful paint measures when the primary content of the page is shown to the user, whereas time to interactive measures when the page is ready to handle user interactions. Hover over a metric to learn more about it and click Learn More to read its documentation. Below Metrics is a collection of screenshots that show you how the page looked as it loaded. The Opportunity section provides specific tips on how to improve the page's performance. The Diagnostic section gives you more detailed information about what was happening while the page loaded. And the Past Audits section shows you what the site is doing well. Now that we have a baseline, we can start experimenting with changes that will hopefully speed up the page. We're going to make one change at a time and then run an audit in order to measure how that isolated change affects performance. If we made multiple changes and then ran an audit, we wouldn't be sure about how each change affects the page. Our report says that enabling text compression is the biggest opportunity, so let's start with that. First, let's confirm that compression is indeed disabled. Click the Network tab, then click Use Large Request Rows, then hold Reload and select Empty Cache and Hard Reload. There's now two values in the size column. The top value is the size of the downloaded resource. The bottom value is the uncompressed file size. Since these two values are the same, this confirms that compression isn't happening. Also note the total download size down here, which is quite large. Now let's enable compression. Go to the Editor tab, open server.js, import the compression library, and then call it. Make sure to put the call before this other app.use statement. Wait for the new build to deploy, then go back to the demo tab. Let's manually verify that text files are being compressed. We want to reload the page as if we were a first-time visitor, so hold Reload and select Empty Cache and Hard Reload. Back in the size column, the downloaded size on the top is now smaller than the uncompressed size on the bottom, so it looks like compression is working. Let's run another audit and see if our score has improved. Go back to the Audits panel, note your score from the last audit, click Perform an Audit, then click Run Audits again. The new report shows a higher overall performance score, so it looks like text compression was a success. The latest report says that properly sizing images is now the biggest opportunity, so we'll try that next. Go back to the Editor tab, open model.js, and change Big to Small. Wait for the new build to deploy, then go back to the Demo tab and run another audit. The performance score has improved again, so it looks like resizing images was also a success. In the real world, there's a few ways to handle images. You can resize them during your build process or create multiple sizes and use the source set attribute to let the browser decide what size it needs, or you can use an image CDN that lets you dynamically resize images when you request them. At the very least, if resizing is too much of a hassle, just make sure to optimize your images. That usually yields big performance wins. Moving on, the latest report says that eliminating render blocking resources is now the biggest opportunity. What does that mean? Well, if you include a link to an external style sheet in your HTML, the browser must download, parse, and execute that file before it can finish loading the page. That's render blocking. It can happen with JavaScript too. Our goal is to get rid of any render blocking code that isn't truly needed for loading the page. But first, we have to find it. Clicking the render blocking audit shows us which resources to focus on. It looks like the site is using some third party libraries, so let's investigate why these libraries are needed in order to load the page. Press Command Shift P on Mac or Control Shift P on Windows, Linux, and Chrome OS to open the command menu. Type coverage, then select Show Coverage. Click Reload, and the Coverage tab shows a breakdown of how much code from each file is unused. Click jQuery.js, and DevTools opens that file in the sources panel. A green bar next to a line means that the line was executed, and a red bar means that it wasn't. A lot of the code that was supposedly executed are just comments, so minifying this file and stripping out all comments could be one way to reduce its size. For your own code, the Coverage tab is a good way to isolate exactly which code is truly needed for loading the page. If you remove all the unused code from your file and only ship what's used, this can often result in some significant speed boosts. For Tony's site, I have a hunch that these libraries aren't even used at all, so let's see what happens when these files are blocked. Press Command Shift P or Control Shift P to open the command menu again. Type block, then select Show Request Blocking. Click Add Pattern, then type Slash Libs Slash Star, then click Add. Go back to the network panel and reload the page. The Lodash and jQuery requests are read now, which confirms that they were blocked. I can still interact with the site, which confirms that these files aren't even used, so let's remove them from the code. Back in the Editor tab, click template.html, then remove the script declarations. Wait for the new build to deploy. Go back to the demo tab, note your previous score, and then run another audit. The score has improved again, so it looks like this is another step in the right direction. In general, request blocking is useful for seeing how a site behaves when any given resource is unavailable. In your own code, you may not be able to remove scripts completely, but you should be able to move less important code to other files and tell the browser to fetch those files asynchronously by adding the async attribute to your script tags. For the next optimization, we'll need the performance panel. In the Opportunity section, there's some minor potential savings, but down in the Diagnostic section, it looks like main thread activity is a big bottleneck. The main thread is where the browser does most of its work, including parsing and executing HTML, CSS, and JavaScript. Our goal right now is to find main thread work that can be deferred or eliminated. Open the Performance panel, click Capture Settings, set Network to Fast 3G and CPU to 4x slowdown. Unlike simulated throttling in the Audis panel, these settings actually do throttle your network and CPU to simulate a mobile device. They're active so long as you have the Performance panel open. Click Start Profiling and Reload Page. DevTools collects everything that happens as the page loads and then shows you a visual report of the loading process. The load process is displayed chronologically from left to right. The wall of yellow that you see here in the CPU chart is a hint that the CPU was completely busy with scripting activity, so we may be able to speed up load time by using less JavaScript. Let's keep investigating. The User Timing section shows that React is measuring certain milestones during its bootup process. You can mark up this User Timing section in your own app with the User Timing API. I happen to know that you can only see this info when React is in development mode, so switching Tony's app to production mode might yield some easy performance boosts. Moving on, the main section shows main thread activity. Again, this is a chronological log events. Stuff on the left happened first and then stuff on the right. The vertical axis shows which events caused other events to occur. For example, this function called the one below it, which in turn called the one below that, and so on. When you use a framework like React, most of the upper activity is caused by the framework, which is usually out of your control. The activity that your app causes is usually at the bottom. By the way, if you're using a trackpad, you scroll this section by clicking and holding, swiping with two fingers, zooms in and out. But you can also disable the zoom behavior by going to settings and changing the flame chart mouse wheel action setting to scroll. Down at the bottom, it looks like the app constructor takes a long time to execute. To understand why, we look at which functions it calls, and it looks like it's just calling one function, minBitcoin. So now we can infer that the main thread is busy because of this minBitcoin function. Thanks to the performance panel, we've now got two ideas on how to do less main thread work, switching to production mode and removing the call to minBitcoin. Back in the editor tab, open webpack.config.js and change mode development to production. This instructs webpack, which is the build tool for this app, to do some super clever stuff called tree shaking, which essentially removes any code that the app doesn't need. When the change is deployed, go back to the demo tab and audit the page again. The score has improved, but the main thread still does a lot of work. Let's see if removing that call to minBitcoin fixes that. Go back to the editor tab, open app.jsx and comment out the call to minBitcoin in the constructor. Wait for the change to deploy, then go back to the demo tab and audit the page again. All right, we did it. The page loads much faster now and Tony is very thankful for our help. The key thing to remember is to audit your page to establish the baseline, use your report to find out how to improve the page and then introduce changes one by one, auditing the page after each change to make sure that you're heading in the right direction. Thanks for watching. Leave me questions and feedback in the comment section.