In this post I take a closer look at performance optimizations from using the Closure compiler to bundle Svelte applications.
This article is a follow up to my previous article about Svelte and the Closure compiler, so I recommend reading the other article first if you are new to the Closure compiler.
Demo Application
For the purposes of this demo I have decided to make things interesting by mixing Svelte with the HttpClient service from Angular. Perhaps a contrived use case, but the Angular Http implementation could be interesting to some since it’s a really good RxJs based http implementation.
One obvious concern from bringing in a feature from another framework is that it may bring in a whole host of extra dependencies. Next, let’s see how this impacts the size and performance of my Svelte application.
Here is a link to the deployed application in case you want to take a look.
Rollup Baseline
As a baseline I have included the Angular HttpClient in a standard Svelte application bundled using Rollup and Terser. The Svelte app is pretty small, but importing Angular’s HttpClient inflates the size of the application to 139kb (49.5kb gzipped).
Closure Compiler
You generally expect a noticeable reduction in bundle size from using Closure, but in this case the difference is huge. Closure compiler reduced the size of the application to 34.6kb (14.3kb gzipped), which is a 71.1% decrease in compressed payload size.
Why is there such a big difference in bundle size?
In my previous article I discuss some of the amazing optimizations offered by Closure, but to help visualize the differences, I have added source map explorer maps to my demo. As you can see from the maps, Closure compiler did a much better job trimming down unused dependencies in both Angular and RxJs. In fact at 14.3kb one could argue that using Angular’s HttpClient is actually a viable option if you need an RxJs based http client. At ~50kb it’s probably too much overhead considering you’re just getting an http client.
Performance
One obvious performance benefit from the reduction in payload size is a faster download time, especially on slow mobile network connections. However, there could be other runtime benefits as well. To measure performance differences, I have run both versions through performance testing using WebPageTest and Lighthouse. Both experiments are run using Android Moto G4 - a middle of the road Android phone.
Lighthouse
The Lighthouse test shows a fairly consistent time to interactive of 0.8s and 1.3s for Closure and Rollup respectively (38.5% decrease). In case you are wondering, time to interactive is a measure of how long it takes for a site to become fully interactive.
Lighthouse doesn’t really offer any suggestions for improving performance in the Closure example, but does highlight several unused Angular modules in the Rollup bundle.
WebPageTest
WebPageTest is a really helpful online tool for running detailed performance analysis of web applications. One interesting metric in this case is the time spent dealing with JavaScript on the page from parsing, compilation and execution. In the Rollup version the total time spent is 113ms, but the smaller Closure version spends only 70ms dealing with JavaScript. Out of the total, JavaScript compilation is 49.5ms and 14.5ms for Rollup and Closure respectively. A shorter compilation time in Closure is not unexpected since there is less JavaScript to compile.