Page Cache Laravel Package

Product Decisions This Supports

• Build vs. buy for performance work. A full-page cache is a classic "don't build this yourself" capability. This package gives you the Laravel-native 80% solution (middleware + on-disk static files) without standing up Varnish, Fastly, or a custom response-cache layer. The decision it most directly supports is: do we invest engineering weeks in caching infrastructure, or do we ship a package and spend that time on product?
• Roadmap sequencing for performance/Core Web Vitals. If TTFB and LCP are on the roadmap because of SEO or conversion pressure, this is a cheap lever to pull before committing to bigger architectural work (read replicas, queue offloading, Octane, CDN re-platforming). It lets you defer those projects and measure how much headroom caching alone buys.
• Feature scoping: "does this page need to be personalized?" Adopting a page cache forces an explicit product conversation about which surfaces are anonymous and static (marketing pages, blog, docs, landing pages, public category/listing pages) versus session-dependent (dashboards, carts, account pages). That classification is genuinely useful for roadmap planning independent of the package.
• Freshness/invalidation policy as a product decision. The package's model-event-driven invalidation (and TTL) makes cache staleness a product question rather than an ops mystery: how stale can a price, stock count, or article edit be before it hurts? That's a decision PMs and content owners should own, and this package makes it legible.
• Infrastructure/cost decisions. Serving pre-rendered HTML from disk reduces PHP-FPM work per request, which can defer a hosting tier upgrade or reduce node count for read-heavy anonymous traffic. Useful input to a build-vs-scale budget conversation.
• Buy-vs-CDN decision. A useful comparison point when evaluating edge caching (Cloudflare, Fastly) versus origin caching: this is the low-cost, low-lock-in origin option; the CDN is the global-latency option. They compose, but the PM should know which problem is being solved.
• Framework-upgrade planning. v1.1.2 adds Laravel 13 support, which means adopting this package does not pin the platform to an older Laravel major. That removes a common "will this block our next framework upgrade?" objection from the build-vs-buy calculus and makes it safe to adopt ahead of an upgrade window rather than after one.
• Primary use cases worth scoping against: content/marketing sites, blogs, documentation, CMS-driven public pages, high-traffic landing pages during launches or campaigns, and public e-commerce category pages (with caveats on pricing/stock staleness).

When to Consider This Package

Consider it when:

• Traffic is predominantly anonymous, GET-based, read-heavy, and the pages are expensive to render (heavy Eloquent queries, complex Blade trees).
• The stack is Laravel-native and the team is small — no appetite for operating Varnish or a separate caching tier.
• You can control web server configuration (nginx/Apache) so static files are served before PHP boots — that's where the "lightning fast" claim actually comes from. The middleware-only fallback still avoids re-rendering, but the headline benefit shrinks.
• Content changes are event-drivable through Eloquent, so invalidation can be automatic rather than manual.
• You want MIT-licensed, no-vendor-lock-in infrastructure with an easy rollback (remove middleware, ship).
• You are on, or planning to move to, a current Laravel major. The v1.1.2 release explicitly targets Laravel 13, so the package tracks the framework rather than lagging it — a meaningful signal for upgrade-roadmap planning.

Look elsewhere when:

• Pages are authenticated, personalized, or session-dependent (carts, dashboards, CSRF tokens, flash messages). Full-page caching here is a correctness bug waiting to happen.
• The workload is API/JSON-first — a response-cache package (e.g. spatie/laravel-responsecache) or HTTP-level caching is a better fit than a file-based page cache.
• You run multiple app servers without shared storage. The cache is local disk; each node caches independently, and invalidation must be broadcast. That's either extra engineering or a correctness risk, and it's the single most common reason to outgrow this package.
• You need tag-based granular purge at scale, stale-while-revalidate, or edge-level caching — that's a CDN or reverse-proxy problem.
• Write rates are high enough that invalidation thrashes the cache and hit rate collapses.
• You need vendor-backed SLAs or a large maintainer team. This remains a focused, single-maintainer utility. The v1.1.2 Laravel 13 release is a positive maintenance signal — it shows the maintainer is keeping pace with framework releases rather than leaving the package to rot — but it is one data point, not an SLA. Verify cadence and issue responsiveness directly against your upgrade policy, and note that the dataset's 0 dependents figure reads as understated relative to the package's real-world footprint; validate adoption empirically rather than trusting that metric.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can cut server response time on our public, non-logged-in pages by serving pre-rendered HTML directly from disk, before PHP even starts. It's an MIT-licensed Laravel package with no new infrastructure, no vendor contract, and a small integration surface — a low-risk, low-cost performance win that improves Core Web Vitals and SEO and can defer a hosting upgrade. The current release (v1.1.2) adds Laravel 13 support, so adopting it won't lock us out of our next framework upgrade. It is explicitly not for logged-in or personalized pages, and it requires a small web server configuration change plus a disciplined cache-invalidation story, both of which we control.

For engineering (the honest version): Middleware writes response bodies to disk and serves them on subsequent requests; Eloquent model events handle invalidation, with TTL as a backstop. Full benefit requires nginx/Apache to serve the cache directory directly via try_files/rewrite; otherwise Laravel serves the file and you still skip rendering but lose the early-exit. Main risks are (1) per-node cache divergence in multi-server deploys, (2) invalidation correctness for any page that varies by user or session, and (3) cache poisoning if cache keys don't account for all relevant request variance. Mitigations are straightforward — restrict caching to a known-anonymous route allowlist, key on full URL plus relevant query params, and start with a short TTL. Rollout is reversible by removing the middleware. v1.1.2 confirms Laravel 13 compatibility, so this is safe to introduce alongside an upcoming framework bump — but treat the release as a compatibility signal, not a guarantee of long-term maintenance; pin the version and watch the repo through at least one upgrade cycle before making it load-bearing.