HTML and CSS Reference
In-Depth Information
HTTP Caching
The most prevalent client-side caching approach is HTTP caching in the browser. When the browser requests a file
over HTTP, it takes time to download the file. Once the file has been downloaded, the browser can store it in its local
cache. This means for subsequent requests for that file the browser will refer to its local cached copy. This technique
eliminates the server request and the need to download the file. It has the added bonus that you will receive fewer
server requests, which may save you money in hosting costs. This technique takes advantage of the fact that most
game assets are static content, changing infrequently.
When a HTTP server sends a file to a client, it can optionally include metadata in the form of headers, such
as the file encoding. To enable more fine-grained control of HTTP caching in the browser requires the server to be
configured to provide headers with caching information for the static assets. This tells the browser to use the locally
cached file from the disk instead of downloading it again. If the cached file doesn't exist or the local cache has been
cleared, then it will download the file. As far as the game is concerned, there is no difference in this process except
that the cached file should load quicker. The behavior of headers is categorized as
conditional
and
unconditional
.
Conditional means that the browser will use the header information to decide whether to use the cached version or
not. It may then issue a conditional request to the server and download if the file has changed. Unconditional means
that if the header conditions are met and the file is already in the cache; then it will return the cached copy and it
won't make any requests to the server. These headers give you varying levels of control for how browsers download
and cache static assets from your game.
The HTTP/1.1 specification allows you to set the following headers for caching.
•
Unconditional:
•
Expires: HTTP-DATE
. The timestamp after which the browser will make a server request
for the file even if it is stored in the local cache. This can be used to stop additional
requests from being made.
•
Cache control: max-age=DELTA-SECONDS
. The time in seconds since the initial
request that the browser will cache the response file and hence not make another
request. This allows the same behavior as the Expires header, but is specified in a
different way. The max-age directive overrides the Expires header so only one or the
other should be used.
•
Conditional:
•
Last-Modified: HTTP-DATE
. The timestamp indicating when the response file was last
modified. This is typically the last-modified time of the file on the filesystem, but can
be a different representation of a last modified date, for example the last time a file was
referenced on the server, even if not modified on disk. Since this is a conditional header, it
depends on how the browser uses it to decide whether or not a request is made. If the file
is in cache and the HTTP-DATE was long ago, the browser is unlikely to re-request the file.
•
ETag: ENTITY-TAG
. An identifier for the response. This can typically be a hash or some
other method of file versioning. The ETag can be sent alongside a request. The server
can use the ETag to see if the version of the file on the client matches the version on the
server. If the file hasn't changed, the server returns a HTTP response with a status code of
304 Not Modified. This tells the client that a new copy of the file is not required. For more
The ability to control caching settings is not always available from every server and behaviors will differ
depending on the server. It is worth referring to the documentation to discover how to enable and set these headers.
