Friday, December 21st, 2007

Packing Down Prototype

Category: Prototype

In the world of client-side development, page size definitely matters and John-David Dalton is doing his best to improve this. Awhile back, he took on the task of trying to determine how to best optimize the 120k+ Prototype and libraries and get the best compression out of the files. He’s done an absolutely fabulous job in the past and continues to pack the libraries as new versions are released. He’s just released his new version of his compressed Prototype collection and released it on Google Code.

This pack contains the following compressed versions of Prototype: 1.4, 1.5,, 1.6.0 and Scriptaculous: 1.7.1_beta3, 1.8.0. This release compresses Prototype and Scriptaculous around 10% more than regular gzipping.

Prototype’s lowest weighs in at 20.4kb.
Scriptaculous’ lowest weighs in at: 19.7kb.
Protoculous’ lowest weighs in at: 38.4kb.

Compressed forms of Scriptaculous are segmented to allow for custom builds of Protoculous/Scriptaculous.

He has included a common custom build with the pack, “Prototype+Effects”, which weighs in at around 26kb. That’s smaller than standard Prototype gzipped!

Protoculous also allows the loading of additional js files like Scriptaculous via: protoculous.js?load=one,two

You can download his collection here and included in the download is a readme file providing more details about his build.

Posted by Rey Bango at 10:55 am

4.4 rating from 74 votes


Comments feed TrackBack URI

Yay! I love it.

Comment by Diodeus — December 21, 2007

Is his technique manually or it can be done by an application? any blog post or somethin’ from him?

Comment by phpcs — December 21, 2007

@phpcs – I format the code manually, fixing semi-colons and fixing references to $super. I run them through a compressor with quotes around the $super vars so they aren’t changed then fix their method arguments. I use Dean Edward’s Packer because it creates the smallest files. From there you can use a server side solution to gzip/version/and deploy the file. I use Prado ( and their asset publishing capabilities.

I have a Blog but it’s currently in the early stages, I never have time to work on it.

– Cheers :)

Comment by jdalton — December 21, 2007

very cool………. Prototype++

Comment by holts — December 21, 2007

I think any article like this needs a big asterisk next to the sizes to note how using a packer like this affects parse time and therefore overall page latency. We experimented with integrating Dean’s Packer into Dojo’s build process but found that the time it takes to unpack the code via regex was nearly 100ms, and if gzipping was employed, the size on the wire wasn’t any different (which we expected). If you’re serving your content right, packing hurts, and if you’re not, it may still be a wash. Oof. As a result, our guidance to folks is to just pull it off of a CDN or a static resource server which is guaranteed to gzip it. Other toolkits (like jquery) have backed off from providing default-packed versions and now provide a choice (I can only assume for similar performance reasons).

Comment by slightlyoff — December 21, 2007

Just wondering if we are any closer to a universal CDN for Ajax libs (all versions), or if the desire to minify and link cull means too many combinations to host? Agree with Alex on gzip over packing.


Comment by Brendan Eich — December 21, 2007


I cannot agree more! See this article for more details:


Comment by jlecomte — December 21, 2007

You all will be pleasantly surprised to notice that Dean Edward’s Packer 3 has a “shrink variables” option that produces NO parse time delay because nothing is encoded. In fact if you were to read the readme_first.txt in my package you would also notice that I don’t recommend using JavaScript compression that encodes the source because of the delay you mentioned.

The file sizes in this post are of the “var shrunk” versions that were gzipped.

No asterisk is necessary because there is No parse delay.


Comment by jdalton — December 21, 2007

Packer still uses eval().

Comment by MezZzeR — December 23, 2007

@MezZzeR – Dean Edward’s Packer 3 only uses eval() when compressing with the “Base 62 encode” option checked. If you just use “Shrink variables” then there is no use of the eval().

Comment by jdalton — December 23, 2007

As a result, our guidance to folks is to just pull it off

Comment by koreanplywood — December 25, 2007

Leave a comment

You must be logged in to post a comment.