On Nov 11, 2008, at 2:39 PM, Olivier Dehon wrote:
> Thank you Vincent, (and Dave and Anthony)
>
> I think I will definitely be able to work something out with your
> suggestions.
>
> As far as JS and CSS goes, I think I will attempt to serve the files
> independently through a dhandler to force "Expires:" headers for those
> files to avoid the repetitive 304's.
> This will allow (I think) for a more modular management of the various
> JS bits and pieces, and actually allow for a basic "version and
> dependency management" of the JS and CSS libs (a la Maven).
>
> If this fails, then I will fallback on a "deployment/build" script
> that
> does the concatenation at the end of each development phase when the
> site is ready to be deployed/tested.
Why have Mason serve Javascript and CSS at all? Unless there's some
reason you need
to rewrite the files, I would strongly recommend avoiding having Mason
ever touch them.
Instead, just configure your web server to serve them statically -
that's much more efficient.
Also, configuring it to send them gzipped will help performance.
If you're using Apache, it's easy to set file expiration times with
mod_expires. Just be careful to be sure
that you have a system in place so that you can use newer versions of
those files when you need
to update them... you don't want people running with HTML that needs
new revs of the CSS and Javascript
but getting old versions from their browser cache.
Some people do this by adding a parameter to the URL, like so:
<link rel="stylesheet" type="text/css" href="/static/css/uv-homepage-
min.css?version=2" />
I don't like this because it's likely to cause your CSS not to be
cached at all. I want the benefit of my CSS being cached.
Instead, in my sites I embed a version in the path to the CSS:
<link rel="stylesheet" type="text/css" href="/static/20081109/css/uv-
homepage-min.css" />
and when I have a new release of the CSS file, I update the version
number in the path. The version is
simply stored in a config file used by my application, so it's not
something I need to do manually.
I do the same thing with my CSS and Javascript that Dave Rolsky
recommended; I cat all
the individual CSS files and Javascript files together into one big
CSS file and one big Javascript file.
I also minify the concatenated files. Then serve the minified files
gzip'd.
Ther'e also a Javascript compression technique called 'packing', which
encodes the Javascript very tightly
and then decodes and rebuilds it at runtime. While it produces better
results than minifying, be
careful of it because it can have some compatibility problems with
certain browsers (ie: IE).
I think that you'll find that the benefit of serving a single chunk of
CSS and a single chunk of Javascript
well outweighs the hypothetical drawbacks of providing CSS or
Javascript that's not needed by a particular page.
I don't know what your site is, so this may not be relevant to it, but
for most sites the first time a user loads a page
sets a lot of the user's expectations. If the first page load is slow,
you've got a problem. And the first page load
will be the one where nothing's cached. If you load 20 different CSS
and Javascript files the browser is going to
have to wait while they load, and they're going to load serially not
concurrently, as most browsers limit
the number of simultaneous loads of CSS and Javascript from one site.
I don't have the URL for this handy but Yahoo released the results of
a study a while back that showed that
the impact of this effect to be serious. The amount of time that it
takes the browser to process extraneous CSS and Javascript
is negligible compared to the time it takes to pull the separate files
down from the server. And as an
added bonus, you no longer need to worry about getting links to the
necessary collection of CSS and
Javascript files into your HTML.
If you don't believe this, try using Yahoo's tool 'yslow' - it's an
extension for Firebug for Firefox - and check out load times
for your web pages with a single CSS payload and a single Javascript
payload versus many separate CSS files
and Javascript files. And make sure you do it from the environment
your users will be - say a coffee shop or at home over
a cable modem or even dialup or cellular connection - rather than on
the same ethernet as your server.
- john romkey
http://dot.romkey.com/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
