How to analyze Closure Compiler bundle size

Question

I have an app in ClojureScript, which uses Google's Closure Compiler as a compiler backend. The resulting bundle using advanced optimizations seems way too big for what it is. I blame the dependencies but how do I find out which modules are taking the most bytes in the output bundle? I scanned through all the Closure Compiler options and didn't find anything useful. Then I tried to learn about source maps and use that to calculate individual module size but with no success.

I would like a tree-like output where I can dig in and find the biggest modules in terms of size, eg.

• [+] goog 100kb
  • [+] goog.net 30kb
• [+] react 90kb
• [+] my 50kb
  • [+] my.namespace 30kb

Quaquaversal

Answer 1

shadow-cljs can generate Build Reports which take the advanced compiled output and analyze the source maps and then combines it with some of the compiler information to group sources by artifact and so on. The report is generated as a standalone .html file.

A sample build report can be found here. The build included "antd" package from npm. A comparison report that just included "antd/es/button" can be found here.

Note that this is limited to shadow-cljs as it relies on having all source map data available. Analyzing the source maps of CLJS builds generated by other tools misses source maps for all CLJSJS content and thus will include a lot of "gaps".

Palacio

Could you specify what exactly is "some of the compiler information"? I'm not familiar with shadow-cljs but I assume it uses cljs.build.api and thus uses the same compiler options, and I don't see any that would provide me some extra insight. Also, it would be cool if you could name some other build tools that don't fully propagate source map data and why? I'm not keen to switch build systems but I'd like to have that build report :) – Quaquaversal

shadow-cljs interfaces pretty tightly with the CLJS and Closure Compiler so it has way more data than cljs.build.api exposes. Anything using CLJSJS won't have accurate source map data since those packages do not contain any source maps. shadow-cljs does not use CLJSJS and instead accesses npm packages directly and generates source map data when processing them. – Palacio

Answer 2

To my knowledge, such a tool does not exist. It would be an excellent one to have though.

The tool need not be specific to Closure Compiler. Instead, analyzing the output source map could attribute specific symbols in the code to specific input files.

Andiron

I was able to use github.com/danvk/source-map-explorer to get some results, but there's a rather big part of the bundle that it cannot map to any symbol. I think a proper solution would be a feature request for Closure Compiler. – Quaquaversal

I think the unmapped bytes belong to the preamble and extern files, eg. React.js when using reagent. – Quaquaversal

The extern files should not be in the bundle. What size is it? Are you looking for 10K or 200K? If it is under 40K, perhaps the unmapped bytes are just the injected polyfills? Try setting the language_out=ECMASCRIPT_2017. – Thistle