You may be familiar with "last modified" headers - a way preventing repeated downloads of files that haven't changed since they were last requested. Knowing this allows browsers to use a locally cached copy, which will significantly speed up user experience.

Etags are a similar mechanism, but instead of using dates and times, use an identifier instead - which gives a bit more flexibility that just a timestamp. This can be useful if for some reason you can't get implement correct last modified dates.

The way etags work is your server can be configured to send the tag along with requests for images etc. When your browser re-requests the file, it also sends back the tag. If they match, the cached version is served instead.

How it's set up, and whether it's necessary depends on your server. Bear in mind that automated tests will tend to rely on general best practice rather than specifics for your site.

If you have some budget to increase speed, I'd recommend serving media files via a CDN - there are a number of low cost options for this these days, and your CDN provider would handle the best approach to caching for you. It would also reduce your own server laod and speed up the parts you were still handling yourself.

- if the browser caches that resource it would also maintain the Etag for that resource. - the next time that browser requests that resource it also sends a HTTP request header like:

If-None-Match: "nnnnnnnn"

- if the server can match Etags with the current version of that resource, instead of responding with that resource it will send a HTTP 304 Not Modified status. - then the browser will use the cached resource instead of having to wait for another copy.

it depends on what determines a "significant" change in content for your specific application. if you are basing it on all 3 options (inode, last modified and file size) it would be simpler to use: FileETag All

if you are using a CDN, for example, the inode would be different on each server, so you might want to use: FileETag -INode

you also want to make sure this directive is designated in the proper Context [httpd.apache.org].