3 ms·

In my tests on my companys code base Closure Compiler wasn't worth it. It did however save a few kilobytes - after gzip - but took around 3-4X longer to run (m

In my tests on my companys code base Closure Compiler wasn't worth it. It did however save a few kilobytes - after gzip - but took around 3-4X longer to run (much worse if you use their JS implementation for Webpack) If time to build is not an issue for you, and you're ok with the java dependency, then it might be worthwhile.

andrewingram 10y ago
What about parse time? This is arguably an equally important metric. Make sure throttle CPU and network to simulate a budget smartphone when you test.
- indolering 10y ago
  If you have customers on ancient smartphones and the engineering budget to manage the complexity ... go for it! :D
  - andrewingram 10y ago
    We're not talking ancient here. The mobile test on Webpagetest (https://www.webpagetest.org/easy https://www.webpagetest.org/easy) uses a Moto G4, which is less than a year old. But this test is punishingly brutal on most JavaScript-heavy websites. If you can make wins on parse time, you absolutely need to be pursuing them.
    - abritinthebay 10y ago
      Most JavaScript heavy sites in the real world are that way due to 3rd party ad code (sad fact of the modern web) and Closure Compiler won't affect those
- abritinthebay 10y ago
  Again, only based on my codebase, it was better but in the same way it was better on post gzip size: by not a lot. I'm sure in other specific cases it may be a lot better. Just not in mine.
indolering 10y ago
Exactly, when comparing the size after gzip compression, minifcation itself is often not worth the hassle. To get any serious benefit out of Closure Compiler you have to annotate your source code, not use certain conventions, and generally worry about things breaking. That's probably just fine when you are transpiling (i.e. Google Web Toolkit) but its a PITA for everyone else.

3 ms·

In my tests on my companys code base Closure Compiler wasn't worth it. It did however save a few kilobytes - after gzip - but took around 3-4X longer to run (m

by abritinthebay 10y ago

andrewingram 10y ago
What about parse time? This is arguably an equally important metric. Make sure throttle CPU and network to simulate a budget smartphone when you test.
- indolering 10y ago
  If you have customers on ancient smartphones and the engineering budget to manage the complexity ... go for it! :D
  - andrewingram 10y ago
    We're not talking ancient here. The mobile test on Webpagetest (https://www.webpagetest.org/easy https://www.webpagetest.org/easy) uses a Moto G4, which is less than a year old. But this test is punishingly brutal on most JavaScript-heavy websites. If you can make wins on parse time, you absolutely need to be pursuing them.
    - abritinthebay 10y ago
      Most JavaScript heavy sites in the real world are that way due to 3rd party ad code (sad fact of the modern web) and Closure Compiler won't affect those
- abritinthebay 10y ago
  Again, only based on my codebase, it was better but in the same way it was better on post gzip size: by not a lot. I'm sure in other specific cases it may be a lot better. Just not in mine.
indolering 10y ago
Exactly, when comparing the size after gzip compression, minifcation itself is often not worth the hassle. To get any serious benefit out of Closure Compiler you have to annotate your source code, not use certain conventions, and generally worry about things breaking. That's probably just fine when you are transpiling (i.e. Google Web Toolkit) but its a PITA for everyone else.