- How do I install barryvdh/laravel-httpcache in a Laravel application?
- Require it with composer require barryvdh/laravel-httpcache. The service provider is auto-discovered, so there is nothing to add to config/app.php. Publish the config file to get config/http_cache.php, then attach the httpcache middleware alias to the routes or groups you want cached. There are no migrations, schema changes, or new services to provision.
- How does laravel-httpcache actually cache responses?
- It is a thin middleware wrapper that puts Symfony's HttpCache in front of the Laravel kernel. Responses that declare themselves cacheable are stored through Laravel's cache drivers and replayed for matching repeat requests, skipping routing, controllers, and database queries. It does not cache individual queries or Blade views, only full HTTP responses.
- Which Laravel versions does barryvdh/laravel-httpcache support?
- The package tracks Laravel majors, with compatibility releases for Laravel 11, 12, and 13 inside a stable v1.0.x line. That is healthy tracking, but it means every Laravel major upgrade adds a dependency task to your roadmap. Pin to v1.0.x and check the composer.json constraints in the repository before upgrading your framework.
- How do I configure the cache TTL for a route?
- TTL is set per route through middleware parameters and the published config/http_cache.php file, including a default_ttl option surfaced in v1.0.1. The same config controls which HTTP methods and status codes are cacheable, plus which routes are ignored entirely. Decide the business staleness tolerance in seconds for each endpoint before you set any of these values.
- How does cache invalidation work in laravel-httpcache?
- Invalidation is TTL-based and manual: entries expire after their configured lifetime or are purged explicitly. Cache tags are available for grouping entries when you want more targeted clearing. There is no automatic model-level invalidation, so any endpoint that cannot tolerate an N-second stale window is out of scope for caching.
- Which cache backends does laravel-httpcache work with?
- It stores through Laravel's existing cache drivers, so it inherits whatever Redis, Memcached, or file backend your platform team already runs instead of introducing a second caching system. That is the strongest cost argument against building bespoke response-caching middleware. Size the backend for the added key space, since Vary combinations multiplied by compressed variants can inflate storage quietly.
- How do I prevent logged-in users from seeing another user's cached page?
- This is the real correctness risk: malformed Vary handling or interaction with response-mutating middleware such as cookies, locale, and auth can produce silently wrong cache keys and cross-user leakage. Treat it as a correctness incident rather than a performance regression and gate the rollout behind a staging review. Keep authenticated routes in the ignored routes config unless you have proven key variance is correct.
- Is barryvdh/laravel-httpcache safe to run in production?
- Architecturally it is low risk: one Composer require, one published config file, one middleware registration, and a cheap reversal path. The headline concern is the bus factor, with roughly 500 stars, a single primary maintainer, and effectively zero declared dependents. Mitigate by pinning to v1.0.x, documenting a fallback to using Symfony HttpCache directly, and naming an internal owner who could fork it.
- How do I test that responses are actually being cached?
- Clear the cache between test cases and assert on the cache-related response headers and max-age values your routes emit. Because the middleware sits in front of the kernel, a cache hit never reaches your controller, so tests that assert on query counts or database writes will behave differently once caching kicks in. Exercise it against the same cache driver you run in production, ideally in a staging environment rather than only locally.
- How is laravel-httpcache different from using a CDN?
- It runs inside your Laravel middleware pipeline, so cache rules live in code and can vary per route. If a CDN already sits in front of the app, cache semantics have to be designed once, jointly, rather than layered opportunistically in two places. Also check the ROI first: below roughly 70% of traffic hitting genuinely cacheable responses, the case for expanding a pilot weakens materially.