browser caching strategy for javascript and css?

i have found that my site's js and css files are not being cached in browsers correctly. when i use pingdom tools analysis and other similar tools, i was get a warning about 'leveraging browser cache' - highlighting that the core and plugin css/js files are not being cached by the browsers. when i add a directive to my site's nginx config file that is intended to set the expires header for jss and css files, it appears to do nothing - even though i have successfully added such headers for other file types already.

is there something about the way that elgg serves js and css files that prevents an expires header being added!? when i analyse the elgg community here through the same tools, it passes 100% and gets no warnings.. anyone know how/why?

  • aha. the problem was just that there was a typo in the nginx config, so my changes weren't applied and nginx didn't warn me when i restarted the server. it is working now. :)

  • Can you please contribute your nginx config changes for

  • oh, i didn't realise this was an issue. i just learned that although 'expires' is now being set - when i attempted to change theme using my custom theme changer code or flush the caches on my site, the css files fail to load. this is the same regardless of whether the symlink is used or not.

    so basically, it appears i have no way of caching css or js files on my site in nginx at present.

  • the problem appears to be that if you add a directive in an nginx config file that handles js/css files, then the call to those files is only processed through that one directive and not through other directives that are needed to be able to handle the files correctly.

    i thought i would be able to resolve that by adding the default 'try $uri $uri/ @elgg' directive to the block for js/css files. this has actually resolved the problem - buuuut.. for some unknown reason, the expires date is being set to 6 months, instead of the 1 month that i had set it to in the config file. i continue!

  • technically, a 6 month expiry date is ok since the filenames will change whenever the file contents change, but i am still unclear as to why my value of 1 month is being ignored.

  • is there a particular reason why the cache expires header for js and css files is not set directly by elgg? it seems like that would be the most accessible and granular way to do it.

  • If your cache symlink is set up, PHP doesn't touch the files, so Elgg can't do anything, it's up to proper web server configuration. We have a correct Apache config, but not for nginx.

  • i experience the same problem regardless of whether the symlink is present or not... i am not sure why.

    i will test this setup a bit more and then post what i end up using.

  • Do you have the dataroot config variable set in settings.php? If yes, this might explain why the problem also occurs without the sysmlink variable.

    Don't ask me about the exact handling of caching with/without the dataroot variable defined. I only remember that I had an issue with MultiViews in Apache causing the CKEditor to fail both with the cache sysmlink and/or the dataroot variable defined but not without either of them used. I don't know if nginx has anything corresponding to Apache's MultiViews. If yes, it might help to disable the corresponding functionality (as I do now in .htaccess to override any global Apache config of MultiViews).

  • i did have the dataroot variable set in settings.php, yes. i just removed that and then removed the directive for js/css files in my nginx config but there is a confusing pattern emerging. i am now seeing that js and css files are being served with a 6 month expires value regardless of whether the dataroot value is set or not and regardless of whether i apply an nginx directive to js and css files.

    my only explanation for this at present is that when i initially removed the symlink there was some kind of delay in the system that meant that initially the expires parameter was not applied.