Image Cache Laravel Package

Product Decisions This Supports

1. Whether image performance gets its own roadmap line. Product listing and PDP performance is dominated by image payload and server-side render cost. This package caches the output of Intervention Image transformations — a 1200×1200 derivative is generated once and re-served from disk instead of recomputed on every request. That gives a PM two measurable levers (TTFB and LCP) under one roadmap item instead of a vague "make the site faster" initiative. If image work has been hiding inside a platform tax line, this is the artifact that lets you split it out and fund it.

2. Build vs. buy for image delivery — the decision you will eventually have to make. With Intervention doing the transform and this package doing the cache layer, "own derivative generation" becomes a real, costable option rather than an abstract preference. That means the buy candidates — Cloudinary, imgix, ImageKit, or CDN-native transforms — must now be priced against something concrete: our catalog size × derivative count × transform volume. A PM can force that comparison instead of letting it be argued on vibes.

3. How many derivative sizes the business is allowed to ask for. Caching turns "one more size" from a per-request CPU tax on every web node into an explicit storage number. Without a cache layer, every additional size quietly taxes every page render, which is why merchandising requests for a new crop or an OG card tend to get refused. With it, the cost of a new size is storage plus a config line — a legitimate product negotiation instead of a hard no. The package's templates config is the concrete mechanism: each preset (thumb, pdp_zoom, cart, og) becomes an explicit config diff rather than a magic number scattered across views, which means a PM can see and approve the derivative catalog.

4. Resize on upload vs. resize on demand. This is a long-running, low-grade argument that this package tilts decisively. On-demand-with-cache is usually the better product trade: it doesn't block the upload flow, doesn't require re-processing the back catalog when a size changes, and doesn't couple merchandising velocity to an ingest pipeline. Adopting this is effectively a decision to stop pre-generating variants on upload.

5. Infrastructure sizing and campaign survivability. Reducing per-request render cost is a credible lever for staying on smaller instances and for surviving a launch spike without a render storm — provided you accept the caveat that a cold cache has no locking or request coalescing, so the first traffic after a deploy or flush regenerates concurrently. The product framing: this buys headroom, but the campaign calendar is the input to a pre-warm plan, not a nice-to-have.

6. Scope discipline — the decision not to bundle things. This is not a DAM, not an image optimizer (no WebP/AVIF Accept negotiation, no compression tuning), and not a CDN (no signed URLs, no edge transforms, no responsive srcset generation). "Image stuff" is exactly the theme that absorbs three sprints with no clear owner. Adopting this package is a decision to do one thing — cache generated derivatives — and to keep the rest as separately owned roadmap items.

7. An ownership and risk-appetite decision, which is genuinely a PM decision. Zero stars, zero dependents, no upstream to file an issue against. That is not a technical footnote; it's a question of whether we are willing to say "we own this if it breaks." The documented escape hatch — a ~150-line decorator we write and test ourselves, costed at roughly half a day — makes this a decision with a known fallback rather than a one-way door. A PM should make that call explicitly rather than letting it be made by whoever writes the composer require.

When to Consider This Package

Adopt when all of these hold:

• You are on Laravel/PHP and already using Intervention Image v2. This is a decorator around a manager you already have, so integration cost is low. Run composer show intervention/image first — the cache layer depends on ImageManagerStatic and the v2 Response type, both removed in Intervention Image v3. On v3 this is a port, not an install, and a self-written decorator is the better trade.
• Images are self-hosted and you generate multiple derivative sizes per asset — the classic commerce pattern, highest fan-out, lowest risk.
• Traffic is meaningful but not extreme. You need to stop regenerating the same crop thousands of times an hour, but you are not at a volume where per-transform CDN pricing beats engineering time.
• You need caching inside the same deploy. No external service, no vendor contract, no per-transform billing.
• The team can pin and vendor a small MIT dependency and read its source when something breaks. Pin the exact version, commit the lock file, budget roughly an hour a quarter to re-check compatibility against Laravel and Intervention upgrades.
• You can own three things the package does not give you: an invalidation story (a version token — file mtime or updated_at — in the cache key, so replacing a product photo doesn't serve the old one until TTL expiry), an eviction/prune job (nothing caps disk growth), and a hit/miss metric (the real operational risk is silent 100% miss degradation after an upgrade — you stop hitting cache and start regenerating, with no error).

Look elsewhere when:

• You need modern format negotiation (AVIF/WebP with Accept fallback), signed URLs, or edge transforms. That is a CDN or a dedicated image service, not a patch to this package.
• Adoption risk is unacceptable. This is effectively an internal component of the Bagisto platform, not a supported standalone library. If we cannot say "we own this if it breaks," we should not adopt it.
• Scale justifies a managed service. At high transform volume, per-transform pricing is frequently cheaper than operating, monitoring, and invalidating our own cache.
• You are not on Bagisto. Confirm it isn't coupled to Bagisto's config, paths, and storage conventions. If it is, the honest comparison becomes "write the decorator ourselves," which is a perfectly good outcome — and often the preferable one.
• Cache invalidation is a first-class concern (frequent image replacement, per-tenant isolation). The naive key = source + params scheme needs extending, and that work is ours.

Recommendation framing: treat this as a reference implementation and optional shortcut, not a strategic dependency. Audit the source first (it is small), pin the version, and keep "inline the pattern" as the documented and pre-costed fallback.

Gate the decision on two cheap checks before any commitment: the Intervention major version, and whether the config is genuinely configurable (route, paths, templates, lifetime, cache driver). If any of those is hardcoded, this is surgery later, not configuration — and that changes the build-vs-buy math.

How to Pitch It (Stakeholders)

To executives (30 seconds): "Every product image on our storefront gets resized into several sizes. Today we either burn CPU redoing that work constantly or over-provision servers to absorb it. This is a small, free, MIT-licensed component that stores the resized result once and reuses it — faster pages, lower infrastructure cost, no vendor contract. It's a thin layer over a library we already use, and if we outgrow it we can move to a CDN without changing the product."

To engineering: "It's a caching decorator around Intervention Image: a hash-to-file lookup in front of the transform pipeline, with configurable templates, paths, and TTL. Two constraints up front. One — it's Intervention v2 only; ImageManagerStatic and the v2 Response type are gone in v3, so on v3 we'd be porting, not installing. Two — it has no eviction, no request coalescing, and a naive cache key, so before this goes near production we own four things: a version token in the key so replaced product photos invalidate, a scheduled prune for disk growth, a hit/miss metric so a silent 100% miss after an upgrade surfaces as an alert with a cause, and a pre-warm job for the two or three hottest templates after deploys and imports. Also note the lifetime unit is minutes, not seconds like Laravel's cache TTL — that's a five-minute bug that looks exactly like a cache that isn't working. The full surface is small enough that the fallback is inlining ~150 lines of it ourselves in about half a day; I'd want that scoped and accepted as the contingency before we commit, because there's no upstream to file an issue against. And it is not an optimizer and not a CDN — WebP/AVIF negotiation, compression tuning, and edge delivery stay on the roadmap as separate items with separate owners."