Why not caching javascript and css?

Javascript ONLY appears and css is not cached ... but images are cached.

I use Firebug, and when I refresh the page, I notice in Firebug a lot of 200 HTTP responses for js / css, but I get 304 HTTP codes (content not changed) for all my images. This way, it looks like my JS and CSS are not cached.

Also, when using YSlow to help solve the JS / CSS caching problem, he tells me that:

There are 4 components with incorrectly configured ETags

Below is my .htaccess file

Options -Indexes Options +FollowSymLinks # Enable ETag FileETag MTime Size # Set expiration header ExpiresActive on ExpiresDefault "access plus 1 week" # Compress some text file types AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript text/javascript application/javascript application/json # Deactivate compression for buggy browsers BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Set header information for proxies Header append Vary User-Agent 

Any idea what is wrong with my .htaccess access file without allowing my CSS or JavaScript to cache?

+10
caching apache .htaccess etag
May 08 '09 at 18:36
source share
6 answers

Please consider disabling ETag!

Consider the following settings:

 Header unset ETag FileETag None Header set Cache-Control "max-age=2678400" 

The first two rules completely disable ETag, so the browser is somewhat forced to listen to the Cache-Control header. The last rule tells the browser to cache the file 2678400 seconds or 1 month. Change the settings to what suits you best. And apply this configuration in your directory that contains static files (e.g. by placing the .htaccess file in this directory)

Optionally, if you are using multiple servers for static content and / or are not sure of the latest changes these servers are reporting, consider using:

 Header unset Last-Modified 

It tells Apache not to serve the Last-Modified headers, so browsers can only listen on the max-age Cache-Control header.

These settings are used by me on many hightraffic websites, and disabling the ETag and Last-Modified headers helped reduce traffic to one fifth of what it was before. Especially Internet Explorer is very sensitive to these settings.

Be warned: Disabling Last-Modified will no longer request 304 Content Not Modified requests. In my experience, this is positive because the web server has fewer processing requests, and browsers rely more on the Cache-Control settings that you serve. But it may or may not suit you. Some browsers will try to check assets every few minutes if you give them the "Last-Modified" header, and so I would advise you to completely disable its use.

Oh, and if you're not sure about your caching; use http://www.redbot.org/ to check your assets, it quickly reports what your headers mean for the browser, and how to interpret the various cache control settings to use.

+5
Dec 13 '11 at
source share

YSlow reports incorrectly configured etags if they do not adhere to a specific pattern. Since you are compressing css and js, these diagrams are output like this:

 Etag "1e10-4889909861a80"-gzip 

See -gzip at the end? It fits apache there (version 2 only). This is precisely what causes the "error." YSlow expects to see something like this:

 Etag "xxxx-xxxxxxxxxxxxx" 

Basquely, you cannot fix it because it is not broken. So don’t go crazy trying to get the perfect result if you don’t know what you are doing. Even this yahoo page only gets 90.

+2
Jun 09 '10 at 13:57 on
source share

This YSlow error message is extremely misleading!

YSlow actually complains that you generally use ETags!

YSlow works in your browser - it has no way to find out if ETags are configured correctly or not. Typically, this suggests that you should not use ETags, because you are more likely to have them configured incorrectly than correctly configured in a multi-server environment. (And YSlow targets users with large multi-server websites.)

Of course, if you use a single-server setup or use a distributed server setup, but you know what you are doing, then ETags is fine. But YSlow does not know this.

There are many discussions in the comments on the error description page: http://developer.yahoo.net/blog/archives/2007/07/high_performanc_11.html

I also found this answer on ServerFault, which repeats the point: https://serverfault.com/questions/55919/yslow-says-etags-are-misconfigured-how-to-configure-etags-properly-on-iis7

+2
Sep 15 '10 at 19:42
source share

Yes, this is the correct and well-known behavior (perhaps not very important).

Read http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html about ETag.

Perhaps you just want to disable ETag on the server.

Edit: Also, use the LiveHTTPHeaders addon to understand what your browser does. It works better than FireBug for this task.

+1
May 08 '09 at 19:43
source share

I am experiencing the same problem as you. Removing etag will work.

Add the following to the configuration file: FileETag none

+1
Jul 30 '09 at 4:08
source share

Hi, I had the same problems. But just put in FileETag no one worked

How I fixed it (and I don’t know if this is correct, but it works), I put

FileETag none

at the bottom of my htaccess file.

Then ySlow was happy.

0
Jan 11 '10 at 4:03
source share



All Articles