EE currently sends the following headers when serving CSS:

This is incredibly inefficient. Static content like CSS and JS should only be sent to the client if they’ve been modified. Please offer an option to send proper HTTP headers for these types of content.

I’d argue that it should be on by default, as the benefit of sending a fresh copy every time is far outweighed by the performance hit incurred by doing so. EE CSS and JS files should behave exactly like any other CSS out there. That is, cached normally.

More information

I’d second this- would be nice to have a config setting so css and js can be optionally cached by the browser.

About 20,000 posts late on this one, but nevermind ;]

http://expressionengine.com/forums/viewthread/40481/

Oe OE vote here too,

Me hopes a new EE build with that option..

I’d really go for this one too!!

Yep, should be. I was somewhat surprised it wasn’t but I always use external files. Was thinking about going internal but this stopped me cold.

It does seem to offer easy scope to significantly speed up EE page loads [after first page].

I started looking into ways of doing this last year [with noble help by the_butcher], but could not crack it [at least for online sheets].

I seem to remember that this is not just an EE thing - which made me wonder if there a good reason for not caching stylesheets?

Still be great to have the option tho!!
- especially as the per stylesheet option is there already in the template preferences, so no changes in UI needed!

Anything that goes through the Template parser in any form will have those headers sent because they force the content to not be cached, which in a dynamic CMS like ExpressionEngine is critical.  One should be able to easily justify why we would not want a global option to cache templates of any type, including CSS and JS.  More fine tuned abilities to send different headers for individual templates is on our minds though.

As for CSS templates.  I think we can change the headers sent when using the {stylesheet=} variable as it never goes through the Template parser and is almost directly outputted to the browser.  I will have to do some research to figure out what are the best headers to send as the RFC specs are nearly useless as the browsers rarely follow them correctly and each browser is a bit unique in its “following”.

Cool…Thanks Paul for taking this up.

Fascinating stuff I am reading here. 

I do get paid for this, right?

Get paid for such lite reading?  Are you crazy ;-)

As I understand it ..

if I have EE on domain1.com and if I have my CSS, Images, JS called from domain2.com

then it seems the browser caches everything served through domain2.com ... ?

You get paid in deep and heartfelt admiration by the bucket load! I’d echo the thanks for picking this up. I do think that this will be worthwhile. 

Going back a stage, I just had not realised that you could store/use stylesheets as static files.  It was only when Pxylated mentioned ‘external files’  that I suddenly understood that you could actually use something like MyStylesheet.CSS with EE [just like external image files]. 

I tried this out on one site [hosted by your good selves in the US] and it made a clear and noticeable speed improvement [when moving between pages].  So thanks to Pxylated too!

PS to save anyone whose wondering how to do this a few seconds of thought:

this code calls a standard dynamic sheet held within EE

but this code calls a static sheet external to EE

NB {gv_dir_cssext} is simply a global variable holding the path to the directory that the external CSS files live in

Just a little further on this .. I don’t know how it will apply to those who are using C-Panel type servers because they treat sub-domains a little differently ...

My site’s on an H-Sphere panel and they treat sub-domains as a separate domain (ie with its own root etc .. )

I’ve just tested my site in IE, Firefox and Opera (PC running XP) and found that all browsers are cacheing everything served up from the subdomain .. which includes CSS, all images and JS files.

This is how Yahoo do it .. all their static content, images etc are served through another domain.

Interesting Paul. Would you be reading up on XHR caching for a reason? ;]

Yes please, this is needed.

Hey Adam, what version are you running?  This was added last year in v1.6.1, at least on the part of stylesheets:

Modified the {stylesheet=”“} tag to allow browser caching of CSS files and built in versioning of stylesheets

Hmmm, I apologise; I am using the most recent version and build, and after checking my headers again it does seem that this has been implemented.

Actually, I was wondering if there is some method of knowing which feature requests have been implemented? Short of cross-referencing the entire back-log of build/version notes that is.

Can the moderators mark FR that have been implemented as ‘closed’ so that we could tell?

I would just cruise through the changelog whenever we put out a release, Adam, or search through it when you are unsure.  There can be multiple threads for a given feature, and there’s always the possibility that we missed a feature request, but happened to implement that particular feature.  It would take quite a bit of time to be thorough and make sure appropriate threads got marked as implemented - just thinking of the different ways we’d have to search on terms to try to find even a simply described feature makes my head spin.  The end result would be an inaccurate representation of implemented / not implemented, but the existence of a marker to that effect would give the indication that is was an accurate metric.