4 ms·
200kb image doesn't block rendering, and while somewhat important, it's not the content the user came to see. 30kb might not be much, but this has to be downloa
by mklepaczewski 5y ago
200kb image doesn't block rendering, and while somewhat important, it's not the content the user came to see. 30kb might not be much, but this has to be downloaded, parsed, compiled and executed. These 30kb fight for bandwidth and CPU with other resources or even apps running on the same machine. Sometimes it's fine, but sometimes... Sometimes one component is generated only after another one has loaded, which itself depends on other components, each of which might depend on other resources. It might get pretty bad really quickly. Usage of JS when done right is fine, but it's really easy/convenient/common to do it badly.
- oliwarner 5y agoFor the little it's worth, my 30KB+ full-Vue progressive enhancements don't render block either. It's happening after DOMContentLoaded fires, replacing "real" content with Vue content. And yes, they use more CPU and RAM than -petite. My point there was that a lot of people focus on a bandwidth argument while their sites use [comparatively] massive blobs of media. 3MB bitmap image on their CMS uploaded by Sean in marketing because he doesn't know any better. That sort of thing. Broadly speaking, I don't disagree. There's a lot of truly awful JS out there, wasting cycles doing things that CSS should be handling, but I think the tooling is slowly getting better.
- aeturnum 5y agoI think that package size is a useful gut check about how you're delivering your web app. It's hard to screw up delivering a 100kb package, but it's pretty easy to screw up delivering 5 megs. You can probably also deliver 5 megs in a way that doesn't block anything - but you may not need to devote eng resources to doing that until you reach a certain package size.