Live data from Hacker News

CSS and JS code coverage in Chrome DevTools

developers.google.com

11–20 of 130 posts

Re: CSS and JS code coverage in Chrome DevTools

#14
My vague recollection of the Google event where this was first announced (was it late 2016 or early 2017?) - was it was going to "record" your site usage for as long as you were "recording" - and give the report at the end.

But this now sounds like a coverage tool for a single page?

Does anyone know if it can record over multiple pages and/or application usage (such as an SPA)?

Re: CSS and JS code coverage in Chrome DevTools

#15
post #9
post #3

Earlier quoted context omitted.

Not that I don't appreciate the efforts that they put in to helping developers--and I'm sure this is for the single-page PWA crowd--but CSS and JS is far more complicated than looking at a single page (especially for big organisations).

If it's not for this page, then why are you loading it? Load it when the user goes to that other page. That's the idea behind bundle splitting and whatnot. Don't send users code they don't need yet. Most of them are never going to get to the part of the page that does need that code.

Depending on what you are loading it may be more efficient to bundle everything in one file. If you are only loading a few kb per page, the overhead and extra time required for the network requests mean it's probably not worth splitting code.

Re: CSS and JS code coverage in Chrome DevTools

#16
Excellent timing, I had given up finding a good tool for coverage on JS and CSS and where right now using audits in Chrome trying to find unused CSS and searching through the code to find unused JS on our landing page. Even if it is hard for at tool to find everything that is unused on a page it will show what is used so we know what we don't have to check in the code

Re: CSS and JS code coverage in Chrome DevTools

#18

What happened with shipping everything in a single file and letting cache magic happen?

HTTP/2 happened. HTTP/2 allows you to send HTTP requests over a single TCP connection per domain. Headers are compressed. The request overhead is minimal compared to HTTP/1.x.

Caching one big file has the draw back of busting the cache each time the file is updated for any small change.

Caching multiple small files allows you to have a finer grain cache. Only bust the things that updated. And, since it's all the same TCP connection it's now performant to load this way.

Re: CSS and JS code coverage in Chrome DevTools

#20
post #12

Can this be useful when someone uses webpack?

Why would it be any different if they weren't? Unused code is unused code.

Webpack bundles everything up into one huge .js file, I gotta try how it works with that.

Plus in my current environment (ReactJS + TypeScript + MobX + Webpack) tslint generates errors when I have unused variables and that breaks TeamCity build.

No matter what, this tool is super useful!

Post reply on HN