- How do I install and set up silber/page-cache in a Laravel app?
- Install it with Composer, publish the package config, and register the provided caching middleware on the routes or groups you want cached. No schema changes or extra infrastructure are required, since cached pages are written as flat HTML files on disk. The real setup work is deciding which routes are cacheable and what should invalidate them.
- Which Laravel and PHP versions does silber/page-cache support?
- It runs on modern Laravel releases with PHP 7.4 or 8.x and has no exotic server requirements beyond a writable cache directory. The v1.1.2 release extends the supported framework ceiling to Laravel 13. Confirm that the version you pin matches your framework major, and check that other edge-layer packages such as debug bars, A/B testing, and locale negotiation are also ready for that Laravel version.
- What is the difference between middleware mode and rewrite mode in page-cache?
- In middleware mode Laravel still boots, but the middleware short-circuits routing and returns the stored HTML, so you skip controller and database work. In rewrite mode your web server serves the static file directly and PHP never runs, which is where the largest speed gain comes from. Rewrite mode requires the cached file to be physically reachable by the web server, so it only works with the file store, not Redis or Memcached.
- How do I clear or refresh cached pages with silber/page-cache?
- The package ships Artisan commands for clearing and refreshing cached pages, and it exposes forget and remove primitives you can call from application code. Invalidation wiring is your responsibility: connect it to model events, admin publish actions, and deploy hooks. Plan the triggers up front, because stale pages are the most common source of bugs with any full-page cache.
- Can I use page-cache on routes for authenticated users or sessions?
- You should not cache session, cookie, or user-scoped responses. The package provides configurable bypass rules for auth, sessions, and non-GET requests, and you should enable them before going live. Serving one visitor's personalized page to another is a security incident rather than a performance bug, so keep candidate routes anonymous and non-personalized.
- How do cache tags and invalidation work in silber/page-cache?
- Cache tags and query-string awareness let you invalidate groups of pages instead of clearing everything. Tag support works best with a taggable store such as Redis, but that store forfeits the rewrite-mode benefit of serving static files before PHP boots. On the default file store you typically clear by URL or pattern and rely on your TTL as a safety net.
- Is silber/page-cache safe for production and multi-server deployments?
- It is a good fit for anonymous, read-heavy GET surfaces such as marketing pages, blogs, docs, and public listings. On a fleet, each node caches to its own local disk, so you get N divergent caches unless you share a volume or front everything with a CDN. The project is well regarded but has a single maintainer and thin recorded dependents, so treat it as a solid utility rather than a de-risked platform dependency.
- How do I exclude specific routes or requests from the page cache?
- Use the bypass rules in the config file for auth, sessions, and non-GET requests, and register the middleware only on the route groups you actually want cached instead of applying it globally. Skipping the middleware on specific routes keeps personalized or form-bearing pages out of the cache entirely. Decide this policy route by route before rollout rather than after the first stale-page report.
- Does page-cache handle query strings and CSRF tokens correctly?
- The package is query-string aware, so different query variants are stored as separate cached entries. CSRF is the bigger concern: cached HTML containing @csrf fields will serve expired tokens and produce 419 errors on form submissions. Keep cached pages form-free or add a token-refresh strategy for forms that must appear on cacheable pages.
- What are the alternatives to silber/page-cache for Laravel?
- Common alternatives include Laravel response caching packages such as spatie/laravel-responsecache, Nginx proxy_cache, and a CDN like Cloudflare or Fastly. silber/page-cache is per-origin and application-aware, so it complements a CDN rather than replacing it, and it is worth choosing only if you need full-page files served before the framework boots. Compare it against what your stack already does so you are not duplicating caching layers.