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.
- No Expires
- Far Future Expires
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.