# Laravel Page Speed: HTML and API Optimization Middleware for Laravel 10 to 13

> A middleware package from vinkius-labs that minifies Blade output and adds compression, caching and security headers to JSON APIs. Here is what it actually does, how to wire it up, and where it stops being the right tool.

**vinkius-labs/laravel-page-speed** — Package to optimize your site automatically which results in a 35%+ optimization. Laravel Page Speed delivers an end-to-end optimization pipeline for Blade-rendered pages and REST APIs with measurable gains in latency, bandwidth, and resiliency.

- Repository: https://github.com/vinkius-labs/laravel-page-speed
- Stars: 2,509 · Forks: 290
- Language: PHP
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/vinkius-labs-laravel-page-speed

## The problem Laravel Page Speed solves, and who has it

Laravel gives you a fast framework and then hands you the last mile unmanaged. Blade renders whatever you wrote, comments included. JSON endpoints return uncompressed bodies unless you added a compression layer. Security headers are your problem. Each of those is a small piece of work, and most teams end up with a handful of hand-written middleware classes that drift apart over time. Laravel Page Speed packages that last mile as a set of middleware you enable individually through config/laravel-page-speed.php. The README describes the scope as dual: rendered HTML and JSON/XML payloads, with the stated constraint that it does not modify your business payloads. That constraint is the interesting part, because it defines who the package is for. It suits teams running server-rendered Blade pages and a REST API behind the same Laravel application, on Laravel 10 through 13. It does not suit single-page applications where the HTML shell is nearly empty, because minifying an empty shell saves nothing. It also does not suit teams that already terminate compression and caching at a CDN or API gateway, since the work would be done twice.

## How the optimization pipeline is structured

The package is a stack of independent middleware rather than a single filter, and the README splits it into two groups. The web group covers HTML minification and comment stripping, which the README says stays compatible with Bootstrap, Tailwind and Livewire, targeted critical CSS inlining, and script deferral with DNS prefetching. The deferral mechanism uses data-ps-* guards to preserve execution order, which is the detail worth noticing: deferring scripts is easy, keeping them in order is not, and the package solves it with attributes rather than by rewriting script contents. The API group is broader. It includes adaptive compression that prefers Brotli and falls back to Gzip, with configurable size thresholds so small payloads are not compressed at a loss. It includes response caching with method-aware invalidation, dynamic tag derivation per path segment, and hit-rate metrics. It adds security headers (HSTS, CSP, Permissions-Policy), an automatic circuit breaker with customizable fallbacks, and a health check middleware the README describes as designed for Kubernetes probes. Observability is exposed through standard HTTP headers carrying latency, memory usage, cache hits and circuit status. Because each middleware is registered separately, the cost is proportional to what you enable. Turning on all seven API middleware is a different decision from turning on one.

## Installing Laravel Page Speed and registering the web middleware

Installation is a Composer require followed by publishing the package assets, which writes the configuration file you edit to choose middleware. The README gives both commands in sequence.

```bash
composer require vinkius-labs/laravel-page-speed
php artisan vendor:publish --provider="VinkiusLabs\\LaravelPageSpeed\\ServiceProvider"
```

Registration depends on your Laravel version. On Laravel 10 you append the middleware classes inside the web group in app/Http/Kernel.php. On Laravel 11, 12 and 13 you use the middleware configurator in bootstrap/app.php instead, extending the existing withMiddleware closure. The README is explicit that the order should stay deterministic, and its example lists InlineCss, ElideAttributes, InsertDNSPrefetch, CollapseWhitespace and DeferJavascript in that order.

```php
$middleware->appendToGroup('web', [
    \VinkiusLabs\LaravelPageSpeed\Middleware\InlineCss::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\ElideAttributes::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\InsertDNSPrefetch::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\CollapseWhitespace::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\DeferJavascript::class,
]);
```

After this, load a Blade page and view source. You should see collapsed whitespace and stripped comments, with script tags carrying data-ps-* attributes rather than plain defer attributes. If the source is unchanged, the middleware is not running: check that the classes were appended to the web group and not to a global stack, since a globally registered middleware runs before routing and may not see the response body the same way.

## Adding the API middleware and baseline environment variables

The API stack registers into the api group, and the README recommends attaching only the middleware that fits your API architecture. A reasonable starting set is security headers, response cache, ETag and compression, leaving the circuit breaker and health check until you have a reason for them.

```php
$middleware->appendToGroup('api', [
    \VinkiusLabs\LaravelPageSpeed\Middleware\ApiSecurityHeaders::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\ApiResponseCache::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\ApiETag::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\ApiResponseCompression::class,
    \VinkiusLabs\LaravelPageSpeed\Middleware\ApiPerformanceHeaders::class,
]);
```

The README's recommended baseline for cached APIs uses these environment keys. Note that API_CACHE_DYNAMIC_TAGS is set to true, which only makes sense on a cache store that supports tags.

```env
LARAVEL_PAGE_SPEED_ENABLE=true
API_CACHE_ENABLED=true
API_CACHE_DRIVER=redis
API_CACHE_TTL=300
API_CACHE_DYNAMIC_TAGS=true
```

After restarting, request an API endpoint and inspect the response headers. You should see the performance headers the README describes (latency, memory, cache hits, circuit status). A second identical request should report a cache hit. If the headers are absent, LARAVEL_PAGE_SPEED_ENABLE is the first thing to check, since it gates the package as a whole.

## Where Laravel Page Speed is the wrong tool

The package operates on the response body inside the Laravel request cycle, and that position is also its main limitation. Anything that never reaches a Laravel response is untouched: static assets served directly by nginx, images, fonts, and any HTML produced by a separate front-end build. If your application is a Next.js or Vue SPA with a thin Laravel API behind it, the web middleware group has almost nothing to minify, and you should skip it entirely.

The API caching layer deserves the same skepticism. The README states that invalidation is method-aware, which means a POST, PUT or PATCH to a path presumably clears the related cache entries. That is a sensible default, but it is a heuristic about your routes, not a guarantee about your data. If your API mutates state through a different path than the one it reads from, or through a queue worker or scheduled job, the cache will not know. The README does not document a rollback procedure for the package, and it does not describe how the circuit breaker decides when to open beyond calling it automatic. Those are the two places where I would read the docs/ directory before enabling anything in production. The Dockerfile in the repository is a development environment, not a deployment recipe: it is built on php:8.2-cli and its final command is php -a, an interactive shell.

## How it compares with doing the same work at the edge

The obvious alternative is not another PHP package. It is moving compression, caching and security headers out of the application and into a reverse proxy or CDN, where nginx, Cloudflare or an API gateway handles them before the request reaches PHP. The difference in approach matters. An edge layer works on every response regardless of which application produced it, and it keeps working if you later rewrite the API in another language. Laravel Page Speed works only inside Laravel, but it can do things an edge layer cannot: it knows your routes, so it can derive cache tags per path segment and invalidate on the methods that actually mutate data. It can also inline critical CSS into the specific Blade output it just rendered, which requires seeing the final HTML.

There is also the older package this one is related to. The README's badge row links to renatomarinho/laravel-page-speed for total downloads, which suggests the vinkius-labs package is a continuation or fork of that lineage. If you are already running the older package, the practical question is whether you need the API middleware group, since that is the part the web-focused original did not cover. If you only need HTML minification, the migration may not be worth the churn.

## Maintenance cost, licence and what to check before upgrading

The repository is not archived, and the last push was on 2026-06-04, which is recent enough that the project is being worked on. The release history shows v4.4.2 in May 2026, v4.4.3 described as bug fixes and security hardening, and v4.4.4 in June 2026 described as code hygiene, trait extraction and regex simplification. Two of the three most recent releases are maintenance rather than features, which is a fair signal about where the project is: stable, with periodic cleanup. The version numbering means upgrades within 4.4.x should be low risk, but the middleware class names are part of your bootstrap/app.php or Kernel.php, so a major version that renames or removes a middleware class would be a breaking change in your application code, not just in the vendor directory.

The licence is MIT, which permits commercial use and modification with the copyright notice retained. That is permissive and carries no copyleft obligation on your own code, but it also means no warranty is provided. For a package that sits in the response path of every request, the absence of warranty is worth more than usual: if the response cache returns stale data, that is your incident, not the maintainer's. The README does not document a support policy or a version support window, so pinning the package version in composer.json is the only guarantee you have that a composer update will not change behaviour under you.

## Conclusion

Adopt it if you run Laravel 10 to 13 and want HTML minification plus API compression, caching and security headers without writing each middleware yourself. Do not adopt it if your pages are rendered by a JavaScript framework or your API responses are already shaped by a CDN or gateway. Verify first that the middleware order in bootstrap/app.php matches the README's example, that your cache driver supports tags if you enable dynamic tagging, and that DeferJavascript does not break inline scripts that expect to run before the DOM is parsed.

## FAQ

### What is page speed?

In this package's context, page speed is what the middleware pipeline tries to improve: the time and bandwidth a page or API response costs. The README frames it as an optimization pipeline for Blade-rendered pages and REST APIs with gains in latency and bandwidth.

### How to increase page speed in a Laravel application?

The README's approach is middleware: HTML minification and comment stripping, critical CSS inlining, script deferral with DNS prefetching on the web side, and compression, response caching, ETag and security headers on the API side. You enable each one through config/laravel-page-speed.php.

### How important is page speed for SEO?

The README does not discuss SEO or ranking effects, so the package makes no claim about it. What it does document are measurable technical changes such as smaller Blade page size and compressed API payloads.

### Which is faster, Laravel or WordPress?

The README does not compare Laravel with WordPress, so this package has nothing to say on the question. Laravel Page Speed only applies inside a Laravel application, on Laravel 10 through 13, and cannot be installed into WordPress.

## Sources

- [Issues](https://github.com/vinkius-labs/laravel-page-speed/issues)
- [License: MIT](https://github.com/vinkius-labs/laravel-page-speed/blob/master/LICENSE)
- [README](https://github.com/vinkius-labs/laravel-page-speed/blob/master/README.md)
- [Releases](https://github.com/vinkius-labs/laravel-page-speed/releases)
- [vinkius-labs/laravel-page-speed on GitHub](https://github.com/vinkius-labs/laravel-page-speed)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vinkius-labs-laravel-page-speed