Earlier quoted context omitted.
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.
> it may be more efficient 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.
CSS and JS code coverage in Chrome DevTools
41–50 of 130 posts
Re: CSS and JS code coverage in Chrome DevTools
#42So I recorded my site for a while. Then sorted by unused bytes. What was on top? Google's own analytics.js
Re: CSS and JS code coverage in Chrome DevTools
#43It'd be awesome if there was a button to download a file with the code that's used, and the code that's unused, instead of just having a diff. Hint hint :)
Re: CSS and JS code coverage in Chrome DevTools
#44Earlier quoted context omitted.
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.
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.
Re: CSS and JS code coverage in Chrome DevTools
#45Things 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.
Re: CSS and JS code coverage in Chrome DevTools
#46From the same link, being able to take a full page screenshot (as in, below the fold) is also very excellent. I notice from the YouTube page description there is a further shortcut: 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". I needed this literally yesterday, when I used MS Paint to cut a…
Re: CSS and JS code coverage in Chrome DevTools
#47Earlier quoted context omitted.
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!
Re: CSS and JS code coverage in Chrome DevTools
#48Chrome Dev tools, the first reason why I started using Chrome. I wonder if HN has any better alternatives to suggest? I'm curious to see what I could be missing on!
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.
Re: CSS and JS code coverage in Chrome DevTools
#49Chrome Dev tools, the first reason why I started using Chrome. I wonder if HN has any better alternatives to suggest? I'm curious to see what I could be missing on!
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.