- [Instructor] To see how much of your JavaScript and CSS
and other code is loaded unnecessarily into the browser,
you can use the coverage view in the browser dev tools.
You get to it by opening the dev tools,
opening the settings here and going to more tools
and coverage.
When you open coverage, you need to reload the page
and you get a visualization, immediately,
of how much of the code is not being used.
So anything in red here is not being used.
And you can see right away that this JavaScript file
has a lot of unused code
and my main styles sheet also has a lot of unused code.
If you then click on any of these code files,
you can see a full breakdown
of exactly which rules are in play
and which rules are not in play.
If you see anything marked in red, here,
it's a rule that is not currently being used on the page.
This is what Critical does, it runs this type of process
and then identifies which rules are being used
and which rules are not being used,
but in the view port, and then it picks and chooses.
There're also other automated tools you can use
to further cull the CSS you're not using
and the JavaScript you're not using.
But it's a bit of a challenge
when you're working with one giant style sheet.
Because if you have one giant style sheet,
it often applies to multiple different pages,
you need to compare all of these pages
and do a bunch of work.
A better solution would be if we could modularize our CSS
and split the CSS into smaller components
and then load them only if they are needed.
And one way we can do that is by deferring loading of CSS
until something happens.
Now, you already saw an example of that in Critical.
You'll remember when we used Critical,
the Critical CSS was in lined
and then the rest of the styles
were put in this uncritical CSS file and deferred.
So, here's a different way of doing the same thing.
What happens here is we set the rel preload
and as style attributes into the link element,
to tell the browser to preload this style sheet
when there's processing available,
meaning the loading is delayed to avoid render blocking.
Then the on load attribute fires
when the CSS is fully loaded
and sets the rel attributes to style sheet
so the browser recognizes it and renders it.
But this non script element at the bottom
is a fall back for browsers that don't have JavaScript,
and in that case,
they will just immediately load the style sheet.
There's also a bleeding edge way of doing this
using the disabled attribute, that you see here.
This style sheet will not be loaded by the browser at all
until the disabled attribute is removed or set defaults.
You can then set up a JavaScript function
to change the disabled attribute if, and only if,
some event occurs.
And that event could be activating a gallery
or triggering a JavaScript
or triggering some external function
and only then will the browser go to the internet,
pull down the style sheet, and mount it in the browser.
This means we can now split up our style sheet
in many different pieces and then progressively load them,
only when it makes sense to do so
in the browser using standard html.
This is really cool
and it makes performance of CSS much more powerful.