July 19, 2010 at 11:17Internet Explorer 9 Caching Enhancements
- Transfer
The web plays a key role in the overall performance of the web browser. The best way to increase network performance is to reduce the amount of traffic transmitted over the network using HTTP compression and using browser caching.
We have made a huge number of improvements in how Internet Explorer 9 caches data in order to increase the use of resources from the cache. This post describes these improvements that are already available in the third version of IE9 Platform Preview , which was released last month .
The essence of caching
Let's start with a quick description of how caching works in browsers. At the highest level, browsers perform two types of HTTP (S) requests - conditional requests and unconditional requests.
Unconditional requests are created when the browser does not have a cached copy of the resource. In this case, the server is expected to return a resource with an HTTP / 200 OK response . If the response headers separately do not prohibit this, the client can cache the content and use it in the future.
If in the future the browser needs a resource that is in the local cache, then the resource headers are checked to see if the resource remains relevant. If the cached copy is current, then requests to the resource on the network will not be made and the client simply uses the copy from the cache.
If the cached resource is outdated (older than the max-age header or later than the Expires date ), the client will make a conditional request to the server to determine whether the previously cached resource is relevant and whether it can be used. The conditional request contains the If-Modified-Since and / or If-None-Match headers that show the server which version of the content is already on the client. The server can determine that the client version is still relevant by returning an empty response with the HTTP / 304 Not Modified header, or it can indicate to the client that its version is outdated by returning a response with the HTTP / 200 OK header and new content.
Obviously, conditional requests lead to better performance compared to unconditional requests (since the server does not need to forward the resource if the client already has the current version), however, better performance is achieved when the client knows which version in its cache is relevant and conditional revalidation is not performed at all .
Extremely long headings
Although RFC2616 recommends that servers limit the lifespan of content to one year, some servers specify Cache-Control directives with a significantly longer period. Prior to IE9, Internet Explorer declared obsolete all resources whose lifetime ( Cache-Control: max-age value ) was more than 2147483648 (2 ^ 31) seconds, approximately 68 years.
In the ninth version of IE, we accept any set max-age value up to 2 ^ 63, although inside we reduce it to 2 ^ 31 seconds.
Vary parameter improvements
The Vary HTTP / 1.1 response header allows the server to indicate that the actual cached resource can be used without re-validation only if the headers specified in the Vary match the request headers.
For example, this allows the server to return English content with the title Vary: Accept-Language. If the user later changes the Accept-Language value from en-US to ja-JP in his browser , the previously cached content will not be used, since the Accept-Language header no longer matches the value that was saved when caching the resource in English.
In IE9, we improved support for key Vary use cases. So, IE9 no longer requires server-side validation for responses that contain Vary: Accept-Encoding and Vary: Host directives .
We can safely support these two directives for the following reasons:
- all requests are explicitly dependent on Host because the host is a component of the request URL;
- IE always decompresses HTTP responses into the cache, which makes Vary: Accept-Encoding redundant.
If the response contains a Vary directive that specifies a header or header combinations other than Accept-Encoding , Host, or User-Agent , then Internet Explorer will continue to cache the response if the response contains an ETAG header. However, such a response will be marked outdated and a conditional HTTP request will be made before using it in order to determine the relevance of the cached copy.
Redirect Caching
IE9 now supports caching responses with an HTTP redirect, as described in RFC2616. Responses with a permanent redirect (with status 301) will be cached until they contain headers prohibiting this (for example, Cache-Control: no-cache ) and those requests that have the status of a temporary redirect (302 or 207) will also be cached, if the headers allow this (e.g. Cache-Control: max-age = 120 ).
Despite significant performance improvements, web applications that are not properly configured may not work as expected after these improvements. For example, we found several public sites that use patterns similar to the following:
> GET / HTTP / 1.1
<301 Redirect to /SetCookie.asp
> GET /SetCookie.asp HTTP / 1.1
<301 Redirect to /
Here, the purpose of the site is to set a cookie using the sub page, if it is not set. The problem is that the server chose 301 for this task and 301 is cached. As a result, IE will simply perform redirects on the client side without accessing the server until the user is bored and the browser closes. Please note that this endless loop will also occur if cookies are prohibited in the user's browser.
If your site creates redirects, you must make sure that they are configured to avoid looping and verify that specific redirects (for example, to set cookies) are marked as non-cacheable.
HTTPS Caching Enhancements
A few months ago, I mentioned that IE will not reuse previously cached resources received through HTTPS until at least one secure connection is established for the current process. This can lead to the fact that previously saved resources will be ignored, which will lead to unconditional network requests for content, although it is already in the cache.
In IE9, optional HTTPS cross-host requests will now be conditional, so the server can simply return an HTTP / 304 Not Modified response for immutable content. Although a request remains, a significant increase in performance can be achieved since the server does not need to transfer the resource to the client.
Optimizing Forward / Backward Functions
In IE9, we made a number of improvements so that the Forward and Back buttons lead to fast loading.
RFC2616 specifically indicates that the forward / reverse mechanism of browsers should not be subject to caching:
History and caching mechanisms are different mechanisms. In practice, history mechanisms should not attempt to show the current state of a resource. On the contrary, the mechanisms of history should show exactly what the user saw while visiting the resource.
By default, the expiration time of a resource’s relevance should not matter for history mechanisms. If the entity remains in the repository, the history mechanism should display it, even if the entity is expired, until the user specifically configures the agent to update expired documents.
In previous versions of IE, when a user went forward or backward, IE checked for resource updates if they were sent with a must-revallidate cache directive and depending on some other parameters of how the resource was received. IE9 uses the flag INTERNET_FLAG_FWD_BACK and IE will not check the relevance of cached resources when a user moves forward / backward.
As a result of this optimization, Internet Explorer 9 can make significantly fewer conditional HTTP requests during forward / backward functions. For example, the following table shows the performance increase over the previous behavior:
| - | IE8 | IE9 | Improvement |
| Forward / Backward Navigation | Number of requests: 21 Bytes transmitted: 12,475 Bytes received: 216,580 | Number of requests: 1 Bytes transmitted: 325 Bytes received: 144,617 | Number of requests: -20 (-95%) Bytes transmitted: -12,150 (-97.4%) Bytes received: -71,963 (-33.3%) |
After I talked about the fact that we ignore caching directives during forward / backward navigation, attentive readers may ask why IE9 still makes one request when the user clicks the back button. The reason is that IE does not send any cached resources to the cache. Cached resources are delivered with the Cache-Control: no-cache directive or with an Expires date value in the past or when the Expires date is no later than the value of the Date header . For this reason, the browser has to reload such resources when the user goes forward / backward. To increase performance and create the ability to load a resource into the cache when navigating forward / backward, simply replaceCache-Control: no-cache on Cache-Control: max-age = 0, in this case re-validation will occur in all cases except for forward / backward navigation .
Unlike the other improvements that we described, the improvement in the “forward / backward” operation cannot be observed in the preview version of Internet Explorer 9 Platform Preview, since there are no forward / backward buttons in it .
Enhancements to Caching Heuristics
According to the recommendations, web developers should explicitly indicate the expiration time of their resource so that browsers can reuse the resources without having to make conditional HTTP re-validation requests to the server. However, many sites deliver content without information about the expiration of the validity period, leaving the browser discretion to care about the relevance of the resource.
IE allows users to configure what should happen to content that is received without relevance information. In the Tools> Internet Options> Browsing history> Settings, you can find four options:
These options offer the following behavior:
| Every time I visit the webpage | Resources without explicit information on the time of relevance are marked as obsolete and will be re-allocated with the server before each use. |
| Every time I start Internet Explorer | Any resource without explicit information on the time of relevance validates with the server at least once per session (and every 12 hours in this session) |
| Automatically (Default) | IE will use heuristics to determine relevance |
| Never | Any cached resource will be marked as current and will not be revalidated. |
These options control the behavior of the browser only when the content is received without information on the period of relevance. If the content is specified with an explicit rule (for example, Cache-Control: max-age = 3600 or Cache-Control: no-cache ), then the browser will use these server rules and the specified options will have no effect.
In previous versions of IE, automatic heuristics were simple and only affected cached images , but improvements were made to heuristics in IE9 according to RFC2616:
If the response contains the Last-Modified value, then the heuristic value of the relevance time should not exceed the interval from this time value. A typical value should be 10% of this interval.
If IE9 receives a resource that can be cached without a set expiration date, the heuristic value of the expiration date is calculated as follows:
max-age = (DownloadTime - LastModified) * 0.1
If the Last-Modified header is not in the server response, then IE will apply the revalidation behavior “ Once per browser session ”(once per session).
As a result of improved heuristic caching, IE9 can produce fewer conditional HTTP requests when reloading most of the pages. For example, the following table shows the improvement obtained by visiting a regular article on a popular site:
| - | IE8 | IE9 | Improvement |
| Revisiting in a new browser session (PLT2) | Number of requests: 42 Bytes transmitted: 26050 Bytes received: 220681 | Number of requests: 2 Bytes transmitted: 1134 Bytes received: 145217 | Number of requests: -40 (-95.3%) Bytes transmitted: -24916 (-95.6%) Bytes received: -75464 (-34.2%) |
The caching inspector in Fiddler will show you when the response is no longer relevant, based on the response headers. For example, below what you see in the answer, which contains the ETAG and the Last-Modified header, but does not contain information on the period of relevance:
Other network improvements
In this post, I have listed improvements in the caching code of Internet Explorer that help make sure that websites are making the best use of the network. Of course, web developers should continue to follow the guidelines and specify caching behavior using the Expires and Cache-Control headers, but even if sites do not do this, they will still load significantly faster in IE9.
In the following articles, I will describe other improvements that we made in the IE9 network stack to load pages even faster.
