Code Coverage Analysis for Better Page Speed

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.

The Test

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

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:

fromthis

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

To this:

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:

Find every line of non-essential code and delete it. Less code is better

Find the CSS required for the first page “paint”

Find the javascript 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:

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:

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:

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:

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:

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:

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.

Ian Lurie is CEO and founder of Portent and the EVP of Marketing Services at Clearlink. He's been a digital marketer since the days of AOL and Compuserve (25 years, if you're counting). He's recorded training for Lynda.com, writes regularly for the Portent Blog and has been published on AllThingsD, Smashing Magazine, and TechCrunch. Ian speaks at conferences around the world, including SearchLove, MozCon, Seattle Interactive Conference and ad:Tech. He has published several books about business and marketing: One Trick Ponies Get Shot, available on Kindle, The Web Marketing All-In-One Desk Reference for Dummies, and Conversation Marketing. Follow him on Twitter at portentint, and on LinkedIn at LinkedIn.com/in/ianlurie.

Comments

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.

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.

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!

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