Making Statamic Fast Again

For the last few years, I have been a major proponent of Statamic for any site that need content management in some capacity.

It makes it stupid simple to create content heavy sites that have both a great author experience as well as developer experience. If I never have to touch Wordpress or Drupal again it wouldn't be soon enough.

For one of my bigger sites though things had started to get a bit slow lately. It only has a few hundred items in the main collection (think blog posts) but the rendering time for many pages started exceeding 1 second. Perfectly fine for development locally, but not great for visitors who had to wait a full second or more for things to even start rendering on the page.

Enter two options Statamic provides that I don't think are brought up enough--the stache watcher and static caching.

Show Me The Stache

Under the hood, Statamic uses an ephemeral cache internally that leverages the the underlying framework Laravel provides. This by itself provides a nice little speed bump automatically as well as providing configuration options for more control.

One of the ones often forgotten is the watcher configuration. With this on, every page request triggers a scan of last_modified timestamp on all content and configuration files. In most cases this is fine, but add in the slow filesystem for Docker on macOS and page loads start creeping up over the second mark.

Thankfully there is a simple way to turn it off, and in my case instantly brought the load times down to 500ms. Simply add a new variable to your .env file (assuming you want flexibility on turning it on and off). Then update the config/statamic/stache.php config file to leverage this new setting.

STATAMIC_STACHE_WATCHER=false

return [
   'watcher' => env('STATAMIC_STACHE_WATCHER', true),
];

Setting this to false turns off the check on every page load and greatly increasing rendering times with large sites. Content changes made through the control panel will still update the cache and indexes fine, and if you make changes to content files manually you can run php please stache:refresh which will clear and then warm the stache.

I'll Take Half Please

This was a nice improvement but I knew we could go even faster--enter the static caching options!

The primary two options are called half and full.

The half strategy provides an easy middle ground. With this turned on all requests are still run through the Statamic application, but all response data is pre-rendered and cached within Laravel's application cache (some place the stache lives).

This has a minimal impact on how things work but you do lose certain features. Things such as server-side validated forms or dynamic style content won't work as the response data is cached and served.

The speed improvements are major again, cutting my load times for the document down to 100ms (down from 1 second standard and 500ms without the stache watcher). It can by turned on with an environment variable as well for added flexibility.

Adding another new option to your .env file and then updating config/statamic/static_caching.php to make use of it.

STATAMIC_CACHE_STRATEGY="half"

return [
    'strategy' => env('STATAMIC_CACHE_STRATEGY', null),

    'strategies' => [
        'half' => [
            'driver' => 'application',
        ]
    ]
];

Finally, you will also want to either set an expiry time or run php artisan cache:clear as part of your deployment script. Saving from the control panel will flush that individual URL from the cache, but refer to the docs for more complex options around invalidating the cache.

I'm Going Full Tilt

If that isn't good enough for you, well you can switch to the full option--this entirely removes PHP from the equation as Statamic will generate completed static .html files for your web server to host.

This is very similar to the Static Site Generator plugin for Statamic but both provide different options and features so be sure to check both out before going this route.

Either option though should be as fast as your web server can serve static files, which in many cases is by far the fastest option around. Going with the SSG option also means you can do things such as host your site on a CDN such as Cloudflare or Netlify to get the content even closer to your users.

The fact that Statamic provides all these different options for speeding up an already fast site (even on top of PHP) is another reason I continue to find uses for it.