digg

Facebook Connect Join Digg About

Javascript Compressor

crockford.com — Filter which removes comments and unnecessary whitespace from JavaScript files. It typically reduces filesize by half, resulting in faster downloads.

Who dugg this? Made popular Jan 30, 2006

Digg DudeWhat is Digg?

Digg is a place for people to discover and share content from anywhere on the web. Digg surfaces the best stuff as submitted and voted on by the community. Take the Tour to learn more.

32 Comments

show profanity settings
expand all
  • inactive, on 10/12/2007, -0/+3Eh, better compressor:

    http://alex.dojotoolkit.org/shrinksafe/

    "Many other tools also shrink JavaScript files, but ShrinkSafe is different. Instead of relying on brittle regular expressions, ShrinkSafe is based on Rhino, a JavaScript interpreter. This allows ShrinkSafe to transform the source of a file with much more confidence that the resulting script will function identically to the file you uploaded."
  • digid, on 10/12/2007, -0/+2abuser is right...if your web-server distributes a lot of content and doesn't use gzip compression you are losing a lot of money. Even digg uses gzip to save on bandwidth.
  • abuser, on 10/12/2007, -1/+2Isn't this accomplished automatically by Apache (or equivalent IIS) libs like gzip compression?
  • rolosworld, on 10/12/2007, -0/+1baaahhh... lame
    now..
    this is a javascript compressor:
    http://dean.edwards.name/packer/
  • hafe, on 10/12/2007, -0/+1"This just makes the code unreadable and it's pretty much useless if you don't have a site like digg where you need to mind your bandwidth."

    You can have your "development" JavaScript files separate from "live" JavaScript files that are compressed. Well at least if you care for your page visitors :)
  • Brutal, on 10/12/2007, -0/+1MS-DOS .exe file?!

    NO DIGG!
  • Malakin, on 10/12/2007, -0/+1I ran it on an 18.6KB JS file and it shrunk it to 17KB. gzipping either the before or after files shrunk them both to 2.49KB. So it looks like if you're using gzip this is useless and anyone concerned about bandwidth caused from JS should probably be using gzip.
  • Brigadier, on 10/12/2007, -0/+0Wierd, the site is pretty old but I just happened to go dig up this same tool from there last week.
  • Quaitemp, on 10/12/2007, -1/+1Remember to check the license before removing any comments with copyright-info.
  • inactive, on 10/12/2007, -1/+1this is what digg needs!
  • weiran, on 10/12/2007, -0/+0"This just makes the code unreadable and it's pretty much useless if you don't have a site like digg where you need to mind your bandwidth."

    But if you have a lot of javascript it would make your site faster to load.
  • peterbe, on 10/12/2007, -0/+0I think I should mention slimmer as well which is a whitespace compressor written in Python that does javascript, css and xhtml:
    http://www.issuetrackerproduct.com/Documentation#slimmer

    Perhaps not as fast as jsmin but it's Python which means you can more easily integrate it.
  • Otto, on 10/12/2007, -0/+0Hah. I hadn't noticed this "new" addition to mod_gzip: mod_gzip_update_static. Looks like it can automatically update a static gz file from the original content, when it detects that it's out of date. That would definitely be the way to go for that sort of thing.
  • EndofEternity, on 10/12/2007, -0/+0"Digg has 238,830 bytes of javascript, that pretty crazy.."

    Well none of that code seems to be mission critical. I was browsing with NoScript turned on and I didn't see digg die on me. It works just fine. As the original poster states, Javascript is ok as long as the webpage in question is works with Javascript turned off.
  • dpk87, on 10/12/2007, -0/+0"Webpages that rely too much on javascript can be really annoying. If your web page relies so much on javascript that you need a compressor, it might be time to trim some of it out.
    How much is too much? I believe that if you can not browse a page without javascript turned on, it might be too much. It should be something that is an aid for browsing (such as automatically putting a cursor in a text field), not a crutch (every f@*&ing link is incapsulated by javascript:void() )."

    Digg has 238,830 bytes of javascript, that pretty crazy..
  • rompom7, on 10/12/2007, -0/+0good, but could use obfuscation.
  • ifonly, on 10/12/2007, -1/+1I thought comments actrually had a reason to exist.
  • Otto, on 10/12/2007, -0/+0mod_gzip: http://www.schroepl.net/projekte/mod_gzip/

    It works better than any of these little bits of trickery.
  • KentiVarna, on 06/15/2009, -0/+0A couple remarks on packer and ShrinkSafe: They don't work well for huge JavaScript files. For example at Zimbra, www.zimbra.com we've got > 2megs of JavaScript in our application. jsmin only takes a second or two to strip all the unneeded white space, comments, and new lines, where the others will timeout/hang.
  • Vaelan, on 10/12/2007, -0/+0For those of you trying to enable compression on Tomcat... Here are the details...
    Under the <connector> tag add <connector compression="on|off|force" ... >

    And that enables HTTP/1.1 GZIP compression...

    To read more... try this link: http://tomcat.apache.org/tomcat-4.1-doc/config/coyote.html

  • crimson117, on 10/12/2007, -0/+0"Digg has 238,830 bytes of javascript, that pretty crazy.."

    How much of that is advertisement code?
  • rolosworld, on 10/12/2007, -0/+0khenriks, I just check out zimbra.com, it rocks :-D
  • KentiVarna, on 06/15/2009, -0/+0I posted a "reloaded" digg and used jsmin earlier this weekend.

    http://digg.com/technology/digg:_JavaScript_and_CSS_reloaded

    Of course as a previous comment mentions the biggest savings comes from gzip. It also helps to put all the JavaScript in a single file to reduce HTTP round trips.
  • memerot, on 10/12/2007, -0/+0The place I work has an html application that must work online or offline, so it's allllll javascript and dynamic html (with a small java applet to write files for offline mode). We also have clients who refuse to apply all relevant MS security patches and bugfixes and who therefore can't run said application with HTTP compression. Don't ask me why they don't fix their systems but they don't. We have like 3.5 MB of html/js in the application. Removing comments and extra linespaces DOES have a significant use. But a tool written in 2001 with a page last updated in 2003 is not what I'd expect to see on the front page of digg.
  • rolosworld, on 10/12/2007, -0/+0memerot, it does work.. I use it and it does compress... probably for your specific code it doesn't work, but mine works fine! I have 713 lines code on one .js and from:
    18K it compress it to 4.7K
  • KentiVarna, on 06/15/2009, -0/+0@rolosworld - I think you see now, but it's only one file at deploy time. It's 100's of files in the source tree. We just combine it to deploy it.

    @Otto - mod_gzip is on-the-fly compression that for static content like JavaScript wastes significant CPU time vs pre-gzipping the content one-time when it's deployed.
  • rolosworld, on 10/12/2007, -0/+0khenriks, >2MB of javascript? why you don't split it on multiple files?.. also >2MB of source code is a LOT of source in 1 file... what kind of application is it? and how much lag does the browser has.. I know there a lot of memory leaks the browsers javascript, how you manage the leaks?

    obviously packer will timeout, its written on javascript and >2MB of source seems like a big mess... if its 1 file alone??
  • Otto, on 10/12/2007, -0/+0khenriks: True, but you can use a proxy cache to handle that sort of thing, so that hits to your dynamically compressed content never hit the webserver unless they need to. This gives you maximum flexibility and speed, as it turns your static content into content served straight from RAM instead of hitting the disk.
  • memerot, on 10/12/2007, -1/+0Whoever posted http://dean.edwards.name/packer/ - does this actually work? I just pasted in a 500 line js file, and their packed version is definitely smaller, but the ENTIRE thing is wrapped in an eval statement. The only point to smaller js files is speed downloading and executing - wrapping everything in an eval seems like it would make it worse.
  • Zzzzzz, on 10/12/2007, -1/+0Webpages that rely too much on javascript can be really annoying. If your web page relies so much on javascript that you need a compressor, it might be time to trim some of it out.
    How much is too much? I believe that if you can not browse a page without javascript turned on, it might be too much. It should be something that is an aid for browsing (such as automatically putting a cursor in a text field), not a crutch (every f@*&ing link is incapsulated by javascript:void() ).
  • sensor, on 10/12/2007, -2/+0This just makes the code unreadable and it's pretty much useless if you don't have a site like digg where you need to mind your bandwidth.
  • cryptoz, on 10/12/2007, -5/+0Reduces file size by half? So the .js file becomes twice the size it was before? The grammar on digg is fit for a three year old.

  • Add a Comment

    Login or register to comment!
    Or, sign-in super fast with your Facebook account ...


© Digg Inc. 2009 — Content created and posted by Digg users is dedicated to the public domain | Terms of Use Updated | Privacy Policy
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.