[Cialug] gzipped js and css with no app server

Matthew Nuzum newz at bearfruit.org
Fri Jan 18 11:22:51 CST 2008


I've actually read through that article and the comments and am a bit
frustrated. Spent a good part of an afternoon with Safari 3 doing
experimenting. It seems to work for compressed HTML but not for js, which I
find remarkable. Interestingly enough, the same thing happens with
Konquerer.

If I try to view the file
http://code.bearfruit.org/~matt/gzip/gzip_test.js.gz it just downloads it to
the desktop. But when I run a test to see the response from the server, I
get:

$ HEAD http://code.bearfruit.org/~matt/gzip/gzip_test.js.gz
200 OK
Connection: close
Date: Fri, 18 Jan 2008 16:49:33 GMT
Accept-Ranges: bytes
ETag: "7145a3-2c-abb8e3c0"
Server: Apache/2.0.55 (Ubuntu) DAV/2 SVN/1.3.1 mod_ssl/2.0.55 OpenSSL/0.9.8a
Content-Encoding: x-gzip
Content-Length: 44
Content-Type: application/x-javascript

I've tried changing the apache config so that instead of content-encoding:
x-gzip it just sends gzip, but it changes nothing.

The only thing I can think of is that maybe safari doesn't support gzipped
css/js. You'd think that all modern browsers would though.

On Jan 18, 2008 10:49 AM, Tom Pohl <tom at tcpconsulting.com> wrote:

> Looks cool, but safari reports to not support gzip even though it really
> does.  Here's a URL (comment #2) that describes what's happening:
>
> http://joseph.randomnetworks.com/archives/2006/07/13/compressed-javascript/
>
> -Tom
>
>
>
> On Jan 17, 2008, at 9:17 PM, Matthew Nuzum wrote:
>
> It's trivial to write a bit of PHP code that looks at the http
> accept-encoding header and choose to send either compressed or uncompressed
> data based on what you find there. However I'm in a special situation where
> I cannot serve dynamic content based on individual browser settings. I have
> a caching proxy in front of the app server and for performance reasons we
> don't send differing content based on browser preferences.
>
> I've been trying to figure out a way to detect if gzip compression is
> supported on the client side and then use that information to request either
> compressed or uncompressed js and css files.
>
> The difference in file size really is impressive, starting at about 50%
> decrease in file size for small resources and improving to 70% decrease in
> file size as the resources get larger. Also, it allows you to use normal,
> non-packed js files with practically no difference in download size which
> makes debugging js *so* much easier. (by packing I mean something like
> http://dean.edwards.name/packer/)
>
> I've come up with a solution. It adds about 1.4k to the page weight, but
> in my use case saves over 20k. I've got a working example but would really
> appreciate a few extra eyes and any feedback. I've documented my proof of
> concept here and I'd love to hear your thoughts on it:
> http://www.bearfruit.org/blog/2008/01/17/using-gzip-compressed-js-and-css-without-an-app-server
>
> --
> Matthew Nuzum
> newz2000 on freenode
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>
>
>
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>
>


-- 
Matthew Nuzum
newz2000 on freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cialug.org/pipermail/cialug/attachments/20080118/4581c891/attachment.htm


More information about the Cialug mailing list