The Cost Of JavaScript In 2019 is now available to read.

Building average phone (Moto G4) takes or the ~36s taken by a low-end 2018 phone (Alcatel 1X).

Today we’ll cover some strategies you can use to deliver JavaScript efficiently while still giving users a valuable experience.

tl;dr:

To stay fast, only load JavaScript needed for the current page. Prioritize what a user will need and lazy-load the rest with audit and trim your JavaScript bundles. There’s a high chance you’re HTTP Archive state of JavaScript report, July 2018 highlight the median webpage ships ~350KB of minified and compressed script. These pages take up to 15s to get interactive.
Experiences that ship down this much JavaScript take more than Bringing Facebook.com and the web up to speed”. Sites like Google Sheets are highlighted as shipping up to 5.8MB of script (when decompressed).
We’re hitting this ceiling across both desktop and mobile web, where sites are sometimes shipping multiple megabytes-worth of code that a browser then needs to process. The question to ask is, React, Twitter and Tinder saw anywhere up to a 50% improvement in their Time to Interactive when they adopted aggressive code splitting.
Stacks like Webpack Bundle Analyzer, date-fns).
If you use webpack, you may find our repository of Chrome extension. It gives you an in-depth performance analysis that highlights opportunities to improve performance.

We’ve recently added support for flagging high “PRPL pattern.

PRPL is a performance pattern for efficient loading. It stands for (P)ush critical resources for the initial route, (R)ender initial route, (P)re-cache remaining routes, (L)azy-load and create remaining routes on demand

PRPL (Push, Render, Precache and Lazy-Load) is a pattern for aggressively splitting code for every single route, then taking advantage of a tweet-storm about performance budgets with a few salient points worth noting:

Lighthouse CI project:
Prevent pull requests from being merged if your perf scores fall below a certain value with SpeedCurve:
JavaScript perf budgets for my site teejungle.net using SpeedCurve which supports a range of Long Tasks — an API enabling you to gather real-world telemetry on tasks (and their attributed scripts) that last longer than 50 milliseconds that could block the main thread. You can record these tasks and log them back to your analytics.
Third-party JavaScript if this is currently the primary bottleneck you’re experiencing.
Get fast, stay fast.
Performance is a journey. Many small changes can lead to big gains.
Enable users to interact with your site with the least amount of friction. Run the smallest amount of JavaScript to deliver real value. This can mean taking incremental steps to get there.
In the end, your users will thank you.