Code Coverage Analysis for Better Page Speed
Ian Lurie Oct 30 2017
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?!!”
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.
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:
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:
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:
I need to do four things:
- Find every line of non-essential code and delete it. Less code is better
- Find the CSS required for the first page “paint”
- 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:
- Open Developer Tools
- Show the Console Drawer
- In the Console Drawer tabs, click “Coverage”
Here’s what you’ll see:
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:
Using the Report
Click the reload button. You’ll see the report. We care about the “Unused Bytes” column:
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:
If I click on bootstrap-custom.css, I see the file. Chrome shows used and unused lines of code in green and red, respectively:
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.
Streamlining the Files
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:
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.
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.
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.
Why did this help?
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:
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.
CEO & Founder
Ian Lurie is CEO and founder of Portent. He's recorded training for Lynda.com, writes regularly for the Portent Blog and has been published on AllThingsD, Forbes.com and TechCrunch. Ian speaks at conferences around the world, including SearchLove, MozCon, SIC and ad:Tech. Follow him on Twitter at portentint. He also just published a book about strategy for services businesses: One Trick Ponies Get Shot, available on Kindle. Read More