A-Z glossary of PageSeeder concepts


There are multiple levels at which PageSeeder utilizes caching to improve performance. This entry is specifically oriented to HTTP caching.

Cache-control is an HTTP header value used by both the user agent (the browser) and the server (and proxy servers) to control how the browser will cache content served by PageSeeder. This can optimize performance and conserve bandwidth.

PageSeeder uses two types of cache control, depending on the type of resources being requested.

Volatile resources

For all the HTML returned by the Layout Manager, PageSeeder explicitly disables browser caching with the following HTTP response headers:

Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache

The 'Cache-Control' header with a value of 'no-cache' prevents caching by browsers and proxies ensuring that the user always gets a fresh copy directly from the server.

The 'Expires' header is only needed for old proxy servers which do not support HTTP/1.1

While this configuration ensures currency of resources, it is costly in terms of bandwidth and CPU and should not be used when it isn't necessary.

Static resources

For static resources (i.e. CSS, JavaScript, and some images), PageSeeder uses HTTP response headers that allow caching by browsers and proxy servers.

For example:

Expires:        Fri, 03 Jun 2011 05:02:07 GMT
Cache-Control:  max-age=86400, must-revalidate
Etag:           W/"4845-1267586931000-gzip"

The 'Cache-Control' header tells the browser that the resource can be cached for up to 86400 seconds (= 24 hours), then it must be checked for currency (revalidated).

Revalidation is done by the client returning the Etag from the original header back to the server.

The 'Expires' header is only needed for old proxy servers which do not understand HTTP/1.1, and should be overridden by the Cache-Control.

When the PageSeeder Server re-validates a resource (and the request is successful), it will either return:

200 (OK)Including the content if the resource is new or the server is unable to determine whether the browser has a copy.
304 (Not Modified)Headers without the content assuming that the browser has a copy.

The browser will not attempt to connect to the server while the resource is considered fresh.

See also Hypertext Transfer Protocol -- HTTP/1.1 .

Browser reload

Following are the different ways the browser retrieves resources. These are dependent on the action from the user.

Link or
URL in address bar

Retrieves the resource in the most efficient manner: from cache if possible, otherwise from the server. Sends an Etag if one is available for the resource.

Reload or 
F5 or 

Asks the server to revalidate the cached copy. This request to the server contains the HTTP  header 'Cache-Control: 0'

SHIFT+Reload or
 CTRL+F5  or 

This expects the browser to discard the cached resource and request a new version from the server, forcing a reload. The HTTP headers include 'Cache-Control: no-cache' to ensure that no cache copy is given by intermediaries.

Created on , last edited on