[thelist] preparing Javascript code for release in xhtml templates

[Peter Brunone (EasyListBox.com)]

   I agree with Matt.  One further thought on the bandwidth savings:  have you considered compression?  Some web servers support content compression via HTTP 1.1 (browsers which support this will use compression, and others will get the content the regular way).

   With text and html content, the size reduction can be as much as 90%; it might be worth investigating.  One caveat is that the server may cache compressed files, even if they are supposed to be dynamic; this will depend on the platform and you'll have to see how that affects your particular situation.

Cheers,

Peter

 From: Matt Warden mwarden at gmail.com

Scott,

On Thu, 13 Jan 2005 06:46:33 -0600, Scott Blanchard
wrote:
> Losing all it's dev friendly formatting but minimizing the character count
> for SEO strategy as well as minor obsfucation of the business logic.

You both have a point. As with many issues, there isn't exactly a
clear-cut, true-for-everything answer. However...

The obfuscation is so minor it's really not worth mentioning. If
anything, it would keep someone who doesn't really care from figuring
it out. If someone wants to figure it out, they'll take the 5 minutes
and make it readable.

As for character count, I cannot say this for a fact, but I can see no
reason why a search engine spider would count consecutive whitespace
characters as anything but a single space. Consecutive whitespace
characters have little or no meaning in content types that are
relevant to this discussion. (Unfortunately, I was unable to google up
anything supporting or refuting this point.)

I think your only real argument is bandwidth savings. If it is an
extremely high traffic site, the extra bytes you save here and there
might be worth it. But, if your site isn't slashdot, I'm not sure it
is worth the debugging hassles your developer points out.

> The developer has countered that he will not be able to support this code
> because it will cost him time to convert the code back to human readable
> format in the event that post release bugs are reported. He suggests putting
> the code at the bottom of the page so that it does not hinder SEO. I
> completely disagree with this.

You could possibly work out a compromise.

if (!DEBUG) $script = stripwhitespace($script);
print $script; 

I assume you could do this, since you mention that the script is often
being generated dynamically. Since this is an innocuous change to the
output, you could even have DEBUG based on a query string variable.
This would make it easy for your developer to debug post-launch
problems.

-- 
Matt Warden
Miami University
Oxford, OH, USA
http://mattwarden.com

This email proudly and graciously contributes to entropy.
-- 

* * Please support the community that supports you. * *
http://evolt.org/help_support_evolt/

For unsubscribe and other options, including the Tip Harvester 
and archives of thelist go to: http://lists.evolt.org 
Workers of the Web, evolt !