Chrome 65 – What’s New in DevTools

By | September 5, 2019

[MUSIC PLAYING] SPEAKER 1: 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 in Dev Tools, you’ve probably
learned 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
PRPL, 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 Dev
Tools 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, Dev Tools serves the modified
file on my computer instead. This PRPL 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 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 element’s 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 appear 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 Audits 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 Audits panel is definitely the
best place to begin. To run audits against
whatever page you’ve got open, just go to the Audits panel,
then click Perform An Audit. We’ve also got audits for
best practices, accessibility, and progressive web apps. After 20 seconds
or so, Dev Tools gives you a report like this on
how you can improve the page. In Chrome 65, there’s
some subtle changes to how Dev Tools 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 Dev Tools steps through async code. Here’s the old behavior. When I click this button, I
pause in the Click Listener. When I step in to
set timeout, 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, Dev Tools 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 Dev
Tools home page, 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 the 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
dropdown menu here. All right, that’s
all for Chrome 65. The bonus tip for this
week is a Node.js library built by the Dev Tools
team called Puppeteer. Puppeteer is essentially
a browser automation tool that has access to
Dev Tools 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. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *