- [Instructor] Measuring your project up
against the performance budget for the first time
it's normal to discover you are way over budget
and there's a lot of things you can do
to improve the performance.
There are typically three main areas
which stand out as significant performance culprits,
images, JavaScript bundles
and external web fonts.
And we can use Lighthouse for a performance evaluation
and then get a report
that tells us about these obvious issues
so we can deal with them immediately.
Let me show you an example of this.
So I have an incognito version of Chrome here,
I'll paste in the URL to a domain that has a site on it.
You'll notice this one is HTTP not HTTPS
meaning I'm getting an HTTP 1.1 request here,
which does not have multiplexing.
Now loading the site,
it appears to be running pretty fast.
So let's see what happens if I go and run Lighthouse.
So I'll just run to generate a report,
send the requests,
do a bunch of analysis
and then some data comes back,
and what we get is a performance score of 93
which is pretty good for the site.
You'll see that the green is between 90 and 100.
Scrolling down, there are still some opportunities
for improvement that are being flagged by Lighthouse,
properly sized images,
meaning we are serving large images
when we should actually be serving smaller ones.
If we open this,
you can see there are some suggestions
on how much we could save
by just reducing the image sizes.
We'll talk about that later on
in the chapter on image optimization.
There's also eliminate render blocking resources.
This is when we are using files
that are stopping rendering from happening
that are unnecessarily large,
in this case, it's the main style sheet.
So the style sheet is not as optimal as it can be.
To solve this we can do
what's known as critical CSS rendering
where we place the important CSS
that needs to be rendered in the top of the page,
inside the HTML documents,
and then we defer the rest of the CSS for later loading
we'll also talk about that later on in the course.
Then we have serve images in next-gen formats
I mean swapping from existing formats
to something like WebP,
and we have use HTTP/2
which is adding an HTTPS certificate
and then taking advantage of multiplexing
to serve the falls.
So this is useful
but to truly see what is actually going on,
we need to dig one step further
and that's using the network monitor.
So here I'll check disabled cache and reload the page
so you can see the waterfall being built.
Now, because we are now getting a site through HTTP/1,
it means that we are not getting multiplexing
which is why this waterfall is stretched so much as it is.
This by the way is also where you see
that whole six connections opening thing happening
that some of the files are being deferred in loading.
So, obviously here we have six connections
and then we scroll down
then we have six more connections and so on.
This waterfall will show me information
about all the things that are happening
between the server and the browser.
So if I hover over this first item here
which is the HTML document itself,
we see some of the things
we've talked about previous in the course.
So, we have the DNS lookup,
how much time that took.
Then we have the initial connection
this is the TCP handshake and everything else,
that's just a server on the browser talking
to each other for the first time.
Then the request is sent,
then we wait.
So time to first byte for this file is 149 milliseconds
and then finally the download happens.
So the green bar here, is when nothing is happening.
This is the time it takes from the request to be sent
all the way to the server
and then the data to come all the way
back to the browser again.
And if we look at this breakdown
we see there's a lot of green
meaning the server's really slow.
That might just be because the server is far away,
or it might be because the service actually slow.
And obvious solution to this
would be to introduce a CDN into the mix
because a CDN would always have a shorter time
to first byte then whatever server we're using here.
So this immediately tells us,
"Hey there are opportunities for performance improvements."
The other thing we see
is there are a ton of assets being loaded here.
You can see there's all these images
flaxseed oil and iron and everything else.
and if I go scroll on this page,
eventually we'll get to those images,
but they're really far down on the page.
So all of these images should be deferred
in the loading as much as possible,
and ideally they shouldn't actually be loaded
into the browser at all,
unless I scroll down to them
because we're wasting resources.
For that we can use lazy loading
and that lazy loading also applies
to both CSS and JavaScript.
We can intentionally not load content into the browser,
and not waste the user's data
if we don't think the user will get to it
and then just trigger it once the user
scrolls close to that content.
That way we're not loading
all of this stuff into the browser that you see here,
unless it's actually necessary.
Seeing a waterfall like this
makes it immediately apparent why performance optimizations
like deferring scripts,
and lazy loading images
and putting in place proper font loading strategies,
make a huge difference.
And you also see why adding something
like a CDN into your process,
gives you immediate performance enhancements.