Caching

If your website or application is loading slowly, caching can reduce the load on the server and speed up your performance. If we manage your Webslice Containers, you can control caching from within the Webslice Console in two ways:

• Use a single button to switch on a powerful feature we call Simple Cache.
• Manually control your cache settings through cache-control headers, then use the Webslice Console to switch caching on or off.

If your Container is unmanaged, caching will not be an option in the Webslice Console.

How Caching Works

The simple idea behind caching is to store a static copy of content. When a user requests this content, the cached copy is quicker to retrieve.

When you manage cache settings, you control which content is cached, and how long for.

How to Enable Simple Cache

Simple Cache is a powerful feature that replaces complexities of caching with a single button. If your Webslice Containers are managed by us, they will each have a Simple Cache switch in the Webslice Console.

Manual Cache Settings

Caching on the Webslice Containers platform is designed to be safe and conservative. The system will only cache content that is specifically defined by your application’s HTTP cache-control headers. This makes these headers absolutely crucial.

Anything you don’t want cached (places where users need to log in, for example, or pages like shopping carts that rely on live updates) can send a no-cache header and also be added to your Ignored Paths.

How to Set Up Your Application For Caching

Cache control headers are absolutely crucial, so set them up first.

It’s a good idea to start by excluding all the content that should not be cached. By doing this from the start you’ll avoid potential security risks.

The cache-control headers specify which content will be cached. Where you want no caching, the header should look like this:

cache-control: no-cache, max-age=0

On the other hand, static content like standard home pages can be safely cached. If you wanted the cached copy to be held for a full day, you would pass a cache control headers similar to this:

cache-control: max-age=86400

For more about cache control headers, we recommend reading MDN Web Docs.

Tip

After you have configured your application to handle caching you might still get a MISS for the X-Cache-Status. This happens when your application’s sessions setting is causing the proxy to not cache any responses.

WordPress

WordPress is configured for secure caching management. It also uses cache-control headers to disallow caching when you are logged in.

Drupal

1. As an admin user, navigate to Configuration > Performance.
2. Set the lifespan to the desired value or, if you have set it already, the same value entered through the Webslice Console.
3. After you have set the lifespan, click Clear all caches to empty Drupal’s internal cache.

Craft

Craft’s documentation on headers in Twig templates shows you how to handle cache control headers.

For any page you want cached, modify the template to include a line similar to:

{% header "Cache-Control: max-age=86400" %}

Grav

There are two ways of implementing the cache control headers in Grav:

• Define a global setting through Grav’s admin control panel, or
• Take a granular approach and define each page’s cache lifespan inside the markdown for that page. For this option, have a look through the Grav docs on HTTP Headers.

If you implement cache-control on pages individually, the line to add will look like this:

cache_control: max-age=86400.

Silverstripe

Silverstipe’s CMS Docs take you through the process of using the HTTPCacheControlMiddleware class to set cache control headers.

By default, SilverStripe sets cache control headers that discourages caching. Even if you enable caching through the Webslice Console, these defaults can apply.

To enable caching globally:

1. Open the PageController.php file for editing.
2. Below the <?php tag, add use SilverStripe\Control\Middleware\HTTPCacheControlMiddleware;
3. Add the below lines to the init function:

    public function init()
    {
        HTTPCacheControlMiddleware::singleton()
           ->enableCache()
           ->setMaxAge(86400); // 1 day

        parent::init();
    }

Managing Caching in the Webslice Console

After you have set up your application to handle caching, and checked your cache settings, you can use the Webslice Console to switch a container’s caching on or off, or to change its settings.

You can change the cache status to on and off, change settings (described below), edit Ignored Paths, and purge the cache.

Max Size

As the name suggests, this specifies the size of your cache. Remember that your cache will need space on your Webslice Container server. Higher settings will need more space, but also allow more content to be cached. In general, larger applications need a larger Max Size.

Lifespan

The Lifespan determines how long a cached copy of content will be kept. After the Lifespan has ended, a fresh request is made from the cache to the origin and a new copy of the content is cached (depending on your Inactive setting - see next section). The less often you update your content, the longer the lifespan can safely be.

Inactive

This is a second setting that places a time limit on cached content. Your Inactive setting is longer than the Lifespan, and it helps avoid cold starts.

A time window opens when cached content passes its Lifespan, and closes again when the Inactive time is reached. While that window is open, the first request for the content will:

1. Receive a copy of the old cached content.
2. Trigger an update to the cached content.
3. Reset the Lifespan and Inactive time countdown.

If your Inactive time expires before the content has been requested, then the cached version is cleared. The next user to request the content will be served from the origin server, not the cache, which is slower but will bring up the latest version of the content.

Ignored Paths

Anything that you don’t want to be cached can be specified here. This can be an extra layer of protection, or a way to add certainty if you’re not sure that your application is handling cache-control headers like it should.

You can specify:

• Paths, like /admin or /wp-admin, and
• Files, like /test.php.

Invalid characters to avoid in Ignored Paths:

• Newline, \n
• Carriage return, \r
• Single and double quotes, ' and "
• Curly brackets, { }
• Dollar sign, $. This is because Docker labels use $ for variable substitution.
• Commas ,. Because we store the paths as a comma separated string, adding commas will result in two different paths.

Troubleshooting Caching of Webpages

Check That Caching is Working

The simplest check is to visit your site and see whether your browser receives cached content. To do this, use devtools to check the headers:

1. Open your browser’s devtools (pressing F12 usually works).
2. Open the the Network tab.
3. Select the resource you want to check. You might need to reload the page to prompt the browser to start recording network activity.
4. Under the Headers tab, scroll down to Response Headers and find the X-Cache-Status header. If you don’t see this header, your application might not be properly configured to handle caching.

The possible values that you will see here are:

• HIT: Success. The content in your browser came from a cached copy.
• MISS: The content in your browser was fresh, not cached.
• EXPIRED: Re-test. There was a cached copy, but it was too old so your browser received a fresh copy.
• UPDATING: Success, but worth re-testing. Your browser received stale cached content which is now being replaced with a cache of the current content.

If the only X-Cache-Status you see is MISS

Have another look at your cache-control headers. If they contain values like no-cache or max-age=0, then content will not be cached. Look into whether your application is creating a session or setting cookies which cause the proxy to not cache the response.

If Updates to Your Site Aren’t Displaying

Clear the cache via the Webslice Console. If your application has a cache clearing/purging function, use that too.