|New Host (nginx)||Old Host (s3)|
|Mean: 8.18||Mean: 44.96|
|Total speedup:||over 5x faster!|
And so, we see the value of compressing content for highly repetitive files such as those produced by the ClojureScript compiler.
In the past, I hadn't noticed compression making much of a difference for cljs projects. I have a hunch that's because unlike 90%+ of cljs projects, cljsfiddle cannot use advanced compilation mode because it needs to load the cljs-in-cljs bootstrapped clojurescript compiler.
Everyone knows zipping a file tends to make it smaller. Compression works by looking at a sequence (let's say of characters), and assigning long, frequently repetitive sequences in that string to shorter keys. The longer and more repetitive a substring is, the shorter its key should be. In this way a compression algorithm builds a legend from short symbol -> long symbol. Having one large file makes compression easier because instead of many small (and in the case of code, certainly redundant) legends, we can have a larger legend that only needs to do its work once.
We build the legend
1=AAAB. In our imaginary naive compression algorithm, we include the legend first, then a
|, then the data itself. So:
compress(example1) => 1=AAAB|1111 compress(example2) => 1=AAAB|11 and 1=AAAB|11
The length of compressed example1 is: 11. The length of compressed example two is: 18!! So we can see how having a larger, concatenated file helps with compression.
The clojurescript compiler's
:whitespace mode allows us to do exactly that.
So, with a larger file to compress, let's see what the gains are like:
|(old build) No Optimization||(new build) Whitespace Optimization|
|Total speedup:||over 7x faster than s3!|
So, even though we don't download the app.js file in parallel, we still save bandwidth and decrease load times.
For contributions such as updating cljs to use
:whitespace mode, and changes to the way we call bootstrapped compiler, and pointing out that gzip wasn't actually enabled on nginx!