David Cramer's Blog - Latest Comments in Scaling Your Frontend: Far-Futures Headers and Template Tags

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

simon — Mon, 16 Mar 2009 06:40:33 -0000

Check out django-compress. It versions, combines, and minifies your js/css files.

I use a patched version to bypass using settings.py (current trunk requires this).

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

Arne Brodowski — Mon, 16 Mar 2009 05:58:27 -0000

Because of the caching-issue tabo mentioned I'm using this approach for quite some time now (docstring is in english):

http://www.django-hosting.d...

It's very similar to your solution but it doesn't append the mtime as a query string. Instead it appends the mtime in the filename just before the fileextension and is used in conjunction with some mod_rewrite rule to strip the mtime before reading the file from disk.

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

tabo — Mon, 16 Mar 2009 05:19:49 -0000

Are you aware that if you do this, your static files won't be cached?

http://www.stevesouders.com...

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

dc — Sun, 15 Mar 2009 01:48:59 -0000

Very useful.. Thanks

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

Honza Kral — Sun, 15 Mar 2009 00:06:19 -0000

Why go to all this trouble which requires:
- access to the files from your frontend (that should not be in high traffic site)
- a filesystem access for every URL rendered (with hundreds of thousands of files, this gets ugly pretty quickly)
- requires you to use template tag for every single occurence of such URL (no URL's in static files then)

instead you can just set MEDIA_URL = 'some_url/%s' % VERSION and have your deployment system handle the directories on the media server (simple symlink is usually enough). Settings.py is just a python file, why not use that and compute the VERSION once and for all.

VERSION can be taken from svn's revision and/or any arbitrary string (we, for example, take it from the package version that we deploy, same version we use to identify DB schema version and resolve dependencies). Plus your deployment process can go into your static files (js and css) and add the version there so that you won't have to generate those dynamically.

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

Nick — Sat, 14 Mar 2009 21:38:15 -0000

I can't understand reason for that. Testing ?
Changing file means that you've updated it's timestamp. So, next time you'll have new (non-cached) file delivered to client.

Re: Scaling Your Frontend: Far-Futures Headers and Template Tags

Parand — Sat, 14 Mar 2009 21:14:21 -0000

Thanks for this, I've been meaning to do it forever and this is just the kick in the pants needed to implement it. I was thinking of using the svn version number, but file modification time is even easier.