JavaScript Bundling & Loading

[00:00:00]
>> Evgenii Ray: Also, the HTTP/2+ provides better header compression. If we take the average header size on HTTP/1, which is the 5 kilobytes, on HTTP/2, it's just the 12 bytes, which is 98% more efficient. So look at this line of code. Guess the bundle size for this line of code.

[00:00:23]
And if we try to think how much code will be generated after we compile this code, so for ES5 environment, it's 16.9 kilobyte of JavaScript code because we'll use the polyfills for that. For ES20 bundle, it's just 69 bytes. So you need to be aware of the environment you are trying to compile your application.

[00:00:53]
And if we look at the Core JS size, so it's a 74 kilobytes of minified compressed code. But when it's uncompressed, the JavaScript parser will have to parse the whole 243 kilobytes of the code before you can actually execute your app. So the thing is, there are a few interesting facts about the modern JS.

[00:01:15]
So ES6 already is supported by 98% of the client, while ES7 and 10 has the support of 96%, and ES12, 89%. So basically we are providing the polyfills for a very minority of the clients. And the way how can we try to optimize that is to instruct our JS Compiler to prepare multiple bundles.

[00:01:40]
So it can be ES5 bundle, it can be ES10 bundle, and ES2024, which is the most modern one. So then we can instruct the server, based on the user agent, we can detect what's the browser engine we have. And we can return optimized HTML with the JavaScript assets for this client, so we'll reduce the payload size that the client receives.

[00:02:04]
The next performance optimization technique is the code split. So essentially, we can have our bundle, which is 600 kilobytes, and in HTTP/1 world, this would be the best practice, but now it's anti-pattern. We actually encourage to split the code because it will load faster now. So we can split our code in the separate modules, and we can load the module dynamically and reduce the initial bundle load.

[00:02:35]
We can go even farther and instruct the modules to load in In the background. So, for instance, we know that our application starts with model 1. But in some foreseeable future, we actually know that the model 2 and module 3 will be loaded. So we can instruct the browser using the link element with the rel = "prefetch" value to fetch this asset and cache in the browser cache.

[00:03:07]
So when we access it, we already have this resource. So there are two values that they can use. One is preload, so it's instruct the browser to load such asset under the high priority. And also there is a prefetch which basically loads in the background under the lower priority.

[00:03:24]
And you can play around with that and you can basically prefetch all your JavaScript assets on the background, and when you access the specific module, it will be there and you will not see any loading. The next thing is the code minification and compression, which probably you all use that already.

[00:03:47]
So the minification is just refactoring our code. So this process included in every bundle now. So we're basically removing the longVariableName. We're also refactoring the function names and making the code more compact, so we can reduce on average the size by 20%. So from 1 megabyte, we went to 800 kilobyte.

[00:04:11]
So next is the compression. So the compression, there are two main algorithm that we can use for compression. One is gzip, so it's supported by most of the clients and the browsers and the servers, and also CDNs, and it provides a very good compression rate, around 80%. So also there is a Brotli, which is slightly newer format, and it's 20, 30% more efficient on average.

[00:04:38]
And right now, it's supported by most of the browsers now, and you can also use that on your CDNs. And if we take an example, Lodash library, we'll see that from 530 kilobytes, with Brotli, we went to 73 kilobytes, while with the gzip, we went to 94 kilobytes.

[00:04:59]
So the difference is 4%. But anyway, if we can compress more, why don't we do that?
>> Evgenii Ray: So we applied the compression now, and we went from our 600 kilobyte package to slightly reduced one. And the next thing is to change the order of the script loading. So we can instruct the script to be loaded later.

[00:05:28]
So, for instance, you have some analytics or telemetry scripts that don't really impact the user experience because you load them on the background and you don't, they work, so they don't interact with your runtime code. So you can tell the browser that you need the scripts only once your page is loaded and everything is rendered.

[00:05:52]
So you can use the defer flag. So you will improve your first screen loading, because if you use the normal synchronous loading, then the browser will load the first asset, then the second, then the third, and then the fourth. But since these scripts are kind of optional and our app can function without that, so we can tell the browser that, okay, I don't need the scripts for the first load, defer them, and let's optimize our first screen rendering.

[00:06:21]
>> Evgenii Ray: And here we applied the deferred load to the scripts. And that's it for the JavaScript optimization section.