 Welcome back. We've got a lot of new features coming in Chrome 65, including local overrides, new accessibility tools, the changes tab, new performance audits, a whole new category of SEO audits, multiple recordings in the performance panel, and reliable code stepping for workers and async code. If you've ever changed some CSS and DevTools, you probably learn the hard way that your changes get erased when you reload the page. Local overrides provides a lightweight solution for saving your changes across reloads. Before I set up overrides, let's see the old behavior. When I change this link to purple, then reload the page, the change is gone. Now I'll set up overrides and try it again. Go to the sources panel, open the overrides tab, click select folder for overrides, choose a location, then click allow to give DevTools access to that folder. Now when I edit the links color and reload the page, the change is still there. The way it works is that when the page requests this file, DevTools serves the modified file on my computer instead. This purple dot next to the file name means that overrides is set up for this file. Overrides has two limitations. First, changes to the DOM tree don't work. For example, when I edit some text and reload the page, the change is gone. Editing HTML from the sources panel does work though. Second, changes here on element dot style don't work either. I can explain why that is in the comments. In terms of accessibility, contrast ratio affects how readable text is. For example, if some text is light gray and the background behind that text is white, that text will be hard to read. The color picker now warns you when the contrast ratio of a text element falls below recommended accessibility levels. To open the color picker, select a text element, then click the preview icon next to the elements color property. One check mark means that the element meets the minimum recommended contrast ratio. Two check marks means that it meets the enhanced recommendation. Click the contrast ratio section to show the contrast ratio line up here in the spectrum. Since this element meets recommendations, it means that anything below this line also meets recommendations. Anything above the line doesn't. The second new accessibility feature coming in Chrome 65 is the accessibility tab. Select an element in the DOM tree, then open the accessibility tab, and you can see its position in the accessibility tree, as well as its ARIA properties and computed accessibility properties. The Audis panel has a whole new category of SEO audits, which may help you improve your search rankings, as well as many new performance audits. By the way, the Google Webmaster blog recently mentioned that page speed will be a factor in mobile rankings starting in July. So if you've been meaning to improve your load performance but didn't know where to start, the Audis panel is definitely the best place to begin. To run audits against whatever page you've got open, just go to the Audis panel, then click perform in the audit. We've also got audits for best practices, accessibility, and progressive web apps. After 20 seconds or so, DevTools gives you a report like this on how you can improve the page. In Chrome 65, there's some subtle changes to how DevTools steps through code that passes messages to workers. First, let me show you the old behavior. I click this button and I pause in the click listener. When I step into the next function call, it goes to the next line of the click listener. When I step again, we jump to the on message listener. In other words, we can't see what's going on in the worker. Now, here's the new behavior. I click the button and pause in the click listener again. Now, when I step into the next call, it takes me to the worker code. This worker code happens to just post this message in reverse back to the main thread. So let's see what happens when I step into that call. It brings me back to the main threads on message listener as you'd expect. We've also made some changes around how DevTools steps through async code. Here's the old behavior. When I click this button, I pause in the click listener. When I step into set time out, it jumps to the next line of code that chronologically executes. Eventually, if I keep stepping, I'll pause in the set timeout callback. Now, let's see the new behavior. This time, when I step into set timeout, DevTools runs all of the other code behind the scenes and now I'm paused at the first line of the callback. If you want the old behavior, you can use the new step button over here. In the performance panel, you can now temporarily save up to five recordings over on the DevTools homepage. I'll start a recording and scroll a bit. Then stop the recording and we can see the recording here in the performance panel. Now I'll start another recording and open search box and close it. Then stop the recording. And now we can see that second recording to go back to the first recording. I just use this drop down menu here. Alright, that's all for Chrome 65. The bonus tip for this week is a Node.js library built by the DevTools team called Puppeteer. Puppeteer is essentially a browser automation tool that has access to DevTools features. Here, I've got a little Puppeteer script to take a screenshot. It opens Headless Chrome, then loads a page, then takes a screenshot of that page. I run it like any other Node script. And then after a few seconds, I've got a screenshot of that page on my desktop. Thanks for watching. If you've got any questions, drop me a line in the comments, and I'll see you in six weeks for Chrome 66.