25

I've noticed that every time I use Google's Closure Compiler Service, it leaves a few unnecessary spaces in the compiled code presented on the right-hand side of the page. These correspond to line breaks in the hosted version of the compiled code.

For example (note the line breaks, each of which seems unnecessary):

http://troy.onespot.com/static/stack_overflow/closure_spaces.js

To date, I've just been removing them manually, but I'm curious why they're there. Is it to limit the line length of the hosted version of the code to make it more readable? Could the compiler be smart enough to leave or insert those intentionally to maximize GZIP compression efforts?

I know that they have a trivial effect on the file size, but with so much effort going into minifying every last byte in the source script, it's counterintuitive why they're there.

Bungle
  • 19,392
  • 24
  • 79
  • 106
  • I can't access that [default.js](http://closure-compiler.appspot.com/code/jsc39ddc01a5a74a754148a33d2d8f1444/default.js), the link returns a page with a ‘Content-Length’ of 0. Can you paste (part of) the code in your question? – Marcel Korpel Jun 10 '10 at 21:06
  • Sorry about that - I assumed that Google hosted the compiled code indefinitely, but apparently they don't. I updated the link in the question above. – Bungle Jun 10 '10 at 23:21
  • The craziest thing is Google PageSpeed Insights complain about a few bytes (<1KB) and when I download the optimized files, the js has 180K long lines, but there is no way to instruct the Closure compiler (API or JAVA Application) to break lines at any length (eg 180K) – Jose Nobile Mar 06 '16 at 03:14

1 Answers1

40

Quoting the Closure Compiler FAQ:

Why are there random line feeds in compiled scripts?

The Closure Compiler intentionally adds line breaks every 500 characters or so. Firewalls and proxies sometimes corrupt or ignore large JavaScript files with very long lines. Adding line breaks every 500 characters prevents this problem. Removing the line breaks has no effect on a script's semantics. The impact on code size is small, and the Compiler optimizes line break placement so that the code size penalty is even smaller when files are gzipped.

You knew it was smart! :)

Community
  • 1
  • 1
Daniel Vassallo
  • 337,827
  • 72
  • 505
  • 443
  • 1
    Awesome, that solves it! I hadn't seen the FAQ - thanks for the link, and I appreciate the answer. – Bungle Jun 11 '10 at 10:30
  • The craziest thing is Google PageSpeed Insights complain about a few bytes (<1KB) and when I download the optimized files, the js has 180K long lines, but there is no way to instruct the Closure compiler (API or JAVA Application) to break lines at any length (eg 180K) – Jose Nobile Mar 06 '16 at 03:14
  • 1
    @JoseNobile I faced recently this linebreak issue with Java application. I worked around it bt removing manually line breaks introduced by the closure compiler. – Stephan Jul 30 '17 at 07:46
  • Although firewalls or proxies MAYBE ignore or corrupt files with lengthy lines, you can find many minified js and css files that contain lengthy lines, and everything looks file. For instance, the minified css of Bootstrap 4.5.3 contains 7 lines and 6th includes about 160k characters. – Elyas Hadizadeh Jul 12 '21 at 05:52
  • @ElyasHadizadeh agree, I wonder if this is a thing of the past -- considering how much minified JS code that is out there and web browsing has been fine, I don't think this is necessary in 2023 – Zhe Aug 09 '23 at 14:59