Weave Code
Laravel Response Compression Laravel Package
open-southeners/laravel-response-compression
Laravel middleware that compresses HTTP responses on the fly with gzip or brotli, cutting bandwidth and speeding up load times. Configurable compression level, content-type filters, and automatic Accept-Encoding negotiation.
Add server-side response compression with different algorithm support (Gzip, brotli, ztsd, lz4...)
Frequently asked questions about Laravel Response Compression
- How do I install and enable open-southeners/laravel-response-compression?
- Install it with composer require open-southeners/laravel-response-compression, then publish the package config with php artisan vendor:publish and register the middleware in your HTTP stack. Depending on your Laravel version that means Kernel.php or bootstrap/app.php. Check the README for the exact service provider and middleware alias in your release, since the package tracks Laravel changes closely.
- Which compression algorithms does this package support?
- It advertises gzip, brotli, zstd (sometimes written ztsd in the docs) and lz4 support. Each algorithm depends on the matching PHP extension being installed and enabled, so brotli needs ext-brotli, zstd needs ext-zstd and lz4 needs ext-lz4, while gzip is normally available through zlib. Run php -m on your servers and container images before relying on a specific algorithm.
- How does the middleware choose between gzip and brotli?
- It reads the client's Accept-Encoding header, matches it against the algorithms your PHP build actually supports, and compresses with the best mutually supported option, usually brotli where available and gzip as the fallback. You can typically restrict or reorder that preference list in the config file. Clients that send no Accept-Encoding, or only identity, receive an uncompressed response.
- Which Laravel and PHP versions does open-southeners/laravel-response-compression support?
- Version 3.3.0 adds Laravel 13 support and drops Laravel 11, giving the package a roughly two-major support window. Modern Laravel releases imply PHP 8.2 or newer, but confirm the exact laravel/framework and illuminate/* constraints in the package's composer.json. If you are still on Laravel 11 you will need to pin to the last 3.2.x release.
- How do I configure compression level and which content types get compressed?
- Configuration lives in the published config file, where you set compression levels per algorithm and define which content types should be compressed. Text-based responses such as HTML, CSS, JSON, JavaScript and SVG are the usual candidates, while images, video and already-compressed archives should be excluded. Also set a minimum response size threshold so tiny payloads skip compression, because the CPU cost is not worth it for a few hundred bytes.
- How can I verify that responses are actually being compressed?
- Use curl with --compressed and check the response headers for Content-Encoding: br or gzip, then compare the encoded size against the uncompressed payload. Browser dev tools show the same information in the Network tab, and you can assert on the header in Laravel feature tests. If the header is missing, check that the middleware is registered, the content type is allowed, and the response is large enough to pass your minimum size threshold.
- Should I disable gzip or brotli in nginx or my CDN when using this middleware?
- Usually yes, you should compress in exactly one place. If nginx, Apache, a load balancer or a CDN already compresses responses, running this middleware as well risks double compression or conflicting Content-Encoding headers, and the CDN may re-compress anyway. Choose edge compression or application-level compression, not both, unless you specifically need per-route or per-content-type control inside Laravel.
- What changed in 3.3.0 and what should I do if I am still on Laravel 11?
- Version 3.3.0 adds Laravel 13 support and removes Laravel 11, along with PHPStan typing corrections and test-suite fixes, with no new features announced. Dropping a framework version in a minor release is effectively a breaking change for Laravel 11 users. Stay pinned to 3.2.x as a tracked, time-boxed exception, or upgrade to Laravel 12 or 13 and move the package to 3.3.0.
- Does it work with Laravel Octane, streamed responses and file downloads?
- Because the middleware operates on the response content, it is most reliable for normal buffered responses. Streamed responses, Server-Sent Events, file downloads and binary responses may bypass or break compression depending on the response type, so exclude those content types in the config. Under Octane it should behave like ordinary middleware, but test long-running workers and memory limits in staging first.
- What are the alternatives to this package, and when should I use server-level compression instead?
- The main alternative is doing nothing in PHP and enabling gzip or brotli at nginx, Apache, or your CDN, which offloads the CPU cost from your application servers. This package makes sense when you want compression decisions inside Laravel, for example per-route control, content-type filtering, or environments where you cannot change the web server. Benchmark both approaches on real traffic before adding application-level compression.
Weaver
How can I help you explore Laravel packages today?