How to make your web site more cacheable, for:

• better performance
• lower bandwidth requirements

Recognize the drawback, which is that it makes it harder to get an accurate count of visitors to your site. This can be circumvented with little impact on performance by embedding a one pixel image that is not cacheable. (Recognize though, that the one pixel image technique is used by others for less benign purposes, you may want to embed a reasonable size image (viewable) with an explanation of why it's there.)

I should invent such an image, maybe a stylized circle, c (for "count"), or similar — a small number of bytes to transmit, but something that becomes well recognized as a "benign" use of the embedded image technique.

See:

• About These Pages

Contents

Notes

Resources

See Resource Recommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including Guidelines_for_Rating_Resources.

Recommended

• Internet: Caching: Cachebusting - cause and prevention; draft-hamilton-cachebusting-01.txt; ; mdash; Looks like a good source of techniques to make a web page more cacheable, especially see sections 3.2 and 3.3:

3.2 Tips for content providers (e.g. HTML authors)

Encourage the sharing of links to common graphics and applets, so that only one URL is used for a given object.

Use client-side imagemaps (USEMAP - [8]) where feasible, since server-side imagemaps generate HTTP Redirects which are typically uncacheable.

Use trailing slashes (/) for directory names to avoid extra redirects.

Where you are using a file which is returned when the directory name is requested (typically index.html or index.htm) "./" can usually be written instead of referring to the file by name.

Try to use a single name for a server in the hostname part of the URL in the HTML which you create.

Don't rename files to age them - give them unique names in the first place and update the links which point to them.

Use the Internet domain name in the host component of the URLs you create, rather than the host's IP address.

If you really want to count every access to a given page, embed a tiny non-cacheable image into it. This will give you an access count for the page without requiring the whole thing to be downloaded again by each user of given proxy cache.

3.3 Dynamic content (e.g. CGI) developers

Make results cacheable where practical :-

• Use GET instead of POST for simple queries, since POST results aren't cached.
• Use the path component of the URL to pass information instead of QUERY_STRING - caches may treat objects with a ? in their URL as uncacheable.
• Use a directory name other than "cgi-bin", since caches can be expected to treat URLs containing this as uncacheable.
• Generate valid Last-Modified and Expires headers.
• Handle If-Modified-Since requests.

Use applet and scripting technologies such as Javascript or Java instead of CGI for form validation, where feasible.

If you use cookies, try to restrict them to the portions of your server where they're essential, since objects returned with a Set-Cookie header are commonly treated as uncacheable. Be aware that cookies may not interact well with proxy cache severs.

Try not to parse the HTTP USER_AGENT header to select browser specific capabilities, since the cached HTML will be browser specific, and may be returned to a browser which doesn't know what to do with it. Use features like <NOFRAMES> instead.

Don't use server-side includes unless your server can send the Last-Modified HTTP header with them.

Don't use redirects, since their results may be uncacheable.

Try to keep the size and complexity of pages on secure servers to a minimum, since secure HTTP requests are not cached in proxy caches and may not be cached in many browsers. Try to avoid using secure servers for general pages where feasible.

Don't set the objects your server returns to expire immediately,

or at some time in the recent past, unless you want to be held up to public ridicule!

Don't use content-negotiation until HTTP 1.1 is more widely deployed, since in HTTP/1.0 it interacts badly with proxy caches.

Don't specify port 80 in the URL, e.g. when generating URLs programatically.

Don't use server modules or scripts to convert document's character set on the server side. Leave it to the client.

• (rhk) [[][]]; ; ; —

Contributors

• () RandyKramer - 06 Oct 2003
• If you edit this page: add your name here; move this to the next line; and if you've used a comment marker (your initials in parenthesis), include it before your WikiName.

Revision Comment

• %DATE% —

Page Ratings