Cache manager: fast public pages, dynamic sessions left alone

Server cache is powerful because it can return a public page without asking the application and database to rebuild it for every visitor. It is also dangerous if it stores a private session, a shopping cart, or an account page. Cache Manager is designed around that difference.

When enabled for a domain, SHM evaluates requests and responses before treating them as cacheable. Public, stable pages can be stored. Authenticated sessions, unsafe methods, private responses, and known dynamic routes are bypassed.

The decision path

What must always bypass?

Login and administration paths, carts, checkout, session cookies, authorization state, and other dynamic signals remain outside the shared cache. An application can also mark a response private or uncacheable through normal HTTP behavior. Cache Manager respects that decision rather than trying to win a benchmark by showing one customer's page to another.

This is especially important for WordPress and ecommerce applications, but the safety model is not limited to one CMS. The cache works from HTTP behavior and configured rules around the hosted domain.

Make exclusions explainable

Users can add bounded exclusions for a whole path, exact location, marker, or supported wildcard prefix. That allows a custom application route to remain dynamic without disabling cache for the entire site. Rules stay visible in the manager so future maintainers can see why a path is bypassed.

A broad exclusion may be correct, but it should be deliberate and documented. Cache coverage should reflect the routes that can safely return a shared response.

Operate cache deliberately

Clear, invalidate and warm

Cache Manager supports clearing cached content and invalidating affected entries when configuration or content changes. Eligible public URLs can be warmed so the first visitor after a clear does not pay the full application cost. Warming still follows cache safety; it is not permission to pre-render private routes.

The generated behavior follows the active web stack, including supported Nginx, Apache, and combined deployments. Domain intent remains consistent even though the server implementation differs.

How do you know it worked?

The page reports cache files, bytes, hits, misses, and bypasses where available. Live probes can request an eligible public URL more than once and show MISS, HIT, or BYPASS behavior. Cookie and session checks help verify that dynamic requests do not receive a shared cached response.

A green toggle and an HTTP 200 are not proof of caching. Cache Manager makes the response path visible so performance work can be tested after configuration changes.

When in doubt, bypass

If SHM cannot classify a response safely, bypass is the correct outcome. The application still serves the request normally. That fallback makes server cache useful across varied applications without requiring every site owner to become a cache engineer.

The aim is straightforward: remove repeated work from public pages, preserve correctness for dynamic users, and provide enough evidence to verify which response path was used.