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.