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.

Please refer to our Enabling server-side caching for WordPress article for detailed instructions on how to properly set up your WordPress installation to take full advantage of the server-side caching service.

The server-side cache will be purged (deleted) automatically when it expires. If you have made some changes to your content that have been cached, you can clear the server-side cache manually by using either of the following methods: Control Panel's Server-side Caching section cURL via the command line cURL via PHP Note: Some software applications can be configured to detect content changes and purge the server-side cache automatically for you. You can find step-by-step instructions for WordPress and Drupal in our Enabling server-side caching for WordPress and Enabling server-side caching for Drupal articles. Control Panel's Server-side Caching section To manually purge the server-side cache for a specific domain/subdomain, go to the Server-side Caching section of the hosting Control Panel and click on the Purge button next to the domain/subdomain name. cURL via the command line You can purge the server-side cache for your domain/subdomain (e.g. http://your_domain.com) manually by using the following command: curl -X PURGE http://your_domain.com Using the command below will delete only the server-side cache for the specified page/directory (e.g. http://your_domain.com/your_page) curl -X PURGE http://your_domain.com/your_page You should execute the commands listed above from your hosting account via SSH. To be able to do this, you need to make sure that Network tools are enabled for your account through the hosting Control Panel's SSH Access section. More details on how to connect via SSH to your account are available in the SSH article from our online documentation. cURL via PHP Add the code block listed below to a PHP file (e.g. purge_cache.php) in your website directory using the hosting Control Panel's File Manager section: <?php// Prevent caching for this scriptheader("Cache-Control: no-cache");// Get the protocol and hostname$protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443) ? "https://" : "http://";$host = $_SERVER['HTTP_HOST'];// Set the URL using the protocol and hostname$url = $protocol . $host;// Create a new cURL resource$ch = curl_init();// Set the URLcurl_setopt($ch, CURLOPT_URL, $url);// Set the request method to PURGEcurl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PURGE");// Attempt to clear the cache and print the resultecho (curl_exec($ch) ? "Successfully purged" : "Unable to purge") . " the server-side cache for " . $host . "!";// Close cURL resource, and free up system resourcescurl_close($ch);?> To purge the cache for your domain/subdomain, you have to simply access the file you created via a browser (e.g. http://your_domain/purge_cache.php).

Server-side caching may help reduce page load times by a significant margin if configured properly. You can learn more about the server-side caching service available on our servers in the General information about server-side caching article. To take advantage of server-side caching on a Drupal 8/9/10 website, you need to: Configure Drupal 8/9/10 to cache content Choose how to clear the cache Enable server-side caching 1. Configure Drupal 8/9/10 to cache content By default, Drupal 8/9/10 allows you to specify for how long the cache should be stored via the max-age and Cache-Control headers. You can select your preferred caching period via the Caching menu from the Administration -> Configuration -> Development -> Performance section. We would recommend that you set the caching period to 1 year for best results after enabling the server-side caching. 2. Choose how to clear the cache To have Drupal 8/9/10 clear the cache automatically when you make any changes to your website content, please follow these steps: Extend your Drupal 8/9/10 installation by adding the Purge and Generic HTTP Purger modules. Install the following components:• Purge module - Purge, Purge Tokens, and Purge UI components• Purge - Processors module - Late runtime processor component• Purge - Queuers module - Core tags queuer component• Purge - reverse proxies & CDNs module - Generic HTTP Purger and Generic HTTP Tags Header components Navigate to the Administration -> Configuration -> Development -> Performance section, and select the Purge tab that is now available. Click on the add purger button from the Cache Invalidation menu. Select the HTTP Purger radio button from the pop-up window that appeared. Click on the Add button. A new purger will appear above the add purger button. Open its menu by clicking on the downward pointing arrow on the button, select the Configure option, and a new window will pop up. Enter a name that describes the purger (e.g. Cache purger) in the Name field. In the Request tab, enter the following settings:• Hostname: your_domain.com (Make sure you replace your_domain.com with the actual domain/subdomain where Drupal 8/9/10 is installed)• Port: 80 (default value)• Path: / (default value)• Request Method: BAN (default value)• Scheme: http (default value)Note: If your Drupal 8/9/10 installation is configured to always work over HTTPS, you should change the Port setting to 443 and the Scheme to https. In the Headers tab, enter the following settings:• Header: Purge-Cache-Tags• Value: [invalidation:expression] Alternatively, you can purge the server-side cache for your domain/subdomain manually by using any of the methods provided in our Purging the server-side cache article. Note: If you do not configure Drupal 8/9/10 to clear the cache automatically when content is changed, the Clear all caches button from the Administration -> Configuration -> Development -> Performance section will clear its local cache, but the server-side cache will not be cleared. 3. Enable server-side caching Once you have prepared Drupal 8/9/10 for server-side caching, you can enable the server-side caching service by going to the hosting Control Panel's Server-side caching section and clicking on the Enable button next to the domain/subdomain where Drupal is installed.