Static Cache Buster Laravel Package

Product Decisions This Supports

• Feature-level: Deciding whether to ship "instant content updates without a slow-page window" as a quality attribute for a Statamic-backed site. The package's premise — warming the static cache so real visitors never hit an ungenerated page — directly maps to a user-visible defect (first visitor after publish/deploy gets a cold, slow response).
• Roadmap / perf workstream: Slotting cache-warming into an existing performance initiative (Core Web Vitals, TTFB p95, origin load during traffic peaks). This is a narrow, low-effort lever rather than a platform migration.
• Build vs. buy: The problem is small and well-bounded (invalidate → warm → serve). Adopting or vendoring an MIT-licensed package is almost certainly cheaper than building warming logic in-house — provided the team accepts the maintenance risk of a 0-star, 0-dependent, single-maintainer package. A realistic decision is "adopt under a pin + fork-on-failure plan," not "standardize org-wide."
• Operational decisions: Reducing reliance on aggressive CDN purge budgets and manual "clear cache then hope" runbooks; making publish/deploy events safe by default so editorial teams can publish at will without an ops gate.
• Success metrics to instrument before/after: static cache hit ratio, TTFB p95 on cache-clear/publish, origin request volume and CPU during deploys, 5xx rate in the minutes following a publish, and editorial publish-to-live latency.
• Use cases it fits: content-heavy marketing sites, documentation, high-traffic landing pages, sites with frequent editorial publishing, and low-traffic sites where a single cold request is disproportionately expensive on shared hosting.

When to Consider This Package

Consider it when:

• You run Statamic (Laravel-based) with static caching enabled — this is a hard prerequisite; the package is meaningless outside that stack.
• Your publish/deploy cadence is high enough that cache-miss windows are a recurring complaint, or your traffic is spiky enough that a cold page hurts.
• You can pin the dependency to a specific version/commit, read the source (small surface area), and wrap it with your own smoke tests.
• Your team is comfortable with Composer packages and Laravel scheduling/queue patterns, and can absorb upstream abandonment via a fork (MIT makes this legally trivial).

Look elsewhere when:

• You're not on Statamic, or you use dynamic/edge caching rather than Statamic's static cache — evaluate Cloudflare/Fastly purge-and-warm instead.
• You need vendor support, an SLA, a security review trail, or guaranteed maintenance. Zero stars, zero dependents, and a single 2025-06-25 release are clear maturity red flags; treat it as early-stage code, not infrastructure.
• Your site is small or low-traffic enough that a brief miss window is invisible — the added dependency isn't worth the supply-chain surface.
• You require distributed warming across multiple app servers or a queue-based warm — verify the package actually does this before committing; otherwise plan to build.
• You need cache-warming tied to CDN edge invalidation end-to-end; that's a broader capability than this package appears to cover, and you'd be assembling it yourself anyway.

Verdict to carry into the decision: pilot on one site, pinned and monitored; do not standardize without a named internal owner.

How to Pitch It (Stakeholders)

For executives: A small, MIT-licensed add-on for our Statamic CMS that removes a specific, recurring failure mode — pages being slow or erroring for real visitors right after content is published or a deploy lands. Cost is a few hours of engineering; exit cost is near zero because the license lets us fork or drop it. Recommendation: time-boxed pilot on one property with a clear success metric (TTFB p95 after publish), not a platform-wide commitment.

For engineering: It hooks into the static-cache lifecycle and pre-warms pages so the first real request isn't the one paying the generation cost — i.e., it turns cache invalidation from a "visitor absorbs the cost" event into a "system absorbs the cost" event. Adoption is a Composer require plus wiring it to publish/deploy events; it fits existing Laravel scheduling and queue patterns. Caveats we're accepting knowingly: single maintainer, no dependents, one release — so we pin the version, add integration tests around publish-to-warm, alert on cache hit ratio regressions, and keep a fork path open. If it doesn't hold up in the pilot, replacing it is a same-sprint task, not a project.