Minimizing your JavaScript Code

Avatar von Stefan Giehl

As
my last projects were mostly web 2.0 online applications I had to do
a lot of javascript programming. Using JS-Frameworks like JQuery or
Dojo the size of all necessary javascript files had added up to more
than one megabyte. Even today with highspeed internet connections one
megabyte needs several seconds to be transferred, so I had to find a
way to reduce the size of the code. For all my previous projects I
used
Dean
Edwards Packer
. This amazing packer was able
to reduce it to appr. a fourth of the original size. Getting this
nice result I was wondering if the tool delivered with Dojo – the
Dojo
Shrinksafe
– or other minification tools
like
JSMin
and the
YUI
Compressor
could do this as well. After some
tests, however, I realized that they couldn’t.

Searching
the web for more information about the best way I found a cool tool /
website that shows the transfer sizes of well known javascript
libraries after minification / packing. It is also possible to let
the tool calculate the results for your own piece of code:
http://compressorrater.thruhere.net/

In
addition, the tool also calculates the size of a transfer with
http-compression (gzip). Before I found this website I did not see
the size after minification / packing and compression in combination.
Perhaps I should have done this before…

Analyzing
the results of CompressorRater it seems that Dean Edwards Packer
might really be the best choice – even with zip compression. Very
interesting is the fact that the results of packing and minification
is nearly the same after zip compression.

Yet
the size of javascript files and their transfer speed is only one
aspect which affects the loading delay of websites. The other aspect
is the time the browser needs to interpret those scripts. As packed
files have to be interpreted twice – first to eliminate the eval
and second to interpret the generated code – their loading delay is
higher than those of minified files.

After
taking a closer look at the loading time of those minimized
javascript files it turned out that the Packer is not always
the best choice: In case of bigger javascript files, the Packer
needs up to several seconds to d’eval the code. This doesn’t matter
so much in web applications where javascript is only loaded and
interpreted once at the beginning but it will slow down a typical
website even more because javascript has to be interpreted at each
site request, even if it is in the browser’s cache. Using a minified
script avoids this.

Summarizing
I suggest to use Packer only if it is not possible to realize an
http-compression.

Avatar von Stefan Giehl

Kommentare

2 Antworten zu „Minimizing your JavaScript Code“

  1. Packer also has a fast decode mode as well that sacrifices some of the compression to gain faster unpacking, personally I have my site organized so as the client recieves a jsmin version if they support gzip content encoding and a packer version otherwise, the down the wire time often more than compensates for the time to decode packer when you are talking about large js libs *stares at scriptaculous*

  2. My javascript original size is 114.69 KB and i host it to http://www.yourjavascript.com. In the file info on firefox, it shows the file only 33.79 KB and the source is same with the original. how they compressed it?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.