Code Coverage Analysis for Better Page Speed

Ian Lurie

My team wrote a complete guide to page speed. You can find it here.

It’s aggravating. You smushed the images. You smashed the files. Your site’s still getting a lousy page speed score. You shake your fist at the internet gods and scream “Why!?!! WHY DO YOU MOCK ME?! Why?!!”

Your problem might be “dead code.” Dead code (aka code boogers, code klingons, code fungus) is leftover and unused CSS, javascript, and HTML. It forces your browser to download and sift through all manner of useless crud. It slows both download and rendering time. Remove dead code, and your page speed gets a nice turbo boost.

(Or, you could just hire us – we do some pretty nifty page speed optimization. I leave that up to you)

All you have to do is comb through thousands of lines of gobbledygook and find the stuff you don’t use. By hand. Testing to see what’s required and what’s not. It’s like Hell, without the comfy parts.

Chrome’s Coverage Report promises to help. It highlights and diagnoses dead code. But does it work well enough that a semi-competent site builder like me can use it? Here’s how I tested it, how I used it, and the results:

Nerd Mining Ahead

This post unearthed deep, rich veins of nerd ore. I talk about critical rendering path, etc. etc. I mess around with code. I may have snorted at a few of my jokes.

You have been warned.

The Test

For this post, I downloaded the Portent site, screwed up the code, and added some junk.

I ran the site from MAMP on my laptop.

That gives me this godawful audit score:

A lousy page speed score
score

A lousy page speed score

Audits are a relatively new, mobile-focused report in Chrome. Go to Developer Tools, click “Audits,” and you’re off.

By the way, that score’s pretty good. Here’s one of our competitors:

An even lousier page speed score
score-comp

An even lousier page speed score

I thumb my nose at them. Not that it’s a competition. Oh, wait, yes it is.

But I’m picky. I want to get faster. I’ve already compressed images. I’ve got server caching turned on.

The best next step to improve it is to streamline the critical rendering path. The critical rendering path impacts the time your browser needs to get from this:

Rendering starts with a blank page
fromthis

We start as a blank page. Especially if we're a web site.

To this:

It ends with a web site
tothis

A page with some life experience

That means removing bloated CSS and javascript. Yes, I could just plunk it all in the footer. But then the page first displays all weird, then restyles. And it only brought my score up to 47. So it’s not a great fix.

I need to do four things:

  1. Find every line of non-essential code and delete it. Less code is better
  2. Find the CSS required for the first page “paint”
  3. Find the javascript required for the first page “paint”
  4. Put those first and move everything else to the bottom of the page

The Coverage Report

This is a slick, relatively-new Dev Tools feature.

Be sure you’re using the latest version of Chrome. I’m using 61.0.3163.

To load the coverage report:

  1. Open Developer Tools
  2. Show the Console Drawer
  3. In the Console Drawer tabs, click “Coverage”

Here’s what you’ll see:

The coverage drawer in Chrome Dev Tools
coverage-drawer

The coverage drawer in Chrome Dev Tools

If you’re having a hard time finding the coverage report, make sure the console drawer is open and click the three vertical dots. You can select Coverage from the list that appears:

Click here for the coverage report
coverage-link

Click here for the coverage report

Using the Report

Click the reload button. You’ll see the report. We care about the “Unused Bytes” column:

The code coverage report
coverage-report

The coverage report

That shows us the percentage of unused code in each file. Thanks to my intentionally awful coding, the test site uses only 12% of bootstrap-custom.css.

I can trim that. But I still don’t know what to trim. That’s the next step:

Reviewing Coverage

If I click on bootstrap-custom.css, I see the file. Chrome shows used and unused lines of code in green and red, respectively:

Nice! Dead code highlighted!
highlighted-file

Nice! Dead code highlighted!

How awesome is that?!!! I’m sweaty just looking at it.

I can get the same report for every file, including the page HTML itself.

Now, I can review my page, CSS, and javascript, remove unused code, and rearrange the rest for more efficient rendering.

Streamlining the Files

First, I saved a backup of my CSS and javascript files.

Next, I carefully deleted unused lines in bootstrap-custom.css, index.html, and my various javascript files. A lot of this code was left over from previous site versions or duplicated elsewhere during development.

For more about “carefully,” see “A Warning,” below.

I found a lot of dead CSS. My test site didn’t use lots of standard Bootstrap stuff, like glyphicons, columns, alerts, and progress bars. Deleting those removed about 2,500 lines of code. Then I found all the old, leftover code from previous site versions and deleted that, too.

My updated coverage report looked like this:

Custom Bootstrap, streamlined for better page speed
streamlined-custom-bootstrap

Custom Bootstrap, streamlined

Bootstrap-custom.css now has 40% unused bytes, instead of 88%. The 40% unused is CSS I need for other pages on my site, so I left it in.

I also found dead code in my HTML and various javascript files. I cleaned all that out.

Why did this help?

“Dead” code—code that doesn’t do anything—drags downloads and rendering. Your browser still has to download, parse, and render it.

By deleting unused code, I reduced file size by 30%. I also dumped about 9,000 lines of code. That’s less for my browser to parse and render.

I also reduced index.html from 191k to 9k.

This work raised the page performance score to 60.

A Warning

It’s tempting to start deleting hundreds of lines at a time, then publish. Don’t. Styles that don’t matter to one page may be essential to another. Lazy loading might mean some javascript fires only when the user scrolls down. Media queries might need CSS you’re not currently using. You need to test.

I save backups. I also use Git, checking in my code every few minutes. That lets me roll back to a previous version if I screw something up.

Separating & Organizing

Then, I took all forms-related CSS and put it into a separate file. I can load that when I load a form, instead of loading it on every page.

I pulled all the blog-related CSS and put that in a separate stylesheet.

And, I put any unused javascript in separate .js files for inclusion on other pages, as well.

Why did this help?

No sense loading CSS you don’t even use. Same with javascript. That speeds things up a little bit more.

This work improved my page performance score to 65.

End Result: A Better Page Speed Score

I did a little more cleanup, minifying the most bloated files. The final result was a performance score of 66:

better page speed!
final-score

Huzzah!

Was It Worth It?

This was a lot of work. But I shaved a full second off rendering time and improved performance score 55%. As a bonus, I cleaned up my code. It’ll be easier to maintain.

Thumbs up. Five stars. Worth it.

Know Any Tools?

That said, I still had to go through these files by hand. It took me three hours. My dog wanted ear scratches and kept slobbering all over my laptop. My cats got impatient with me and started pawing at my face for attention. And it was a one-way trip down the carpal tunnel.

I’ve heard tales of magical tools that do this cleanup for you. I haven’t had time to dig in and find them. If you know one, let me know.

A Quick Pitch

My team wrote a complete guide to page speed. Check it out.

Start call to action

See how Portent can help you own your piece of the web.

End call to action
0

Comments

  1. Hey Lan!
    Such an awesome post to fix the speed of a side on the geeky side. I use wprocket + Cloudflare setup on most of my WordPress based sites, and this setup gets a more easily 90+ score. Still, I will cross-checking about the coverage report.
    I observed one thing over here,
    When we enable the ad blocker, the social signals on this blog post gets disappeared. When I disable ad blocker, I see social signals.
    Please fix it, and your article deserved a lot of sharing 🙂
    PS: I shared it on twitter too.

  2. Excellent post as always Ian. I often find that the simple act of splitting CSS / JavaScript files based on templates etc. can have a massive impact. Most devs argue about caching etc. but loading all the CSS for the blog, the Xmas page from 2014 and all the other pages that house 1% of the overall pageviews, on every page is madness.
    Many don’t even realise they have it set to no-cache in the headers anyway…
    Anyhow, Happy Halloween and hope to bump in to you in Vegas (if you are there and my jet lag allows me to see straight).
    Malc.

  3. This is great! We both have a passion for speed and chasing the 99th percent, and #TIL about this new unused feature in Chrome (been in Firefox land for the past few months in their Dev environment).

  4. Thanks for the great post! I have a quick question though…
    I am a “non-dev”… I got a template on Hubspot for our website, which means the main CSS has A LOT of unnecessary codes (to facilitate even the pages that we ended up not using)… Would you recommend me just have different trimmed-down CSS files for each page, or how should I approach it using your tool?
    Thanks!

    1. I’d use the coverage report to find and remove unnecessary CSS and leave it at that. You don’t want to get too fancy with third-party sites like Hubspot.

  5. Thank you for that article, Ian. I liked the part withe the coverage the most, since it’s hands on useful!
    Tools we use:
    https://www.webpagetest.org/ – Get Insights about ttfb, speed index and page load time. Useful if you want to compare yourself with your competitor.
    https://github.com/micmro/performance-bookmarklet – It’s handy to make a quick analysis of a page, when testing different changes, without doing the big test on webpagetest.org
    – We implemented the RUM Tracking Pixel provided by webpagetest.org with a lokal Kibana and Elasticsearch to get longtime insights about our Pagespeed. This helps to see if a version of an application made the site faster or slower on a regular basis

      1. hi,

        Is there a way to only show the green color for coverage tool, I have very big css file and the coverage is just 3% I want to show those and cut them from the source.

        1. Hey Bashar. So a littler further down in the article it explains how you can drill into each specific file and see what Chrome detected as being used or not used. Once on the Coverage report tab, you can click into each individual file and it will highlight what is being used in green and what’s not in red. From there you can remove those lines of code — or pull out the green highlighted code snippets and build a new file. Hope that helps!

Leave a Reply

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

Close search overlay