Examples

The following two examples demonstrate the performance improvement achieved by using a far future Expires header. Both examples include the same components: six images, three scripts, and one stylesheet. In the first example, these components do not have a far future Expires header. In the second example, they do.

Adding the far future Expires header drops the response time for subsequent page views from ~600 milliseconds to ~260 milliseconds, a 57% reduction when tested over DSL at 900 Kbps. With more components in the page, response times improve even more. If your pages average more than six images, three scripts, and one stylesheet, your pages should show a speed up greater than the 57% I found in my example.

Where exactly do these response time savings come from? As I mentioned earlier, a component with a far future Expires header is cached, and on subsequent requests the browser reads it straight from disk, avoiding an HTTP request. However, I didn't describe the converse. If a component does not have a far future Expires header, it's still stored in the browser's cache. On subsequent requests the browser checks the cache and finds that the component is expired (in HTTP terms it is "stale"). For efficiency, the browser sends a conditional GET request to the origin server. See Chapter 2 for an example. If the component hasn't changed, the origin server avoids ...

Get High Performance Web Sites now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.