[Solar-talk] Squished JS and CSS

[Rodrigo Moraes]

On 12/23/06, Clay Loveless wrote:
> Too much for a simple thing, I think. :)

He, as I thought. :-)

> Think about it like this: you've got a bunch of content (CSS and JS)
> that the browser is going to cache for a long time.
>
> So, the first time the browser gets the file, it'll cache it, period,
> unless "cache busting" random strings are tacked onto the URL.
>
> What you're suggesting is a compression routine that happens on
> *every request*, despite the fact that the browser already has the
> cached compressed version from the first time.

That's true. I'd have three Solar instances (page, css & js) for every
call, and to serve even client-side-cached files. However it is
possible to check if the browser cache is updated and send a 'HTTP/1.0
304 Not Modified' header with no new content. Anyway, it's a work that
can be avoided just letting the server do its job. :-)

> Much less fancy, but much more efficient, method: compress the stuff
> with jsmin or one of the other processors first, store the compressed
> version as static files in the /public directory, and configure your
> web server to handle the gzip compression of you think it's worth the
> overhead for the one-time call.
>
> Same result, but doesn't bog down your application or waste cycles on
> redundant compression.

And what about the idea to force javascript/css gzip using PHP? I
mean, the technique Dustin Diaz shows here:

http://www.dustindiaz.com/yahoo-event-utility/

It could be done without touching the javascript files, adding a
auto_prepend ini setting in the .htaccess for the javascript
directory:

AddHandler application/x-httpd-php .js
php_value auto_prepend_file 'gzip-js.php'

(I have to research a bit more. It may be possible to tell Apache to
serve compressed css/javascript directly, without having to use PHP,
which would be much better)

> You'll notice that there's already a scripts-min directory in the
> Solar distro that has compressed versions of the bundled JavaScripts.
> I know you're not a protaculous fan, so that may not suit your needs,
> but you could be using the -min versions of the JS files from YUI in
> a similar fashion.

I've been managing this in a different way to not change the
directories from the distribution, but it is not a big deal.

(evil comment: I like Prototype a lot. I just think that YUI's
utilities + YUI-ext shine too much)

> If you're concerned about ongoing edits and the hassle of keeping a
> compressed version of JS and CSS up to date with the development,
> uncompressed copies, I would recommend one of two things:

Yes, this is the main concern. There is also the concern to force a
browser update when a cached file is changed, but I guess the server
should take care of this as well? The hash idea would also avoid
browsers working with an old file... I guess that at least a timestamp
should be used for the file names, even if they are static, don't you
think?

> 1. A Subversion post-commit hook that would watch for commits to your
> JS and CSS files, and when they're updated, export copies, compress
> them, and do an automatic commit of the compressed versions.
>
> 2. A script on your side that you run before (or during) committing
> to your repository that does the compression immediately before
> commmitting.

These are all nice ideas. I'll look for a way to automatically run the
compression utilities after commiting. Anyway, this only needs to be
done before moving something from dev to production, so maybe I'll add
the compression proccess to the builder I'm using (Phing).

Thanks for the nice thoughts! :-)

rodrigo

---------------------------------------------------------------------
Solar has now a Community Wiki: solarphp.org
---------------------------------------------------------------------
Join the #solarphp IRC channel on freenode.org
---------------------------------------------------------------------