I have to admit that I haven't paid much attention to Chrome's Developer Tools and don't spend as much time as I used to (time management choices...) dissecting websites, however I did take a little spin about today because of Ian Lurie's Code Coverage Analysis for Better Page Speed 30-October-2017 article on the Portent blog. Not because I'm all that interested in the tool(s) but because he raises the spectre of dead code (on the day before All Hallow's, no less) bogging time between connection and render.
The more that people use frameworks, i.e. WordPress, Bootstrap, Angular, React, apis.google, the more they are likely to NOT be using everything being sent to a visitor but still consuming their bandwidth and taking time, valuable time.
Chrome's DevTool's Coverage tool is actually quite useful. I recommend giving it a spin, after reading Ian's article.
“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.
He then proceeds to do what should be a standard best practice:
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?
How far you go cleaning out and separating code depends on requirements and obsessiveness; years ago I went from separating to template only to then separating by page to now separating also by device capacity (part of serving on context) with the end goal of never sending the visitor any code not necessary for best experience on their device. That last bit of finesse is still somewhat a work in progress as I do err on the side of more rather than less when in doubt. But every byte saved is n-millisecond shaved.