[Seaside] [YSlow] How to set expires in response header for css and js resources?

Jimmie Houchin j.squeak at cyberhaus.us
Fri Aug 24 15:39:40 UTC 2007


I think some optimizations of this sort would be great. It would help 
Seaside in several area. I've been reading about and exploring Plone as 
a potential option for building a website. They have some really nice 
stuff already built. But since I would not be purely an end user it 
isn't a simple decision. Nevertheless I digress.

In the Plone 3 development cycle. They made great efforts to reduce file 
sizes of css, js, when reasonable and possible without sacrificing their 
goals of usability. They also did all that they could to reduce http 

One of the posters on the list said that it helped him a lot with sites 
that he views with his cell phone. He said he had reasonable bandwidth 
but each ping was expensive and having lots of http requests really, 
really hindered performance, while having a single much larger request 

This was in a thread on [Plone-developers] Kupu now uses CSS sprites.

In which Alex Limi speaks of a technique from

Now, Plone is a CMS and includes a lot of things out of the box that 
Seaside itself does not. But there could be things in that thread 
applicable to Seaside or Pier.

Excerpts from the thread above:
> [Plone-developers] Kupu now uses CSS sprites
> From: Alexander Limi <limi at pl...> - 2007-08-05 06:44
> Just a heads-up in case you see any issues with Kupu:
> I moved the Kupu icon loading to use CSS sprites 
> (similar to the plone.org front page).
> Before: 17 HTTP requests
> Now: 1 HTTP request
> This has a major impact on how quickly Kupu 
 > performs its initial load — as
> HTTP roundtripping is very time-consuming.

> Re: [Plone-developers] Kupu now uses CSS sprites
> From: Laurence Rowe <l at lr...> - 2007-08-07 09:51
> I'm currently onsite somewhere where I'm not allowed 
> to plug into the network. Accessing the net over a 
> 3G phone is fairly fast to download (1mb/minute) 
 > but I have a 2 second ping time.
 > It's as bad as a satellite connection.
> Changes like this make a huge difference.

Hope this helps shine some perspective from another group.


Sebastian Sastre wrote:
> Hi there,
>     I was able to make Seaside to write files to disk in an optimized
> fashion. In the application config it offers you to save all the files of
> the libraries in a configurable subfolder of the image directory or make
> that but in an optimized version.
>     In the optimized version (you should set your current/next version
> string) it collects all the CSS content of the libraries used by the
> application and writes in a single css file. The same is made for javascript
> content. 
>     The version string is concatenated just before the extension of the
> filename like this:
>         <filename>.<version string>.<extension>
>         Ex.: 
>             cssStyle.1.3a.css 
>             javascriptStaticCode.1.3a.js
>     With that, if you use them, scriptaculous, prototype, your own js stuff,
> goes to that .js file wich probably will be better deflated or gziped by
> modern http servers.
>     I saw a couple of metrics on a site of my own. I show a table of results
> in the attached file.
>     This convinced me to having a package that makes Seaside work like this
> is worth. But I also think that Seaside itself deserves it because it makes
> it won an A for YSlow principle number 3 sistematically for all pages (valid
> for the resources css and js only).
>     But Yahoo makes the versioning name part of the deployment so I thought
> that we also should be able to do it. Why them do that? They do that because
> like that they take advantage of the web browsers cache. They add
> systematically expiry headers for every static content they serve. So why we
> shouln't?
> 	To implement a systematic optimization like that we need to add the
> expiry header for the css and the js files.
> 	As they are inserted in the updateRoot: which is a process part of a
> response that explicitely needs a cache control of "no cache" I don't
> understand yet how we can set the expiration of only this two files and not
> the rest of the html code. Can someone give me a glimpse on how to achieve
> this?
> 	A secondary question also arrives: can we extend this systematically
> to all the resources? Png, jpg, gif, etc having the <version string> subfix
> and an expiry date far ahead on time to be able, as Yahoo do, to deploy
> anytime a next version of all the resources the seaside app uses in an
> inexpensive fashion?
> 	For your application code should not be a problem if you manage
> resource evocation with Jetsam. We should be easily able to make Jetsam
> FileLibrary to automatically refer with a proper filename subfix versioned
> like your application configuration says that has to use.
> 	If we could do this we additionally will won an A for YSlow
> principle number 3 guaranteed for all seaside components systematically. So
> all Seasiders (and users and customers) won.
> 	cheers!
> Sebastian Sastre

More information about the seaside mailing list