Configure Entity Tags (ETags)
What are entity tags?
Entity tags, or known as the
ETag HTTP response header, are cache validators which help the browser determine if it can retrieve the requested resource from local cache or if it must be retrieved from the server. This mechanism helps improve loading times since if the resource can be retrieved from local cache, the browser does not need to make an additional request to the server.
ETag is comprised of three separate components which make it an unique identifier for each resource:
An example of what an
ETag may resemble containing all three components would be similar to
13630e1-b438-524daace96280. However, this may change in structure depending upon the web server, if the
ETag is using strong or weak validation, and if you configure entity tags.
The problem with entity tags
Although entity tags can be useful for minimizing the amount of round trips (thanks to caching), there does exist a problem in using this method. In the traditional sense, etags are meant to be used on a website which only delivers content from a single server. Therefore, for websites that are delivering various resources from multiple servers using either Apache or IIS, entity tags do not work well. etags generated for the same components across various servers will not be recognized from one server to another and therefore will return a status of
200 instead of
304 Not Modified.
This means that instead of retrieving content from local cache, it will make a request to the origin. Consequently, not only will your users experience slower page speeds, but your origin server will also be under greater load and thus consume more bandwidth. Thankfully, this
ETag issue can be resolved by configuring them correctly for multiserver use.
How to configure entity tags
This section shows the simple process of how to configure entity tags on your origin server. For those using Apache 2.4 or higher, there is no configuration required as Apache has updated the FileETag directive. However, to configure entity tags for websites running on older versions of Apache, the INode portion of the
ETag can be stripped by modifying the snippet within your httpd.conf file from
FileETag INode MTime Size
FileETag MTime Size
This will remove the first section of the
ETag and will leave you with something similar to
b438-524daace96280. Now that there is no server component within the
ETag, this fixes the multiple server issue.
Website owners who are using multiple servers to deliver content can decide whether they want to specify a cache validator using
Last-Modified. As long as you are using a web server which solves the
ETag INode issue, or have properly configured it yourself, both options are valid. To learn more and visualize the differences between both options, read our
304 Not Modified article.
However, if you choose to use
Last-Modified header, which validates the component based on a timestamp, you can simply remove the
ETag and use
Last-Modified in conjunction with
Cache-Control. In Apache, removing etags is done by adding the following to your configuration file.
Header unset ETag FileETag none
Doing so completely removes the
ETag header which also reduces the overall HTTP header size. In any case, using
Last-Modified headers are both valid options in regards to improving browsing cacheability and website speed.