Issue link: https://read.uberflip.com/i/1146286
ETags in the Real World | 95 HTTP/1.1 304 Not Modified ETag: "80b31d5a4776c71:6e0" Last-Modified: Tue, 03 Apr 2007 23:25:23 GMT On the second reload, the ETag changes to 80b31d5a4776c71:47b. Instead of a fast 304 response with no content, a larger 200 response with the full content is returned. GET /br/hp/en-us/css/15/blu.css HTTP/1.1 Host: stc.msn.com If-Modified-Since: Tue, 03 Apr 2007 23:25:23 GMT If-None-Match: "80b31d5a4776c71:6e0" HTTP/1.1 200 OK Last-Modified: Tue, 03 Apr 2007 23:25:23 GMT ETag: "80b31d5a4776c71:47b" Content-Length: 647 Server: Microsoft-IIS/6.0 Even though the ETag changed, we know this is the same component. The size (647 bytes) is the same. The last-modified date (03 April 2007 23:25:23) is the same. The ETags are almost the same. Let's look at the ETag headers more closely: ETag: "80b31d5a4776c71:6e0" ETag: "80b31d5a4776c71:47b" The Server header in the response confirms that this is from IIS. As described ear- lier, the default ETag format for IIS is Filetimestamp:ChangeNumber. Both ETags have the same value for Filetimestamp (80b31d5a4776c71). This isn't a surprise because the Last-Modified header shows that both components have the same modification date. The ChangeNumber is the part of the ETag that differs. Although disappointing, this also isn't a surprise because, as stated in the Microsoft Support articles referenced earlier, this is precisely what causes the performance issues. Removing ChangeNumber from the ETag or removing the ETag altogether would avoid these unnecessary and inefficient downloads of data that's already in the browser's cache. Reconfigure or remove ETags.