Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more.
In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles.
Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure.
Super specific and super practical!
Surprisingly, Addy mentions that “the median webpage today currently ships about 350KB of minified and compressed JavaScript,” which seems like an awful lot lower than I’d expected, if I'm being honest. The stat that scares me most is that the median webpage takes around fifteen whole seconds until it’s interactive. And pulling all that JS into a Web Worker or caching with Service Workers won't even make up that time to interaction. Yikes.
Another key point: not all bytes are equal. For example, 200KB of JavaScript is not equal to a 200KB JPG image file:
A JPEG image needs to be decoded, rasterized, and painted on the screen. A JavaScript bundle needs to be downloaded and then parsed, compiled, executed —and there are a number of other steps that an engine needs to complete. Just be aware that these costs are not quite equivalent.
Direct Link to Article — Permalink
The post The Cost of JavaScript in 2018 appeared first on CSS-Tricks.
from CSS-Tricks https://ift.tt/2LNYuly
via IFTTT
No comments:
Post a Comment