General information about server-side caching

Server-side caching allows properly configured web software to speed up page delivery by having the server cache its web content. When server-side caching is enabled, all external GET and HEAD requests are sent to an NGINX reverse proxy for caching. The system will attempt to cache primarily dynamic content on a best effort basis.

The NGINX reverse proxy creates a cache entry based on the scheme, hostname, request_uri and query_string variables. NGINX takes into account the Vary response header and creates a separate cache entry for each variation of a property defined in a Vary header. For example, if your software sets a "Vary: User-Agent" response header, NGINX will create a separate cache entry for each user agent that loads the particular page.

Please note that not all content gets cached. A GET or HEAD request will not be cached if:

There is no Cache-Control HTTP response header set.
There is a Cache-Control HTTP response header set to Private, No-Cache, or No-Store.
There is a Set-Cookie HTTP response header set.
There is an Expires HTTP response header set, but the expiration cannot be determined.

IMPORTANT: If your site/software relies on Apache configuration directives in .htaccess files or other dynamic filtering, please use server-side caching with caution, as cached dynamic content will not follow any .htaccess directives when served. For example, if part of your content is password-protected or restricted by IP address (using an .htaccess file or through the Protection section of the Control Panel), when cached successfully, this content will be visible to non-authorized parties as well. In such cases, the use of server-side caching is not recommended, unless your software uses proper HTTP cache control headers to avoid caching of sensitive dynamic content.

If you have made some changes to your content that have been cached, and you don't want to wait for the cache to expire automatically, you can purge the cache manually. More details on the available options to do this are listed in our Purging the server-side cache article.


	Online Manual » Control Panel » Server-side Caching » General information about server-side caching General information about server-side caching Server-side caching allows properly configured web software to speed up page delivery by having the server cache its web content. When server-side caching is enabled, all external GET and HEAD requests are sent to an NGINX reverse proxy for caching. The system will attempt to cache primarily dynamic content on a best effort basis. The NGINX reverse proxy creates a cache entry based on the scheme, hostname, request_uri and query_string variables. NGINX takes into account the Vary response header and creates a separate cache entry for each variation of a property defined in a Vary header. For example, if your software sets a "Vary: User-Agent" response header, NGINX will create a separate cache entry for each user agent that loads the particular page. Please note that not all content gets cached. A GET or HEAD request will not be cached if: There is no Cache-Control HTTP response header set. There is a Cache-Control HTTP response header set to Private, No-Cache, or No-Store. There is a Set-Cookie HTTP response header set. There is an Expires HTTP response header set, but the expiration cannot be determined. IMPORTANT: If your site/software relies on Apache configuration directives in .htaccess files or other dynamic filtering, please use server-side caching with caution, as cached dynamic content will not follow any .htaccess directives when served. For example, if part of your content is password-protected or restricted by IP address (using an .htaccess file or through the Protection section of the Control Panel), when cached successfully, this content will be visible to non-authorized parties as well. In such cases, the use of server-side caching is not recommended, unless your software uses proper HTTP cache control headers to avoid caching of sensitive dynamic content. If you have made some changes to your content that have been cached, and you don't want to wait for the cache to expire automatically, you can purge the cache manually. More details on the available options to do this are listed in our Purging the server-side cache article.