How caching works

The Templ cache is a server level page cache, pre-installed on all websites hosted by Templ. If needed, install the plugin manually with the Install Templ plugins tool in our panel.

Templ Cache settings in WP Admin

What is a page cache and how does it work?

Loading a WordPress page normally runs many PHP files and database queries. For pages that don't change constantly, that work is repeated on every visit. A page cache stores the generated HTML once and serves it to subsequent visitors, giving:

Much faster page loads
Scalability: more pages served with less server load

Our servers use the nginx fastcgi cache module for page caching on server level.

What we cache by default

All pages without a query string in the URL, with a few exceptions:

gclid
fbclid
twclid
utm_term
utm_source
utm_campaign
utm_medium
utm_content
fb_action_ids
fb_action_types
fb_source

These URL paths are never cached (they always BYPASS the cache):

/wp-admin/
xmlrpc.php
wp-.*.php
/login
/logout
/signin
/signup
/register/
/cart
/my-account/
/wc-api/
/checkout
/addons
/lost-password

(wp-.*.php is a pattern matching any PHP file whose name starts with wp-, such as wp-login.php and wp-cron.php.)

The cache will be disabled if you are logged in to WP Admin.

Frequently asked questions

How do I know if a page is loaded from cache or not?

Templ adds an X-Cache-Status response header. The first request to a non-cached page shows MISS; the next request to the same page shows HIT, meaning it's served from cache.

X-Cache-Status header shown in Pingdom response headers

The example above uses Pingdom. You can also check in Chrome (right click → Inspect → Network tab → response headers for the domain):

Checking the X-Cache-Status response header in Chrome DevTools Network tab

Or from your terminal with curl -I https://templ.io:

Cache HIT shown in the response headers from a curl request

Can I use the Templ cache along with another page cache plugin?

No. Only one page cache should be active at a time, whether that is WP Rocket, WP Fastest Cache, Autoptimize, or any other.

Do not run another page cache together with Templ Cache. Two page caches at once can cause unexpected behavior, such as stale content or conflicts when the cache is purged.

To use the advanced optimizations of a plugin like WP Rocket, disable the Templ Cache helper plugin first so it runs instead of Templ Cache.

Plugins like Templ Optimizer that only add non-cache optimizations (minification, combining CSS and JS) can run alongside Templ Cache.

What is the difference between other cache plugins and Templ's page cache?

Our cache works on a server level for maximum performance and efficiency; the plugin is merely a helper that clears the cache as you edit content.

Other cache plugins add extras like minification and combining CSS/JS files. Our page cache doesn't replicate these, since so many plugins already do them.

When is a page added to the cache?

The first time it's visited, or the first time it's visited after the cache has been purged.

How long is a page cached?

24 hours by default. To change it, contact support.

How do I manually purge (clear) the cache?

Purge from the Templ Cache settings, or from the shortcut at the top of the WP Dashboard:

Purge cache shortcut at the top of the WordPress dashboard

The cache is also automatically purged when you make edits in WP Admin.

To purge programmatically, for example from a deploy script, use the Templ CLI over SSH with templ cache purge, or run it remotely in one line.

How do I disable the Templ page cache?

Deactivate the helper plugin:

Deactivating the Templ Cache helper plugin to disable the page cache

Troubleshooting

A page always returns X-Cache-Status: MISS

If a page never reaches HIT no matter how many times you load it, WordPress is almost always sending a response header that tells the cache not to store the page.

no-store in the Cache-Control header is the only directive that stops the Templ page cache (a response setting X-Accel-Expires: 0 is skipped the same way). It's often part of a longer value, but no-store alone is enough to force MISS on every request:

cache-control: no-store, no-cache, must-revalidate

Other directives that look like they'd disable caching are ignored by the Templ cache, and the page is still served as a HIT:

Cache-Control: no-cache
Cache-Control: private
Cache-Control: must-revalidate
Cache-Control: max-age=0
An Expires header with a past date
A Set-Cookie header (the cookie is stripped from the cached response)

These still affect browser and CDN caching, but they won't stop a page from being stored in the Templ server cache. So when you see repeated MISS, look specifically for no-store.

MISS means the page is cacheable but wasn't in the cache (or was told not to be stored) - a header problem. BYPASS means the request matched a rule that skips the cache entirely, such as a query string or a never-cached path - a request or path problem.

To diagnose, request the page and check the cache-control value alongside x-cache-status:

curl -I https://your-domain.com/the-page/

Common sources of a no-store header:

PHP sessions. Calling session_start() (directly or via a plugin/theme) makes PHP emit Cache-Control: no-store, no-cache, must-revalidate on every affected page.
Membership, e-commerce, and security plugins, which often call WordPress's nocache_headers() on pages they consider private.

Deactivate the suspected plugins one at a time and re-check cache-control until no-store disappears and the page returns HIT.