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?!!”

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.

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

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

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:

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

To this:

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

Using the Report

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

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!

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

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:

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.

The post Code Coverage Analysis for Better Page Speed appeared first on Portent.

from Conversation Marketing: Internet Marketing with a Twist of Lemon http://ift.tt/2xzXqq3
via IFTTT