Comments on: Dean Edwards /packer/ compression tool http://www.clientcide.com/best-practices/optimization/dean-edwards-packer-compression-tool/ Making stuff work on the other side of the request. Tue, 05 Jan 2010 18:16:32 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Dean Edwards http://www.clientcide.com/best-practices/optimization/dean-edwards-packer-compression-tool/comment-page-1/#comment-77 Dean Edwards Fri, 24 Nov 2006 19:37:07 +0000 http://clientside.cnet.com/best-practices/optimization/dean-edwards-packer-compression-tool/#comment-77 It is not the eval that is slow. There is only one eval and it is equivalent to document.write in terms of speed. The overhead is cause by string replacement. There is only one of these but it executes over (in this case) a 30K string. You have to do the math yourself. If you are getting a lot of one-off hits then packing is the way to go. If you are confident that you will get a lot of return visitors then just whitespace and comment removal may be sufficient. Like a lot of things this is a judgement call. The next version of packer will provide variable/argument substitution for a higher compression rate and proper obfuscation. This also makes the minified (whitepaces stripped) version much smaller too. It is not the eval that is slow. There is only one eval and it is equivalent to document.write in terms of speed. The overhead is cause by string replacement. There is only one of these but it executes over (in this case) a 30K string.

You have to do the math yourself. If you are getting a lot of one-off hits then packing is the way to go. If you are confident that you will get a lot of return visitors then just whitespace and comment removal may be sufficient. Like a lot of things this is a judgement call.

The next version of packer will provide variable/argument substitution for a higher compression rate and proper obfuscation. This also makes the minified (whitepaces stripped) version much smaller too.

]]> By: Ethan http://www.clientcide.com/best-practices/optimization/dean-edwards-packer-compression-tool/comment-page-1/#comment-52 Ethan Thu, 26 Oct 2006 19:47:02 +0000 http://clientside.cnet.com/best-practices/optimization/dean-edwards-packer-compression-tool/#comment-52 First off, nice freaking work on the mootools docs! I came across them earlier today, and was impressed. Congrats. But onto the topic at hand. I too fear the eval that is at the start of all 'packed' code. It makes things small, but there's a lot for it to eval. Personally I'm a fan of the whitespace stripper, it's less for their browsers to load, but it's not executed every time they load the page. And page responsivenness, especially with dom stuff, is not a minor issue. First off, nice freaking work on the mootools docs! I came across them earlier today, and was impressed. Congrats.

But onto the topic at hand. I too fear the eval that is at the start of all ‘packed’ code. It makes things small, but there’s a lot for it to eval. Personally I’m a fan of the whitespace stripper, it’s less for their browsers to load, but it’s not executed every time they load the page. And page responsivenness, especially with dom stuff, is not a minor issue.

]]>