Caching with Nginx

General information

What is a cache?

A cache is temporary storage that makes accessing data from memory more efficient. This means that a range of requests can be responded to directly without any computation being required. The result of initially computing the request is stored in the cache and can therefore be delivered faster. It should be noted that there are different types of cache. For web applications, these are primarily the server cache (in this case, the Nginx cache), the application cache and the browser cache.

On the server side, it is predominantly dynamic content that benefits from caching, as this usually has to be generated in a complex way and is often linked to database requests in the background.

Nginx cache with Hostpoint

With Hostpoint, you can use Nginx as a server-side HTTP cache in shared hosting (Smart and Business web hosting) and with all Managed Flex Server packages. Nginx can be enabled in addition to the Apache web server in shared hosting in order to cache dynamic content. Nginx can also be run as a web server and cache in front of your own application on Managed Flex Servers from size ‘M’.

Caching can be enabled and configured for all products in the Hostpoint Control Panel website settings. Whether and for how long content can be cached is normally determined via the HTTP header.

HTTP header

Using the right HTTP header is crucial for caching. It tells all possible caches whether content can be stored in the cache and for how long. Headers don’t just influence how a server-side cache like Nginx behaves – they also control how intermediary proxies and ultimately the browser cache behave. ‘Cache-Control’ and ‘Expire’ are examples of HTTP headers that influence caching.

Requests without a corresponding header are normally not cached. This is the case with Hostpoint, particularly for Nginx, unless this is expressly configured in the Hostpoint Control Panel.

The Hostpoint Nginx cache only stores dynamic content by default because static content can normally be delivered directly from the fast file system cache. Nevertheless, it can still be useful to set corresponding HTTP headers for static content such as images, for example, because this allows the browser to store this content in the local cache for longer.

Useful cache content and times

Before you configure the cache and adjust your web application, you should think about what you want to store in the cache and for how long. The cache is normally controlled via HTTP headers (see above).

We recommend keeping the cache duration short for content that changes frequently. This is important for a news page, for example, because changes would otherwise only be visible after the cache expires. But websites that are rarely adjusted can be stored in the cache for much longer.

It should also be noted that initial access after the cache has expired can take a little longer because the page has to be recomputed. We therefore recommend following this guideline: set the cache for as long as possible but as short as necessary.

Please note that although it is possible to empty the Nginx cache in the Hostpoint Control Panel, this does not affect any proxies or the browser cache. As such, actively emptying the Nginx cache only helps to a limited extent if content is allowed to be cached for too long.

Password-protected areas

Essentially, areas that have Nginx password protection are not cached for security reasons.

Emptying the cache

In some cases, it is advisable to empty the Nginx cache in the Hostpoint Control Panel. For example, if adjustments have been made to a website but these are not yet visible and the browser cache and the application cache have already been emptied. Certain Nginx plugins for CMS such as WordPress also give you the option of clearing the Nginx cache. However, these are not supported by Hostpoint, which is why the cache must always be emptied via the Hostpoint Control Panel if necessary.

Enabling and configuration

We will explain the steps you have to take to enable caching for your website in the sections below.

Default website settings

One requirement for caching is that your website has to be configured with Nginx as the primary web server. You can specify this when creating a new website in the Hostpoint Control Panel. If you have an existing website, you have to edit it and click on ‘Change default settings’ to enable Nginx.

In both cases, you have to select a use case that supports caching:

• Nginx (proxy) with Apache/PHP
• Nginx with your own application (available from Managed Flex Server M)

The use case ‘static website with Nginx’ uses Nginx, but additional caching would not be of any benefit and is therefore not available as it only supports static content that is already covered by the fast file system cache.

Enabling and configuration caching

As soon as the basic configuration of your website has been adjusted so that Nginx is used as the primary web server and caching is generally supported, you also have to expressly enable this in the Hostpoint Control Panel website settings. You can find the corresponding options in the ‘Proxy settings’ area.

After enabling the cache, please note that requests are only stored in it if your application (e.g. your CMS) allows this via the HTTP header. By default, Nginx does not store any requests that don’t have these headers. You can change this behavior using the ‘Fallback behavior’ setting and specifying that content without a corresponding header should still be cached. This, however, should only be done in exceptional cases. Use of the HTTP header is usually the preferred method for web applications as this gives you better control over what should be stored in the cache and for how long. This setting has no influence over content with HTTP headers.

From Managed Flex Server M, you also have the option of specifying whether both dynamic and static content should be stored in the cache. We normally recommend only allowing dynamic content for Nginx caching as it is mainly only dynamic content that benefits from caching. Static content is already cached very efficiently by the file system and would only unnecessarily fill up the Nginx cache.

Adjusting web applications

For caching to work, your application must set HTTP headers. These tell Nginx whether the corresponding content can be stored in the cache and for how long. If no such headers are set, Nginx does not save anything in the cache by default. You can change this behavior by configuring the cache’s ‘fallback behavior’, but this is not normally recommended. You should ensure that your web application sets the appropriate headers for content that can be cached.

Plugins for most the common CMS exist that can do this for you. You can find some examples below:

Wordpress:

• WP Super Cache
• WP Rocket (for a fee)
• W3 Total Cache

Joomla:

• Speed Cache (for a fee)
• Server Cache

For self-written applications, it may be necessary to make changes to the code so that the headers can be set correctly. In certain cases, headers can also be set via .htaccess.