The Performance Impact of Generated JavaScript

♪ Hey, everybody. Welcome. Today, we're going to be talking about the performance impact of generated JavaScript. My name is Abhijit. I currently work at Sentry, maintaining our open-source MIT-licensed JavaScript SDKs. And so, these are some of the most used SDKs in the world, and we have a little bit of experience of how people are building apps and using JavaScript.

One of the biggest things that people come to us all the time is that the JavaScript SDK that we give them, especially our front-end browser one, is just way too big. And what I mean by big is by bundle size. It's so large that they're hesitant in loading it in their app. So, now, this is actually a really valid concern and something that we're looking to fix all the time, but it's important to think, okay, why do people keep coming to us about this? This is actually because bundle size is pretty important.

So, it has a direct correlation with how fast it takes to load a page. And so, therefore, it's directly also correlated with your user experience. So, you want to have websites that have fewer loading spinners, that load faster, that feel snappier. All of that directly affects how a user perceives and uses your site. And so, managing your bundle size, having less JavaScript loaded is really important. Now, we know that, okay, this is something that people want to reduce. So, how do people typically reduce their bundle size? Well, so, usually, you take a look at the code you write and use. This means that you're analyzing whatever you're adding to your app and you're determining if it's important or not.

So, typically, this will be like using smaller alternate libraries. For example, switching from React to Preact, lazy loading your JavaScript so that you're only loading exactly what you need. And whenever you happen to use a component or some other logic, you lazy load it. Or you remove JavaScript altogether and you try to eliminate the usage of it from your app. The most common scenario for this is, for example, moving from client-side rendering your application to server-side rendering it. But an important theme here is that these are all strategies for the code you write. But the code you write is not actually the code that runs on the browser, is it?

In modern JavaScript apps, this is completely different. In modern JavaScript apps, the user runs generated JavaScript. This means you need to look at and understand the generated JavaScript to improve your bundle size, not just the JavaScript that you wrote. Now, what do I mean by generated JavaScript? I brought it up a couple of times now as we've talked together. I mean via a build process. We've talked together. I mean via a build process. For most modern JavaScript stacks, whether you're client-side rendered or server-side rendered with a framework like Next.js, Nuxt or SvelteKit, you take some input JavaScript and TypeScript, pass it into a bundler like Veet, Webpack, Rollup, and you get some JavaScript at the end. Using a build process is really useful. You can tree shake out unused JavaScript, transpile from TypeScript to JavaScript, support older browsers via injecting polyfills or down compiling out and down compiling older browser APIs, and you can inject logic at build time, which is super useful for statically built sites. Everybody pretty much uses a build process at this point. You're probably using Veet or Webpack or one of those things under the hood now. So with that in mind, everyone's using a build process. You can go no build, but everybody running huge, big apps are running build processes. And so there's a lot of improvement that we can take with how builds generate JavaScript. Here we have five main areas of improvement. Minification, down compilation, transpilation, compression, and tree shaking. We're going to be skipping tree shaking this time, but I'll touch upon it briefly at the end. So first is minification, which is a process of making your JavaScript assets as small as possible, typically by removing unnecessary tokens and shortening variable or function names. So you can see here is an example. On the left, we go from a JavaScript function that has an object inside of it, and we minified it down, removing comments, white space, shortening names whenever possible. The tricky thing with minification and where the optimization part comes in is that not everything can be minified or shortened. You cannot minify reserved keywords like typeof, function, return. You can't minify object keys because they're needed to do lookups on our object.

Otherwise, you can't do lookups. And you can't minify class methods because you have to call the methods by their name. And so if you shorten them, they no longer work. This actually means that API design matters a lot, and how you design your programs so that they can be minified more easily can affect your bundle size a lot.

Here's an example of the class methods. On the left is an example API class, something actually we used to use in the Sentry SDK, but I de-Sentryfied it a lot. And on the right here is a minified version. I prettified it so that we kept white space so that it's easier to read. And you can actually see that in the minified version, a lot of the names still state because all of these class methods can't get minified. They're part of the public API of this API class. Even things that we consider private like encoded auth still doesn't get minimized because of how JavaScript works.

So, what are some strategies so we can write more minification-friendly code? Well, first of all, try to avoid deeply nested object lookups and builder patterns. On the left here, you can see that we have this complicated lookup on event.exception.values.type. And we want to make sure that everything exists properly so we do this Boolean operation. But all of these values, exception.values.type, and of course the SentryError here, are completely unminifiable. And so we end up with a lot of redundant information in our bundle. Given that we're already using a try catch, we can just shorten this to a single line. And if we hit a type error, it'll hit the catch block instead.

Another way to write more minification-friendly code is to use config to mangle based on regex. So, for example, if we go back to the class methods example here, if we say, hey, everything that starts with the underscore should be minified, we can suddenly now minify encoded auth and all of its usages here. Most bundlers have config that allow you to set up custom mangling based on some regular expression. Lastly, and this is where the API design component comes in, you can use functions and objects instead of classes. And this means classes, of course, they have their whole public API and every method, public method, can't be minified. But if you use functions and objects, function names can be minified because they're just simply top-level methods and all they care about is where they're called and what they're called with. Even better than objects, because, again, object keys can't be minified, is actually using arrays. So if you have some internal data structure that you know is commonly used, then perhaps making an array instead of an object. React hooks actually does this really well. Things like useState and useReducer return an array. So that these structured array arguments can actually be minified by a bundler. A great example of comparing minification-friendly libraries is Zod versus ValleyBot.

So Zod is a really popular schema validation library. ValleyBot is kind of a competitor for this. And you can actually see the two different approaches in API design. For Zod, you have this builder pattern where you can actually notice here that string, email, and endsWith is chained from this zexport, and these chained methods cannot be minified. And so you end up with all of these in your bundle. And if you're using Zod a lot and it's spread around everywhere, then that adds up over time. Meanwhile, for ValleyBot, these are just top-level functions exported. And so therefore all of these functions, string, email, and endsWith in the ValleyBot example will be minified. Requires this kind of like top-level API design change, but suddenly you have a much more minification, bundle size-friendly library.

Next, let's think about down-compilation. Down-compilation is a process of converting source code to a more backwards-compatible version of that source code. Unfortunately, more backwards-compatible JavaScript can be bigger. Let's say you need to target IE11. And so you're emitting ES5-compatible JavaScript. This means actually there's no classes because ES5 didn't have classes yet. That's an ES6 feature. And so you might have to polyfill those out or down-compile them to have alternate JavaScript. A great example of this is optional chaining. So on the very left here, you can see the optional chaining feature, which allows you to kind of do deeply nested lookups on objects. But if you target something older than ES2020, which is when optional chaining came out, and you want to support more browsers than that, you'll end up down-compiling your JavaScript and your optional chaining to something that looks like this. This is super expensive. And you can imagine if you use optional chaining a lot, especially if this was some big, huge nested statement, you would have a ton of conditionals in here. Instead, especially if you use TypeScript, you can probably just replace this with a simple Boolean assertion, which is what we do in our Sentry SDK codebase. We actually lint against using optional chaining and force everybody to use Boolean conditions instead. So the biggest thing for this is to really look at how your JavaScript is getting generated and make sure that nothing looks strange, nothing looks off, and disallow patterns that down-compile not well because you need to support more browsers. For polyfills, because sometimes a lot of people just start injecting them unnecessarily, just take a look and see what you're bundling and update your browsers list or use modern bundlers. Please don't use Webpack 4 anymore.

Next, we have transpilation. This is the process of converting source code from one language to another. We used to have a lot of these, CoffeeScript, BuckleScript, ReasonML, things like that.

But nowadays, this pretty much means TypeScript and JavaScript to the average front-end developer. For what it's worth, the TypeScript transpiler is pretty good. But one thing to note is that TypeScript enums are pretty expensive, and I recommend not using them. On the left, we have an enum. Looks pretty simple, but on the right, we can see what this generates. And this is because enums allow reverse lookups. This is really expensive, and oftentimes, just the enum values cannot be minified at all, too. And so there's a double whammy there. It's pretty much easier just to not use them, use string constants and do enums that way. Strings also have the benefit of compressing really well.

Compression is the last thing that we can talk about here. The browser automatically uncompresses compressed JavaScript assets, also CSS and other fonts, that are compressed with gzip, Brotli, or deflate. And so therefore, you should always be, alongside minifying your code, compressing it for big savings while users have to load your resources over the network. What ends up happening is, though, that repeated strings or code compress really well because the increased similarity helps with gzip and Brotli algorithms. So for example here, if we had to switch this enum to repeated string constants, that would actually improve its gzipability. gzip and the other compression algorithms, though, can be a little bit of a black box. It's confusing. And so the biggest recommendation here is, as you're examining your bundle and trying to fix your polyfills, your down compilation, and your minification strategies, test your changes against whatever is gzipped. And if you're not already doing it, please compress your JavaScript before you're sending it to your users.

So we covered a lot of ground, but there's a lot more to take a look. Really the best way to start exploring and to start investigating is to read more generated JavaScript. Get comfortable with reading minified code and see what is actually emitted from your build processes. Sometimes if you take a look, you can find some really great quick wins. In general, though, please start tracking your bundle size. I've been to many different conferences by now and I always ask this question. How many of you are tracking your bundle size? And the answer is disappointingly low. I recommend using CodeCub bundle size. You can track it over time. It'll also give you a PR comment. But I'm a little biased because I helped build it.

A great alternative is the size limit action. This is what we use in the Sentry SDK. It'll leave a PR comment on GitHub that basically says, oh, this was the previous bundle size and this is the new bundle size and here's what's changed. If you want to dive in and you just don't want to only read the generated JavaScript, then I recommend you use bundle analyzers for your bundlers. There's a Webpack one, the Rollup one, which also works for Vite. These are really great ways to also visually see how your bundles, what's in your bundle and the connections between different components.