ProCache vs. $cache API for Handling Concurrent‑Request Latency in ProcessWire

Goal: lower the average response time of ProcessWire pages when many users request the same uncached content simultaneously.

Constraints: ProCache eliminates per‑request PHP and DB work by serving static HTML, but its automatic cache‑clearing may miss API‑driven updates, risking stale pages; the native $cache API lets developers cache expensive fragments or queries, preserving dynamic parts while still reducing load, yet it adds more cache files or Redis keys and requires manual invalidation for each cached piece. The decision hinges on whether simplicity and near‑zero latency outweigh the flexibility and granular control of fragment caching under realistic concurrency.

Which approach yields the lowest average latency under a sustained load of 50 concurrent requests for a page that is initially uncached? How does the effort required to keep ProCache‑generated HTML fresh compare with the invalidation overhead of managing many $cache API entries? What are the respective impacts on disk I/O or Redis memory when scaling to 200 concurrent users?