Cache Bundle Laravel Package

Product Decisions This Supports

• Deploy-time cold-cache strategy. The core problem this solves is real: after a release, early users pay full render cost because nothing is cached. A warmup command converts "the site is slow for five minutes after every deploy" into a predictable, testable pipeline step. That is a product decision about release quality and perceived performance, not an architecture debate.
• Whether to invest in HTTP reverse-proxy caching at all. If you cache public GETs behind Symfony HttpCache, Varnish, or a CDN, you need a warmup story. If you can't define a safe URL set to warm, that's a signal your cacheable surface is too personalized to bother with.
• Roadmap input for performance budgets. Warmup pulls p95 TTFB for anonymous traffic after deploy into the same band as steady state. That changes which performance items are worth a sprint and gives you a defensible acceptance criterion for launch readiness.
• Build vs. reuse. The existence of a small MIT command is an argument for building a ~100-line equivalent rather than adopting a dependency. Treat this repo as a spec and a sanity check on scope, not as a library.
• Campaign and SEO readiness. Marketing asks "will the landing page be fast at 9am on launch day?" A prewarm step lets you answer yes with evidence. Without it, the answer is "probably, once enough people have hit it."
• Important caveat: despite the framing, this is a Symfony2 bundle, not a Laravel package. It will not install in a Laravel app and has no Laravel-specific value. Its only transferable contribution is the pattern, so every decision below should read as "reimplement this" rather than "adopt this."

When to Consider This Package

Consider it — narrowly — when:

• You maintain a legacy Symfony 2.x application that already uses HttpCache, you are not upgrading it, and you need a warmup step you can drop in today with minimal effort.
• You can enumerate a stable URL set at build time: a sitemap, a route table, or a curated top-N list of public pages.
• Your cache sits in front of anonymous, cacheable GETs. Warmup only pays off where post-deploy hit rate actually moves a number you care about.
• You want a reference for the mechanics: iterate URLs, issue requests concurrently, respect Cache-Control, report failures.

Look elsewhere when:

• You're on Laravel. This won't install. Write an Artisan command, or pair spatie/laravel-responsecache with your own warmer, or warm from the deploy tool (Envoy, Deployer, a CI curl loop).
• You're on Symfony 3.4+. The bundle targets Symfony 2, is archived, last released February 2016, with zero dependents. No maintainer, no security response, no PHP 8 support. 38 stars and a low adoption score reflect that accurately.
• Responses are authenticated or personalized. Warmup either does nothing or warms the wrong variant and can poison cache — a worse outcome than a cold cache.
• Your CDN has a prewarm or edge-population API. Use that; app-level warming is the wrong layer.
• The real problem is origin cold-start — opcache, JIT, DB connection pool. Different fix, different owner.

How to Pitch It (Stakeholders)

Executives: There's a small open-source tool that addresses a measurable issue: the first few minutes after every deploy serve slower pages because the cache is empty. It's MIT, and the idea costs roughly a day of engineering — no license, no vendor. The package itself is abandoned and tied to a framework we don't use, so I am not proposing a dependency. I'm proposing we copy the pattern into our own deploy pipeline behind a flag and measure the result.

Engineering: Do not composer require this. It's Symfony2-only, archived, last released February 2016, zero dependents, and will not survive PHP 8. What we want is the behavior: after deploy, enumerate our cacheable GET routes, fire them concurrently at the origin, and fail the build loudly if the warmed ratio drops below a threshold. One Artisan command plus a deploy-script step, gated by config so it never runs against authenticated routes or staging data. Land it with a before/after on p95 TTFB for anonymous traffic in the ten minutes post-deploy, and revisit only if we ever inherit a Symfony 2 estate.

Bottom line: adopt the pattern, not the package; scope it to about a day; treat it as deploy configuration rather than a product feature.