ETags! Or entity tags, if you prefer to make them sound less like a system for keeping tabs on alien beings. There’s a reasonable chance that even if you’re a techy SEO you might not have heard of these or, if you have, exactly what they do and whether they do a good job of it. I’m working an awful lot on site speed for a number of clients recently and these are an oft-forgotten element that sit roughly under the category of web caching.
Oft-forgotten because PageSpeed Insights doesn’t mention them despite having a “Leverage browser caching” section – and this tool is generally Point A for anybody looking to brush up a given page’s speed.
So what is an ETag and why on earth should you care about it?
Well, it’s a mechanism that HTTP provides for web cache validation – specifically it allows for a client to make a request that is conditional on whether the content it’s requesting from the server has changed or not. If it hasn’t changed, then this allows the resource to be fetched from cache more efficiently, saving bandwidth.
The method by which an ETag does this is as follows; each entity tag acts as a unique identifier for its resource – this identifier is made up of 3 values:
So put that all together and you end up with a unique identifier made up of 3 parts. Exactly what it looks like will depend on your server configuration.
So the resource attached to that ETag has been requested – the server reads that unique identifier and, if it hasn’t changed, sees that the file hasn’t been modified and draws it from cache instead. If the ETag *has* changed then the client knows that to return the correct resource then it must re-download it from the server, rather than use the cached version.
Yeah, doesn’t it. The only problem is that if your ETags are mis-configured then the test to see whether the resource has changed will *always* fail, leading to un-changed resources being drawn from the server rather from cache.
This is a common issue on sites that are being served from multiple servers, such as those utilising a CDN or other (perhaps cookie-less) domains. The inode (the first part of that identifier) will differ from server to server, and therefore invalidate the cache – returning a 200 OK status code rather than the small, fast 304 Not Modified we were hoping for. Due to this, even if your components have a Far-Future expiration header, a GET request is still going to be made whenever the user refreshes.
Luckily ETags are quite easily removed.
Once removed you can rely on the Last-Modified header – they both serve the same purpose and simply using the latter will reduce the header size of your response.
Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT