Using Processwire's Template Cache to Cut Page Load Times

The Problem: Slow Page Render on a Shared Host

You have a Processwire site running on a low-cost shared host. Pages that pull data from several selectors or call external APIs take 150-200 ms to render, which feels sluggish for visitors and hurts SEO. You cannot install Redis or Memcached, but you need a way to serve the same content faster without rewriting the logic.

How Processwire's Template Cache Works

When template caching is enabled for a template, Processwire saves the fully rendered HTML output as a static file under site/cache/templates/. The filename is a hash that incorporates the template name and any selector-based variations you define, for example a page ID or a URL segment. On subsequent requests for the same variation, Processwire skips PHP execution and database queries, serving the file directly. This reduces typical load times from the 150-200 ms range to under 30 ms for cached pages.

Enabling and Configuring the Cache

1. Log in to the Processwire admin.
2. Navigate to Setup → Templates and click the template you want to cache, e.g. basic-page.
3. Open the Cache tab.
4. Check Enable template caching.
5. Optionally set an Expiration time, e.g. 3600 seconds for one hour, or leave it blank for indefinite caching until a page is saved.
6. If your template output varies by a selector, add that selector to the Cache variations field, e.g. id or parent_id. This ensures different pages using the same template get separate cache files.
7. Save the template.

No command line is required to enable the feature, but you can clear the cache manually if needed:

# Run from the site root; requires shell access and write permissions to site/cache/
rm -rf site/cache/templates/*

Alternatively, use the admin: Modules → Cache → Clear.

Worked Example: Caching a Blog Listing Page

Imagine a template blog-list that shows the ten most recent posts, each with a thumbnail fetched from an external image service. The uncached request takes ~180 ms.

1. Edit the blog-list template, enable caching, and set the variation to limit, the number of posts shown.
2. Save the template.
3. Visit the blog listing page in a browser.
4. Open the developer tools network tab and look for the response header X-Processwire-Cache: HIT on the second load. The first load will show MISS as the cache is written.
5. Observe the response time drop to ~25 ms.

If you later change the number of posts shown, e.g. adjust the limit to 15, Processwire treats this as a new variation and creates a fresh cache file, preventing stale data.

Trade-offs and Limitations

• User-specific content: The default cache serves the same HTML to every visitor. If a template shows login-based data, you must either add a variation selector, e.g. the user ID, or disable caching for that template.
• Cache stampede: When many simultaneous requests hit an expired cache, each may regenerate the file. Setting a short expiration or using a manual warm-up script can mitigate this.
• Hidden inefficiencies: Because cached pages are fast, slow database queries or expensive API calls inside the template can go unnoticed. Periodically disable caching, or use Debug mode, to profile uncached requests.
• File-system load: On very high-traffic sites, the cache directory may accumulate many files. Implement a routine cleanup, e.g. a cron that deletes files older than a set time, to avoid inode exhaustion.

Checking and Verifying the Cache

To confirm that caching is active:

1. Enable Debug mode, Setup → Advanced → Debug mode, and reload the page. The debug toolbar shows Render time and indicates whether the template was served from cache.
2. Check for the header X-Processwire-Cache: HIT or MISS in the network response.
3. Look inside site/cache/templates/ for a newly created file matching the template name and a hash suffix.

If you do not see the header or a new file, verify that the template's cache settings are saved and that the web server has write permission to the site/cache/ directory.

Actionable Closing

Template caching is a low-overhead way to gain significant speed improvements on shared hosting where external caches are not available. Enable it for templates whose output is stable across users or can be varied with simple selectors, monitor the X-Processwire-Cache header to confirm hits, and keep an eye on user-specific sections and cache hygiene. By combining this feature with regular profiling of uncached requests, you will get both fast page delivery and visibility into any remaining performance bottlenecks.