Laravel Static Laravel Package

Product Decisions This Supports

• Go/no-go on production static caching. Unbounded per-URI file growth (every ?utm_source=… and ?fbclid=… becomes its own permanent file) is the main operational objection to full-page static caching. static:status converts that objection into a measurement: 35% of cached pages being query-string variants of 11 distinct URLs is a concrete number a PM can act on rather than a theoretical risk.
• Cache-growth policy and pruning rules. The report surfaces storage held by URLs with vs without a query string, top URLs by variant count, and the most common query parameters — that is the evidence needed to justify a standing policy such as static:clear --only-with-query-strings, or to argue for a scheduled job that does it.
• Roadmap: whether to invest in URL normalization upstream. If utm_source/fbclid tops the parameter table, the real fix is not pruning but normalizing or rejecting tracking parameters before they reach the cache key. This data tells you whether that work is worth a sprint.
• Capacity and cost planning. --json plus --disk= means disk-usage alerts can be wired into existing monitoring, turning an ad-hoc "the server filled up" incident into a threshold with an owner.
• Build vs buy on cache diagnostics. A bespoke du-and-parse script is cheap to write but couples you to the package's on-disk layout and breaks on upgrade. Given this release, buying the package also buys the diagnostic.
• Support and on-call triage. Age distribution, largest single files, per-host and per-file-type breakdowns (with gzip/brotli siblings excluded from page counts so compression never reads as growth) shorten the path from a disk alert to a cause.

When to Consider This Package

Adopt when:

• You are running — or considering — laravel-static for a mostly-GET, publicly cacheable Laravel site and need production-grade observability before you commit.
• Your traffic mix plausibly includes tracking parameters, newsletter links, or bot-generated variants; growth is the failure mode, and this release makes it visible.
• You want cache health in your existing monitoring stack: --json is explicitly intended for disk-usage alerts.
• Your cache lives on a local disk.
• You want the numbers and the levers on one screen — the report includes the config settings that govern cache growth, which shortens the loop from "disk is filling" to "change this setting."

Look elsewhere or down-scope when:

• The cache is on a remote disk. Inspection is local-only by design; walking a remote disk would be one API call per file. No workaround is offered.
• You run ephemeral or multi-node container filesystems, where per-node local cache inspection tells you little about aggregate behaviour.
• The dominant risk is personalized or authenticated responses. Static caching is the wrong layer; this tool will only confirm that.
• You need fine-grained, tag-based invalidation. This adds visibility, not invalidation semantics beyond static:clear.
• You want cache efficiency managed at the CDN/edge, where query-string normalization and purge APIs already exist.

How to Pitch It (Stakeholders)

For executives: our page cache grows forever — nothing is ever removed except by a full clear — and the usual cause is not the pages but their variants, so a single newsletter link can leave a file on disk indefinitely. This release adds one command that shows exactly where the space went and what to do about it, and can feed a disk alert automatically. It is a capacity-risk reduction, not new infrastructure: no schema change, no migration, no new service to run or pay for.

For engineering: additive release, no breaking changes to the caching behaviour. php artisan static:status is read-only and reports query-string vs non-query-string storage, cumulative directory sizes with pass-through levels collapsed, top URLs by variant count and most common query parameters, per-host and per-file-type breakdowns, age distribution, largest files, and the governing config values. --disk= and --limit= scope the walk, --json gives machine-readable output. Compressed siblings count toward size but not page count, so enabling gzip never looks like cache growth, and memory scales with distinct URL paths rather than files so it stays usable on the multi-million-file caches it is meant to diagnose. Limitation to note in the runbook: local disks only.