The Hidden Costs of JavaScript: How to Optimize Your App’s Startup Performance
When you visit a web app for the first time, have you ever wondered what code is being downloaded behind the scenes? The answer might surprise you. From JavaScript libraries like React to custom UI components and third-party scripts, the amount of code being loaded can be staggering. But what does it all mean for your app’s startup performance?
The Slowdown Effect of JavaScript
JavaScript is a costly asset for several reasons. Not only does it take longer to download than smaller files, but it’s also more expensive for the browser to process. Once downloaded and compiled, the browser has to execute it, which can lead to a blank white screen or loading view for an extended period. Even if you’ve server-rendered your app, your JavaScript still needs to be downloaded, parsed, and executed before the user can interact with the page.
The Consequences of Excess JavaScript
For users on mobile phones dealing with occasional connectivity issues, excess JavaScript can pose a real problem. Many developers use powerful laptops on high-speed internet connections, which can obscure performance issues. But for users on lower-end devices with less-powerful CPUs, excess JavaScript can lead to a completely non-responsive app.
Meet Bundle-Wizard: Your New Best Friend
Bundle-wizard is a small tool that helps you answer the question of precisely what JavaScript is being loaded on your users’ browsers. By running the command npx bundle-wizard [site name], you can generate an interactive visualization that allows you to explore the JavaScript loaded by any entry point to your production site.
Unpacking the Visualization
Let’s take a look at an example visualization of the code loaded to display Reddit’s mobile site. We can see two large bundles, divided between custom code and vendor libraries like React. But what really stands out is the amount of unused code being loaded. By clicking on a rectangle, we can see a detail view of the code coverage, which reveals how much of the code was actually run by the page on startup.
Prioritizing Optimizations
As we scout for optimizations, it’s essential to focus on the easy wins first. We can see that some components, like the Register/index.js, are largely untouched on initial page load. This makes sense, but since the component is only 13kb minified, it might not make sense to optimize right away.
Third-Party Scripts: The Hidden Culprits
Bundle-wizard provides the ability to toggle the visibility of all scripts, not just bundles with sourcemaps. This helps us compare the size of third-party scripts, such as analytics and tracking scripts, with the JavaScript module code that was bundled up and sent to the browser. We can see that an ad script takes over as the third-largest JS bundle loaded on the page, with only 17% coverage.
Script Priorities and Long Tasks
When a user loads your site, their browser loads JavaScript files in a certain order based on what it perceives to be the urgency of each request. Bundle-wizard warns us of long tasks it detected on app startup that were initiated by JS script execution. We can use Chrome Devtools to run a performance profile and identify which functions might be contributing to this task time.
Take Control of Your App’s Performance
Give bundle-wizard a spin on your own projects and see what you learn! By understanding what JavaScript is being loaded and how to optimize it, you can take control of your app’s startup performance and provide a better user experience.