Blade Cache Directive Laravel Package

Product Decisions This Supports

• Performance budget for read-heavy pages. The package adds a @cache / @endcache pair of Blade directives that store a rendered template fragment in Laravel's configured cache store under an explicit key and TTL. This lets you cut server render time and database load on specific expensive fragments (navigation, pricing tables, marketing modules, "related items" rails) without re-architecting the page or introducing a separate caching tier.
• Scoping a caching initiative. Useful as the concrete tool when the roadmap item is "reduce p95 page latency" or "survive a traffic spike / launch day." It makes caching a per-fragment product decision rather than an all-or-nothing full-page decision, so you can cache the 80% of a page that is impersonal and leave the personalized shell uncached.
• Freshness as a product requirement. Because invalidation is keyed and manual, adopting this package forces an explicit answer to "how stale is acceptable?" per fragment. That is a product decision (TTL per module), not just an engineering one, and it should land in the spec.
• Build vs. buy. The alternative is a hand-rolled Blade::directive in the app, a full-page cache layer (e.g. response caching), or object-level caching in repositories. This package is the cheapest option when the pain is view rendering specifically; it is not a substitute for query caching or a CDN.
• Upgrade planning. v1.1.1 is a maintenance release adding Laravel 13.x compatibility, with no new features and no breaking changes. Product-facing meaning: the dependency remains viable through the next Laravel upgrade cycle, so a caching design built on it will not become an upgrade blocker in the next 12–18 months.

When to Consider This Package

Adopt when most of the following hold:

• Fragments are expensive to render (loops over large collections, computed aggregates, multiple queries) and impersonal or slowly changing.
• You can name a stable, deterministic cache key per fragment and a TTL that matches business tolerance for staleness.
• The team accepts manual invalidation: bumping the key, clearing on deploy, or wiring key segments to model versions. There is no model-event-driven invalidation built in.
• You want the smallest possible footprint — a single-purpose directive you can read in one sitting — over a framework or a caching service.
• You are on a currently supported Laravel version; v1.1.1 confirms Laravel 13.x support alongside earlier versions.

Look elsewhere when:

• A fragment is user-specific (dashboards, balances, permissions-gated content). Caching rendered HTML here risks one user seeing another's data unless the key is scoped per user, which usually erases the benefit. Prefer per-user object caching or leave it uncached.
• You need automatic invalidation tied to domain events (order placed, price changed). Use model-keyed cache strategies, repository-level caching, or a tag-capable store with a plan.
• The bottleneck is whole-page delivery for anonymous traffic — response caching or a CDN is the better first move.
• The cache driver is file and you need tag-based bulk invalidation; that capability is not available.
• Dependency governance prohibits single-maintainer packages on a critical path. Adopting means accepting bus-factor risk and a pinning/upgrade policy, and the v1.1.1 release is evidence of maintenance rather than a guarantee of it.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk performance lever, not a platform commitment. It lets engineering cache the slow, impersonal parts of high-traffic pages — the pieces that make pages feel slow during launches and peak load — without changing how the product works or investing in new infrastructure. The cost is measured in hours of implementation and a per-fragment freshness policy we define; the benefit is lower latency and less database load at exactly the moments that affect revenue and retention. The new release is a compatibility update for the next Laravel version, which means the approach stays supported through our upgrade roadmap and carries no migration work.

For engineering: One directive wrapping a fragment with a key and TTL; adoption is incremental and reversible per fragment. Two requirements before rollout: (1) every cached fragment must be provably impersonal or correctly key-scoped — cached HTML bypasses authorization and personalization logic, so a bad key is a data-leak class of bug, not a stale-content bug; (2) each fragment needs a named owner and invalidation strategy (TTL, key bump on deploy, or version segment) written down. Add cache hit/miss instrumentation per key so we can prove value and detect silent regressions. Pin the version and track the upstream repository; if maintenance lags behind a future Laravel release, plan to replace the directive with an in-house equivalent — a contained, low-effort fallback.