Improving Load Performance – Chrome DevTools 101

By | August 26, 2019

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!/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]

70 thoughts on “Improving Load Performance – Chrome DevTools 101

  1. Ajay Solleti Post author

    I want more cats from now on in these talktorials

  2. Jesper the End Post author

    The key thing to remember is to not add bitcoin mining functionality on page load lol

  3. Alessandro Giordo Post author

    Really helpful, I laughed hard on the mineBitcoin function 😀

  4. supercop104 Post author

    this is awesome! Can you do a hairstyle tutorial next?

  5. Venky Venkataraman Post author

    Awesome video Kayce. Brilliant as always 👏👏 .. wonder if your cat is mining your cat food 🤔🤔

  6. Rock Rabin Post author

    I think coverage panel doesn't evaluate all uses function from depended files.

  7. Jonathan Feldman Post author

    Somewhat related, but when you mentioned adding the async tag to script elements it reminded me of an issue I had with fonts. Whenever I add a font or an icon set like material icons to my site, the audit tab complains about it being a render blocking resource that takes a moderate amount of time to load. I think some blog posts I read suggest asynchronously loading the font via JavaScript, but that seems a little complicated. It looks like adding a preload tag for the font before the link tag that actually references it sometimes causes it to pass the audit, but I'm not sure if it has any actual effect on page load. Any suggestions on how to avoid it? I know font loading comes up frequently so sorry if this has been asked a lot.

  8. Marcos C. Santos Post author

    This was the best video to introduce me to learn basics of performance of web. Thank you, I was looking for something like that.

  9. Mr Claytron Post author

    Awesome video Kayce!

    I hope Tony has found a better way to mine for Bitcoin… That's one hell of a talented cat! 🙂

  10. gagan deep singh Post author

    Indeed a great video. What do you recommend to make performance measurement for angular 6 application? Angular build creates files which are out of my control.

  11. Gilney N. Mathias Post author

    Holy… That was very informative kk' Thank you!

  12. Husam Ibrahim Post author

    Love this series. And that mineBitcoin() was a nice touch 😀

  13. Timur A. Post author

    У каждого из нас есть своя функция 'майнинг биткойн'. Спасибо ребят за то что делаете, дай вам Бог здоровья))

  14. MOSHIUR RAHMAN Post author

    Awesome!! Where can I get more learning resources about Audit, Performance and resources about how does use them to improve load performance ?

  15. dave john dacalos Post author

    Im here trying to speed up a certain website and ending up still not know how to do it.

  16. João D. Freitas Post author

    Hi. Can I upload my own site into If so where can I find more info on the subject. Thks.

  17. SogMosee Post author

    god levels of dope. Didn't know chrome console could be used and abused this way

  18. FLY Sports Post author

    Very helpful especially for a novice developer like me.

  19. Harinder Saggi Post author

    Thanks brother but my website in WordPress how to fix all issue according to lighthouse

  20. Dhaval Solanki Post author

    Hello Sir, I did not undrstand that how should I add my project for example your project name is tony and for mine is for which I want to decrease page load time.So please guide me how to add my project to glitch tool.

  21. aloeveraforever Post author

    Hi Kayce, this would have been the perfect video for what I'm looking for BUT I'M USING WORDPRESS. So I'm absolutely not used to put hands on codes and I'm not even shure if this would be possible.
    Do you have an idea where I can find some tips like your for wordpress users?
    If you have time to look at my Audit, my slowest page is:
    Hope your best friend is a WordPress-freak! Send me a note, a beer or wine is waiting for you in Italy!
    Greeting, Martina

  22. Sandro Treglia Post author

    hello congratulations for the tutorial I registered with my email and I followed your tutorial! How can I view my incognito site to optimize it? Thank you

  23. Carlos Gomez Post author

    7:03 When Showing Coverage, does it matter if Webpack is in development or production mode? I'm assuming that you'd want to use development mode in order to view the unminified source and have the coverage show red/green accurately (as opposed to production mode, where the source might be minified). Can anyone confirm?

  24. Adriving School Wellingborough Post author

    Great tutorial. Can you fix load performance for my driving school website

  25. Motiur Rahman Post author

    I have made every changes you made. And it works. But when I go to check the changes after closing the chrome, it shows previous settings again. How can I solve this. Please reply me. Thanks for a nice video

  26. Motiur Rahman Post author

    I have made every changes you made. And it works. But when I go to check the changes after closing the chrome, it shows previous settings again. How can I solve this. Please reply me. Thanks for a nice video. Please reply

  27. Mohammed Moniruzzaman Post author

    Extremely helpful, Thank-you Brother.

  28. Roy London Post author

    in this video at 4:44 mark you said to import the compression library . I've been trying to figure it out . How do I import the compression library. I'm stuck at this stage. 😕Thanks ☺

  29. Sudhanshu Mishra Post author

    How we add two image as background image and one image?

  30. Jared Newnam Post author

    I'm fairly new to using the Chrome Dev Tools, but these files you're loading to better load time (server.js, model.js, etc.) – Are these files I simply create in the root or are these files specifically contained within a Glitch hosting environment?

  31. ravi kishore Post author

    How do I audit a page which is part of flow whose url cannot be loaded, like I go few steps further by clicking few buttons and this is done using traditional xhr calls and the url of the page doesnt change.

  32. Maximilian R Post author

    Thank you!!! Holly molly! I didn't think I was going to make it through this video with its instructions. A great instructor will make it a breeze! Gee! Can't believe I made it through all the scripting. Thank you! The score changed from 0 to 100! LOL Unreal! I am an appraiser and have to load tens , or hundreds, of property listings sometimes, to complete analyses in Excel. It was loading too slow. Now, it made a huge difference. Thanks, again!

  33. julio cornelio Post author

    is creating sprites for images still a thing?

  34. julio cornelio Post author

    great tutorial. very well made. thank you

  35. Ayyash Ayyash Post author

    great video, seriously deranged conclusion, you enhanced the performance by removing a functionality? I too can display a "hello page" html page in no time, I really was looking for more… like does set timeouts enhance or block page rendering?

  36. Right Wing Courier News Post author

    Tony, the cat is adorable, You did a great job!!! Please tell Tony Thank You for the fish on the Dev Pg. really well-done Video I think I can make My site load better. Ohh with that being said, does the Google Dev tools work on WordPress site? or do I need to do something else? Thank You

  37. Drill SEO Post author

    Nice Video, learned more about using google audit tool which is inside my browser


Leave a Reply

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