[MUSIC PLAYING] KAYCE BASQUES: Hey
there, I'm Kayce. 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 a Chrome://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/edit/#!/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 at 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 Metric 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 Opportunities section
provides specific tips on how to improve the
page's performance. The Diagnostics section gives
you more-detailed information about what was happening
while the page loaded, and the Passed 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 lets 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 file 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 stylesheet 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
/libs/*, 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 Opportunities
section, there is some minor potential
savings, but down in the Diagnostics 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 Audits 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 on 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 boot-up 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 of 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
are 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 Flamechart 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, mineBitcoin. So now we can infer that the
main thread is busy because of this mineBitcoin 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 mineBitcoin. 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 mineBitcoin fixes that. Go back to the Editor tab. Open app.jsx and
comment out the call to mineBitcoin 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. [MEOWING] The key thing to remember
is to audit your page to establish a 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 comments section. [MUSIC PLAYING]
