Template cache with client-side placeholder vs. WireCache fragments for mostly-static ProcessWire pages

Short answer

For a page that is 95 % static and 5 % per‑user, the most reliable pattern is:

• Enable template cache for the whole page so that the expensive selectors and field queries are rendered only once per cache‑TTL.
• Render a lightweight placeholder for the personalized part and fetch that fragment via a small AJAX call (or a dedicated API endpoint) that uses $cache->get('user_greeting_' . $user->id) to cache the per‑user data.
• Clear the template cache on page save and clear any user‑dependent WireCache entries that depend on that page.

Why this works

Template cache stores the *entire* rendered output. If you put a $cache->get() inside a cached template, the result is cached as part of the page, so the personalized fragment would be shared across users. The only way to avoid that is to keep the fragment out of the cached output.

The client‑side placeholder approach keeps the heavy work out of the user’s browser and avoids any risk of leaking data between sessions. The AJAX request is cheap because the fragment itself is small, and the per‑user cache key guarantees isolation.

Combining template cache with per‑user fragments

ProcessWire does not provide a built‑in way to mix template caching with per‑user output. The safe pattern is:

1. In the template, output a <div id="user-greeting" data-user="{$user->id}"></div> placeholder.
2. Include a tiny JavaScript snippet that, on DOM ready, sends a GET to /wire/api/users/greeting (or similar) passing the user ID.
3. The endpoint returns the greeting string, optionally cached with $cache->get('user_greeting_' . $user->id).

Because the placeholder is not part of the cached HTML, each user gets a fresh AJAX call and the server can safely cache the fragment per user.

Invalidation strategy

When a page is edited you need to clear two things:

• The template cache for that page’s template (ProcessWire does this automatically on page save).
• Any WireCache entries that depend on that page’s data. The safest way is to use $page->watch('cache', function($event) { $cache->clear('user_greeting_*'); }); or to add a custom hook in wire/modules/ProcessPageSave.php that calls $cache->clear('user_greeting_' . $user->id) for all affected users.

Because the per‑user fragment is short‑lived (TTL of a few minutes is usually enough), stale data is unlikely to be served after an edit.

When to consider fragment‑only caching

If you can tolerate rendering the static part on every request (e.g., the selectors are cheap or the user base is small), you could wrap the entire template in $cache->get() and add a per‑user key. However, this defeats the purpose of template cache and will increase CPU usage.

Diagnostic question

Do you have any requirement that the personalized fragment must be server‑rendered in the initial HTML (e.g., for SEO or no‑JS scenarios)? If yes, you would need a different approach such as a per‑user cache key for the whole template, which is not supported out of the box.