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

Assume ProcessWire 3.x with MySQL. A set of content pages is roughly 95% identical for all visitors — long article bodies built from several field queries and a couple of expensive selectors — but each page also contains one small personalized fragment, such as a greeting or a per-user badge.

Two documented approaches seem to compete here. Template-level page caching (enabled per template in the admin) caches the entire rendered output for a TTL and can be cleared on page save, which gives the highest hit rate but cannot hold per-user output. The alternative is to leave the template uncached and wrap only the expensive fragments in $cache->get()/save() (WireCache), letting the personalized part render dynamically on every request.

The trade-off I cannot resolve: with template cache, the personalized fragment would need to be rendered as a placeholder and filled in client-side, adding JavaScript and an extra request. With fragment caching only, the base page markup and its queries are rebuilt on every hit even though they rarely change, and TTL-only expiry risks serving stale fragments after edits.

Which approach is the better fit for this profile, and why?

Is there a documented way to combine template caching with a per-user fragment without risking one visitor's personalized content being served to another?

How should invalidation be handled so that editing a page refreshes both the static output and any long-TTL WireCache fragments that depend on it?