I recently talked about the State Of JavaScript on the State Of The Web show. Yes, I'm a one-trick pony... 😃
On the client, as you pay for things you can't always easily see it becomes important to understand how the cost of JavaScript might impact your site.
How do I tackle these problems?
- Start off with Lighthouse 💡🏠
- Check how well your site performs on some real phones. There are a number of these setup on WebPageTest. If your team can afford them, a local device lab is always useful too 📱
- If JavaScript is impacting your metrics, it's probably time to analyze why. I regularly use source-map-explorer, webpack-bundle-analyzer and bundlephobia to discover opportunities to trim down my bundles.
- I use the DevTools code-coverage highlights bundle weight-loss opportunities.
- Try to leverage code-splitting patterns. Got a large vendor bundle? Maybe only a few of those dependencies are needed for the initial page load. Large app bundle? Is all that logic really needed right away? Libraries like React are starting to get better at supporting code-splitting out of the box (see React.lazy()).
- Consider using babel-preset-env to generate bundles for modern vs legacy browsers. The module/nomodule pattern allows you to serve these in a backwards compatible way.
- Leverage compression techniques. I've been suggesting teams try out Brotli for static asset compression. In my own apps, I've seen a 20-30% decrease in bundle size over the wire for JS. If you're a Node shop, shrink-ray or shrink-ray-current are solid middlewares for serving Brotli that I've found work reliably.
Top comments (4)
I hope we never forget how degrading the experience used to be in the 90’s. Most of us had no choice but to think about peformance. I guess server side generated pages probably made that much easier to manage.
I’m curious if you’ve thought about integrating Babel into the browser given that it might always be a few steps ahead? Would it make sense to let developers use some of the proposed features in the browser without the need for transpiling code (which might reduce the payload further)? Thanks!
There should be a history lesson on the pre-jquery era. With ERPs in the 90s, we had no choice but to figure out how to lazy load 30mb of bloated xml to the browser.
I would also say actually learn JavaScript and what the JS frameworks/libraries are doing under the hood.
Thanks for all the pointers!
ps. is that a firefox on your shirt? :D