Performance gains from switching to Closure Compiler
On the Office Online team, we’re constantly looking for ways to improve the boot times of our applications. One of the factors that directly impacts the time it takes for these applications to boot is the raw size of the JavaScript files required to boot the page and provide basic editing functionality. By reducing the overall size of our critical JavaScript files, we can reduce the amount of time the browser spends downloading and parsing code.
One way we’ve achieved this is by minifying all the JavaScript we send down to the browser. At first we used Microsoft’s Ajax Minifier, which reduces the size of JavaScript files by performing optimizations such as removing whitespace and renaming local variables to have shorter names. We then implemented a tool that would leverage knowledge of the entire application to rename functions and remove unused functions from the output JavaScript. This tool worked well for many years, but it was tightly coupled to our internal build system and eventually was no longer being actively maintained. This caused us to look to the open source community for a more modern solution for JavaScript minification.
We recently replaced our internal minification tool with Closure Compiler. Like our previous minification tool, Closure Compiler in Advanced Mode supports global function renaming and dead code removal. It also has additional features like function inlining and dynamic moving of code between JavaScript files. When running our JavaScript code through Closure Compiler, the size of our main JavaScript file after Gzip compression was 15% smaller than it was with our old minification tool. We found that most of these file size savings came from the compiler’s ability to move code from our main JavaScript file into one of our “delay-loaded” JavaScript files that were also fed as inputs to the compiler.
The JavaScript download time isn’t the only factor that contributes to the boot time of our applications. The browser also needs to parse the JavaScript, run our app initialization code, and render content once available. To get a better understanding of how these file size reductions would translate into boot time improvements, we ran a controlled A/B test in production for Word Online users. In the control group of this experiment, users were served JavaScript files that come from our old minification pipeline. In the treatment group, users saw JavaScript files that were minified with Closure Compiler. Our experiment showed that there was an 8% improvement in boot time across all browsers. We also saw that the “gap to interactive”, which measures the time between the document being visible to the user to the time it is editable, improved by 14% across all browsers.
After analyzing the results of this experiment in Word Online, we started moving other Office Online applications to also use Closure Compiler and saw similar performance improvements. We also did some work to make our JavaScript exception logging code compatible with Closure Compiler by creating a tool that turns minified method names in a stack trace back into their human readable form. For more info on that, check out this blog post.
