Is Javascript Compressor Really Useful?

K

kkkk

from: http://blog.codexpress.cn/javascript/is-javascript-compressor-really-useful/
Does javascript compressor save bandwidth and speed up page load time?
Many developers tend to believe it, but it is probably not the truth.
Nowadays, most mainstream browser and web servers support gzip
deflate. Usually your browser does not have to deal with javascript
text-files directly. Instead, gzipped data are handled between server
and browsers. So I just used gzip to see how much javascript
compressor can reduce file size and load time. Testing file is
Prototype 1.5.1.1; three popular compressor - Dean Edwards' Javascript
Compressor, Dojo ShrinkSafe and MemTronic's HTML/JavaScript Cruncher &
Compressor took this test. The table below shows the result:

Origina Dean Edwards'
ShrinkSafe MemTronic's
file size(kb) 94.0 39.2
64.5 40.4 *
gzipped size(kb) 20.6 16.7
18.4 20.4

* MemTronic's HTML/JavaScript Cruncher & Compressor produce files
containing non-ASCII characters, so I had to save it in UTF-8 format,
which increased the file size.

The biggest difference in file size is less than 4kb. If you are using
a 56k modem, it will take almost a second on average. But this happens
only you first load the page, otherwise the script will be cached by
the browser. However, a compressed javascript file, having no obvious
advantage in file size, will decompress itself each time the page
loads. I don't have an accurate method to evaluate how long it will
take. Even the time for decompressing can be ignored, it will surely
make your CPU occupation a little higher.

Does javascript compressor protect your script source?
Probably not. Compressed scripts need to decompress by themselves.
There always exists "eval()" function to execute the original script.
Just changing "eval" to "document.write", all secrets reveal. A
javascript formatter may be used to get formatted codes. After a few
manual corrections, the compressed script will be perfect for
analyzing and hacking, except that all comments were removed. This
trick usually works.

Obfuscators like Dojo ShrinkSafe will make variable/function names
unreadable. That's the true protection, but it is not always safe.
Some scripts fails to work after the replacement.
 
A

asdf

You managed to have implemented a nice font.

I may adopt it to overwrite the present
on my machine aka open source "Andale Mono".
 
D

David Mark

from:http://blog.codexpress.cn/javascript/is-javascript-compressor-really-...
Does javascript compressor save bandwidth and speed up page load time?
Many developers tend to believe it, but it is probably not the truth.

Yes, HTTP compression can speed up script downloads.
Nowadays, most mainstream browser and web servers support gzip
deflate. Usually your browser does not have to deal with javascript
text-files directly. Instead, gzipped data are handled between server
and browsers. So I just used gzip to see how much javascript

Don't manually gzip JS files. Let the server handle that and the
content negotiation that goes with it.
compressor can reduce file size and load time. Testing file is
Prototype 1.5.1.1; three popular compressor - Dean Edwards' Javascript
Compressor, Dojo ShrinkSafe and MemTronic's HTML/JavaScript Cruncher &

I can only comment on ShrinkSafe and it has nothing to do with gzip
compression. It uses a combination of minification and obfuscation.
Compressor took this test. The table below shows the result:

Origina Dean Edwards'
ShrinkSafe MemTronic's
file size(kb) 94.0 39.2
64.5 40.4 *
gzipped size(kb) 20.6 16.7
18.4 20.4

* MemTronic's HTML/JavaScript Cruncher & Compressor produce files
containing non-ASCII characters, so I had to save it in UTF-8 format,
which increased the file size.

The biggest difference in file size is less than 4kb. If you are using

Your mileage will vary from one file to another. Regardless, I don't
understand what your chart means or where you are getting the 4KB
figure.

[snip]
Does javascript compressor protect your script source?

Protect it from whom?
Probably not. Compressed scripts need to decompress by themselves.
There always exists "eval()" function to execute the original script.

That's encryption not compression. And ShrinkSafe does not do
encryption. And no, encryption will not stop people from copying your
source. It keeps the "honest" people honest, but such people don't
want your source anyway.

[snip]
Obfuscators like Dojo ShrinkSafe will make variable/function names
unreadable. That's the true protection, but it is not always safe.

Again, protection from whom? As for safe, ShrinkSafe has worked well
for me.
Some scripts fails to work after the replacement.

I suppose anything's possible. I can't imagine any of the listed
tools are perfect.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Staff online

Members online

Forum statistics

Threads
473,992
Messages
2,570,220
Members
46,805
Latest member
ClydeHeld1

Latest Threads

Top