SitePoint Sponsor

User Tag List

Results 1 to 4 of 4
  1. #1
    SitePoint Evangelist winterheat's Avatar
    Join Date
    Aug 2007
    Posts
    508
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    running Packer on Prototype.js or jQuery, or YUI

    I tried running Dean Edwards's Packer on prototype.js 1.6.0.3 and the file size is shrunk down to 36% of the original:

    compression ratio: 48635/134057=0.363

    but in real life practice, I don't see people using the packed version... the original version is 127kb and is somewhat big. 47.5kb is quite an improvement. Just wonder if it is recommended to do so. Thanks.

  2. #2
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not completely sold on it.
    There's little doubt that a big heft of javascript will download faster compressed. But the drawback is that even though the browser can then cache what it downloaded, the browser still needs to uncompress it on every subsequent page load, which takes time.

    I'd bet the tradeoff is well worth it on a fresh load for a visitor, where the browser hasn't cached it locally yet. The first page load is important. But all page loads after that will be less responsive. I guess you need to decide where you want your performance.

    I haven't done any benchmarking, so the severity of the two sides of the picture are kinda unknown to me.

    gzip has the same pro/con. At least in opera, the cached version is stored compressed still. But I would imagine a browsers native gzip implementation is extremely fast.

  3. #3
    SitePoint Evangelist winterheat's Avatar
    Join Date
    Aug 2007
    Posts
    508
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's true... some javascript environment will expand it very slowly... a lot slower than gzip which is in machine code.

    how about then, to host the prototype.js on a CDN (content delivery network) like akamai... maybe we can use

    <script src="http://www.some-CDN.com/prototype1.6.0.3.js" type="text/javascript"></script>

    and set the HTTP header to never expire (or expire in 10 years). So that the client's browser doesn't even need to make a network round trip to check for whether the file is up to date. When prototype has a new release, we can just change it to prototype1.6.0.4.js and it will load a new version on client's browser.

    we can do this if we have 1, or 2, or a few important pages. or we can use a PHP include so that we don't have to update all 500 of our files (or 50 of our templates) when a new version comes out. It will make one more hit on the disk on the server for that include file, but that probably should be in RAM any way. (for large company). for small guys... then that 1 more disk hit may mean a real hard disk hit.

    and actually, are there already CDN hosting prototype.js already by google.com or by some company's API depo so that we can use it to load prototype.js?

  4. #4
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by winterheat View Post
    and actually, are there already CDN hosting prototype.js already by google.com or by some company's API depo so that we can use it to load prototype.js?
    http://code.google.com/apis/ajaxlibs/


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •