Page Cache Laravel Package

Technical Evaluation

Architecture fit silber/page-cache is a full-page HTML response cache that sits at the outermost edge of the Laravel request lifecycle. It stores rendered responses as flat files and can serve them in two modes: middleware mode (Laravel still boots, middleware short-circuits the router) and rewrite mode (the web server serves the static file directly, bypassing PHP and the framework entirely). Architecturally it is a complement to — not a substitute for — a CDN or reverse proxy: it is per-origin, per-node, and application-aware, so it is a good fit for anonymous, read-heavy, high-fanout GET surfaces (marketing pages, blogs, docs, public listings, category pages) in a monolith or modular monolith. It is a poor fit for authenticated dashboards, personalized fragments, Inertia/Livewire SPA shells where most value is client-rendered, or APIs where JSON caching belongs in the cache layer instead. v1.1.2 changes none of this: it is a compatibility declaration, not an architectural change.

Integration feasibility Low code footprint: composer require, publish config, register the middleware, and optionally add server rewrite rules. No schema changes, no new infrastructure required, no forced abstraction of existing controllers — the cache is applied as a filter over existing routes. The real integration cost is not installation but policy: deciding which routes are cacheable and what invalidates them. Expect one engineer to reach a staging proof-of-concept in under a day.

Technical risk The dominant risk is correctness of invalidation, not performance:

• Personalization leakage — if a session-, cookie-, or user-scoped response is cached, one user's page is served to another. This is a security incident, not a bug.
• Stale CSRF tokens — cached HTML containing @csrf fields will serve expired tokens to subsequent visitors, producing 419 errors on form submissions. Cached pages should be form-free or use a token-refresh strategy.
• Invalidation gaps — the package gives you forget/remove primitives; you must wire them to model events, admin publishes, and deploy hooks yourself.
• Rewrite-mode coupling to the file store — server-level serving requires the file to be physically reachable by the web server; a Redis/Memcached store gains tag support but forfeits the main performance win.
• Multi-node divergence — local disk per node means N divergent caches unless you share a volume or front everything with a CDN.
• Ecosystem validation is thin — ~1.3k stars but effectively no dependents recorded, single maintainer, no commercial backing. Treat it as a well-regarded utility, not a de-risked platform dependency. The v1.1.2 Laravel 13 announcement is a positive maintenance signal (upstream is tracking current framework majors) but does not change the bus-factor-1 characterisation.

Key questions

1. What percentage of traffic and of routes is anonymous and non-personalized? If under ~30%, the payoff is likely marginal.
2. What are the TTL and invalidation triggers, and who owns them — application events, CMS publish, or deploy only?
3. Single node or fleet? If a fleet, is shared storage or CDN purge acceptable?
4. Are there auth, session, or CSRF-bearing elements in candidate pages?
5. Do we need tags/pattern invalidation (pushing us toward Redis and away from rewrite mode)?
6. What does the current stack already do — Cloudflare/Fastly, Nginx proxy_cache, Laravel response cache — and is this additive or duplicative?
7. Which Laravel major are we actually on? v1.1.2 asserts Laravel 13 support; confirm the pinned version we install matches our framework version and that our other edge-layer packages (debug bars, A/B testing, locale negotiation) are also Laravel 13-ready, since those are the common breakage points.

Integration Approach

Stack fit Works across modern Laravel versions with no exotic requirements — PHP 7.4/8.x, any web server, optional Redis. The v1.1.2 release extends the supported framework ceiling to Laravel 13, which removes the most likely near-term blocker for teams planning a framework upgrade: we no longer have to choose between adopting the cache and moving to Laravel 13. Fits cleanly into an existing Laravel HTTP kernel or Laravel 11+ bootstrap/app.php middleware registration. Best value where the framework boot itself is the bottleneck (heavy service providers, Eloquent-heavy page assembly); near-zero value where responses are already cheap.

Migration path Adopt incrementally and reversibly:

1. Inventory routes and classify into cacheable / conditional / never.
2. Install and run in middleware mode with shouldCacheRequest scoped to a small allowlist — no server changes, instant rollback by removing middleware.
3. Instrument hit ratio, TTFB, and PHP worker saturation to quantify the benefit before committing.
4. Only then enable rewrite mode for the highest-volume routes, which is where the order-of-magnitude gain lives.
5. Optionally layer a CDN in front for geographic distribution.

Compatibility Middleware ordering is the main compatibility hazard: to capture the full benefit the cache middleware must run before session/auth/CSRF and other web-group middleware, while those middleware must still run for cache misses. Packages that inject per-request state (debug bars, response transformers, cookie setters, locale negotiation, A/B testing) will either break on cached responses or silently poison the cache. v1.1.2 confirms Laravel 13 compatibility but, per the changelog, ships no API, config, or behavioural changes — so treat it as a routine version bump with no migration work. Version-pin and re-test on every Laravel major regardless, since middleware registration and alias conventions have shifted historically and this release is a declaration of support rather than a hardening exercise.

Sequencing Route classification → install + config → middleware-mode canary → invalidation wiring (model observers, publish hooks, deploy-time purge/warm) → load test → rewrite-mode rollout → CDN in front → runbook and dashboards. Deploy pipeline must include a cache clear/warm step, otherwise every release serves stale assets and stale HTML. If a Laravel 13 upgrade is on the roadmap, sequence the framework upgrade and the v1.1.2 pin together so the cache layer is validated against the same framework version we intend to run, rather than validating twice.

Operational Impact

Maintenance Small, stable, MIT-licensed codebase with low churn; v1.1.2 is a compatibility bump consistent with that pattern. The bus factor of one and absence of commercial support remain unchanged — one maintainer tracking framework releases is still a single point of failure, merely one currently keeping pace. Budget for owning the package's behavior internally: fork or pin if upstream lags a future Laravel major. The invalidation logic and web-server rewrite rules are bespoke, undocumented-in-repo artifacts that must live in version control and be reviewed like application code.

Support No vendor SLA. Community issues only. Mitigate with a written runbook covering "how to purge," "how to identify a stale page," and "how to disable in one step" (remove middleware, delete rewrite rule, clear directory). Add a line item to the framework-upgrade checklist: confirm the pinned cache version's declared Laravel support before bumping the framework.

Scaling Read scaling is excellent — in rewrite mode a static file serve is roughly the cheapest operation a web tier can do, and PHP worker pressure drops proportionally to hit rate. Costs move to storage: disk footprint grows with route cardinality, and query-string variants can explode file count (filter them explicitly). Multi-node deployments need shared storage (NFS/EFS) or a CDN-fronted per-node cache; shared storage adds latency and a new failure domain. Watch inode counts and realpath/opcache behavior on the cache directory.

Failure modes

• Stale content served after publish (invalidation miss) — highest-probability, highest-visibility.
• Cross-user content leak via misconfigured cacheability — highest-severity.
• Expired CSRF tokens producing 419s on cached forms.
• Truncated/partial cache files read during concurrent writes or under disk-full conditions.
• Silent total cache miss (hit ratio collapses) after a config, cookie, or Vary change — invisible without a hit-ratio metric.
• Cache stampede on cold start or mass invalidation, amplifying origin load precisely when the site is already stressed.
• Permission or path errors on storage/framework/page-cache after deploys.

Ramp-up Genuinely low for a mid-level Laravel engineer: a day to understand the package, a week to safely ship. The learning curve is in cacheability judgment and invalidation design, not the API. Required enablement: a short internal doc on route classification rules, the invalidation contract, and the kill switch — plus a dashboard for hit ratio, cache size, and 419/5xx deltas before the rollout is considered done. v1.1.2 does not alter the enablement scope; it only removes a framework-version objection from the adoption conversation.