- How do I install vinkius-labs/laravel-page-speed in a Laravel app?
- Install it with composer require vinkius-labs/laravel-page-speed, then publish the configuration with vendor:publish. Register the middleware in app/Http/Kernel.php for Laravel 10 or bootstrap/app.php for Laravel 11–13. A working spike is realistically a one-to-two engineer-day effort, while a production rollout should include QA and staging.
- Which Laravel and PHP versions does Laravel Page Speed support?
- The package supports Laravel 10 through Laravel 13 and requires PHP ^8.2. Middleware registration differs between Laravel 10 and Laravel 11–13, and both patterns are documented. Confirm your exact framework and PHP patch level before adopting it across a large application.
- Can I enable only some page-speed optimizations instead of the whole middleware stack?
- Yes. Laravel Page Speed uses composable middleware, so you enable only the optimizations you need through config/laravel-page-speed.php. This makes adoption incremental and reversible per optimization rather than an all-or-nothing switch. It is the safest way to phase the package into an existing Laravel application.
- Does Laravel Page Speed work with REST APIs and JSON or XML responses?
- Yes, the package has dual scope for Blade-rendered HTML and JSON/XML API payloads without modifying your business payloads. API-focused middleware includes response caching and security headers, and a Content-Type guard prevents web HTML middleware from touching JSON or XML. Review which API middleware you enable, because caching and security headers change behavior at the edge.
- Which cache drivers are supported by Laravel Page Speed response caching?
- The README claims store-agnostic support for Redis, Memcached, DynamoDB via cache tags, file, and array drivers across Laravel 10–13. However, Laravel cache tags are not natively supported by file, array, or database drivers. Validate tag behavior and invalidation correctness for your chosen store before relying on response caching in production.
- Is Laravel Page Speed safe to use in production?
- It sits at the edge of the Laravel HTTP lifecycle, which is a low-blast-radius integration point, but its regex-based HTML rewriting has a history of production edge cases. The changelog documents fixes for PCRE stack exhaustion causing blank pages, Livewire and Alpine attribute corruption, TrimUrls corrupting JavaScript strings and SVG namespaces, and Octane/Swoole state leaks, all remediated in 4.4.x releases. Treat it as hardened by incidents rather than fully proven by design review, and stage the rollout with representative pages and API endpoints.
- Does Laravel Page Speed break Livewire or Alpine.js attributes?
- Earlier versions had whitespace collapsing corrupt Livewire and Alpine attributes, and that issue was fixed in 4.4.2. That does not guarantee every edge case is gone, because the package rewrites rendered HTML with regexes. Test pages that use Livewire, Alpine, inline JavaScript, meta tags, and SVG before enabling HTML optimizations in production.
- How is vinkius-labs/laravel-page-speed related to renatomarinho/laravel-page-speed?
- The README's Packagist download badge points at renatomarinho/laravel-page-speed, and the star count appears inherited, which strongly suggests vinkius-labs is a fork or successor of that well-known package. Before adoption, confirm who the legal maintainer of record is, whether the star count is transferred or organic, and whether upstream security fixes flow into this fork. Ask for a documented migration path if you are replacing the upstream package.
- Who should own HSTS, CSP, and Permissions-Policy if I enable ApiSecurityHeaders?
- Laravel Page Speed can emit security headers such as HSTS, CSP, and Permissions-Policy, which creates ownership ambiguity with your application, CDN, and WAF. Decide explicitly whether the package or your edge layer owns those headers, because misconfiguration can break third-party scripts in hard-to-attribute ways. Also note the X-XSS-Protection: 0 change in 4.4.3 and make that a deliberate application decision rather than a silent default.
- How do I verify the claimed latency and bandwidth gains from Laravel Page Speed?
- The Measured Impact table cites figures such as 99.6% latency reduction and 100% query elimination, but those are cache-hit microbenchmark results against a 1M requests-per-day, 65%-hit-rate reference scenario. Reproduce the benchmark with your own traffic shape, cache hit rate, and representative Blade and API endpoints before quoting numbers to stakeholders. Measure baseline latency, bandwidth, and error rates with the middleware disabled, then compare after a staged enablement.