CSS and JS code coverage in Chrome DevTools
developers.google.com
developers.google.com
It contains around 150 tips which I display as short, animated gifs, so you don't have to read much text to learn how a particular feature works.
Software: Typically Screenflow. It has a built in Gif preset which I'll sometimes use, or if better compression is needed: https://gist.github.com/dergachev/4627207
https://www.cockos.com/licecap/
i don't mean to be snaky, but c'mon: https://www.google.com/search?q=gif+recorder
I've found over the years that emails as notifications get ignored by me, no matter how interested I was at the time of subscription.
https://developers.google.com/web/fundamentals/getting-start...
If you want to influence future content, check out: https://github.com/umaar/dev-tips/issues/27
1. Open the Command Menu with Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux, Chrome OS).
2. Start typing "Screenshots" and select "Capture full size screenshots".
Google's own analytics.js
As far as Google serving files though, its about as optimized as it gets. The JS file is gzip'd, served by Google's cloud network and on chrome it even uses their own QUIC protocol which is faster. It's also likely cached by the sheer amount of usage across the web so it'll probably be the fastest loading thing on your entire site.
Fair point, I think I've been accidentally gamified when it comes to the pagespeed test. Good call.
Things it seems to consider unused: `style` tags, if your CSS rule is on more than one line - the lines for the selector and closing tag.
There should be 0 unused lines since there are 0 unused rules, and the opening and closing `style` tags are DEFINITELY being used, so until these false results get weeded out it will be noisey to try to use this to track down real unused lines.
I believe in your case, these bytes are all whitespace. Here's a basic comparison of two pages where all rules are used: http://imgur.com/ZtfNFmo On the left, we have typical whitespace; On the right: no extra whitespace between style tags and rules. You can see we went from 15 unused bytes to 0.
To be extra clear about this we could somehow indicate these bytes are "unused whitespace" bytes. The implication is a little different in that case, mostly just to use a minifier.
(I work on these tools)
Also in firefox you can screenshot not just the whole page below the fold but screenshot any element by right-clicking the element in the elements pane.
It may one day give Chrome a run for it's money.
I tested several cross-platform browsers in Q1 this year and I always had to go back to Chrome because it's the smoothest dev experience.
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)?
I tried it by triggering function A on page 1 and function B on page 2.
The report showed function A as not used.
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.
At my day job we use app splitting rather than page splitting. Instead of breaking our codebase into individual pages and loading only those files, it's broken into apps. So you might load too much stuff for what you're currently doing, but you're never loading code that's completely unrelated.
A downside to that is that if you hit all our apps in one browsing session, you might download some vendor libraries like 10 times. But it's unlikely that a real user would ever do that.
https://webpack.js.org/plugins/commons-chunk-plugin
It does result in code being loaded when it isn't always needed, but in our case most libraries are used in every app.
That reminds me that I once found 3 versions of jquery (or perhaps jquery-ui, my memory fades) linked from the same page.
One was linked in the master (yes, this was webforms), one was being injected through a user control and the last was written into the page.
All three were all different versions so were all being downloaded. This came to light when a controls stopped working when one version was 'updated'.
In many cases it may not. Remember that you have to fetch data anyway when loading a new page. You could load the new parts of the CSS on the same connection.
The Coverage panel in Chrome 59 is the debut, but it's gotten a lot of improvements since then. In Chrome Beta (or you can always look in Canary), the data is reported live as things happen, and indeed results do aggregate across different page navigations. Which is what you would expect.
Mac and Windows only
My major issue with it is that it doesn't seem to take media queries into consideration. It marked as unused a number of styles wrapped in a min-width that happened to be larger than my browser window. Without automation, it's going to be time-consuming to click through every page of a site and resize the browser window from very small to very large.
_Edited_
Updates are disabled by your administratorGuess I will only be able to comment on these when I get home. The full screen screenshot feature is going to be a welcomed addition. I will especially have to teach it to the BA's since they always want to take screenshots to show to business when design is finished but test is still acting up.
If you do a search for that and 'Chrome' you'll find sites that tell you how to work around the issue.
Chrome has long supported the ability to workaround non-admins the ability to install Chrome (local user directory I believe) so no surprise there's a workaround for this as well.
Personally, I found that the registry key wasn't matching what those say, but Chrome still has that message but will update. Your mileage may vary.
In general, there's no momentum to make a change that the agency doesn't "have" to make, and when the browser finally refuses to transmit forms over HTTP then we want to know about it before the change is deployed to all the users.
As suspected: a typical medium.com page contains approx 75% extra code. Most egregious offenders seem to be content loader scripts like embedly, fonts, unity, youtube, etc.
On the other hand, besides net load performance, I'm not really worrying about the "coverage" metric. Compiling unreal engine via emscripten to build tappy dodo may result in 80%+ unused code, but near native runtime worth is a healthy tradeoff.
Try, for example: http://webassembly.org/demo/
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.
HTTP/1.x definitely has support for this. Not using it actually may get your IP temporarily blocked from many sites.
But it seems to silently forget what happened on the first page as soon as you go to the second page.
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!