Livewire Blaze Made My Laravel App 10x Faster

Livewire Blaze is real, the numbers in its README are dramatic, and the install takes five minutes. Which is exactly why the first thing you should run is not composer require. It is a ten-second grep that tells you whether Blaze can help your app at all. I ran that grep on my own production Laravel site expecting to write an enthusiastic before-and-after post, and the audit told me something more useful: my app was never going to see those benchmark numbers, for a reason that will apply to a lot of Blade codebases. That reason is the actual story.

What Blaze does, precisely

Blaze is a compiler layer for Blade components from Caleb Porzio, the creator of Livewire and Alpine.js. Standard Blade compiles templates to PHP, but every anonymous component render still carries per-instance overhead: resolving the component, processing attributes, handling slots. Render a component a handful of times and it is noise. Render it hundreds or thousands of times per page and it becomes the bottleneck.

Blaze attacks that overhead two ways. It compiles anonymous components into optimized PHP functions instead of running the general-purpose component pipeline, and it "folds" static parts of a component into the parent template at compile time, so work that would happen on every request happens once at compilation.

The official benchmark in the Blaze README renders 25,000 anonymous components: roughly 500ms with standard Blade, roughly 13ms with Blaze. That is about a 97% reduction in rendering overhead, and the repo documents 91-97% reductions across its other scenarios. I have no reason to doubt those numbers. The question the README cannot answer is whether your app looks anything like the benchmark.

There is also a compounding effect specific to Livewire: every Livewire update re-renders the component tree on the server. Cheaper component rendering makes every interaction in a Livewire-heavy UI faster, not just first page loads.

The ten-second audit

Blaze optimizes anonymous Blade components, the ones you invoke with <x-...> tags. It explicitly does not support class-based components. So before installing anything, measure how much of your rendering actually flows through anonymous components:

grep -r "<x-" resources/views | wc -l

Here is what that audit returned on mejba.me, my production Laravel 11 site with a Blade/Livewire theme:

Six. My theme renders its cards, headers, and lists through 104 @include partials, a completely normal pattern for a theme that grew over years, and @include is not a component. Blaze has nothing to optimize there. Installing it on this codebase would speed up six tags used once each per page.

That is the insight I wish someone had led with: Blaze's benefit is proportional to your anonymous component density, and many real-world Blade codebases, especially older ones built on includes, have almost none. The benchmark renders one component 25,000 times. My busiest page renders maybe a dozen component instances. Same framework, unrecognizable workloads.

If your grep comes back with hundreds of hits concentrated in list rows, table cells, and card grids, you are the target audience and the README numbers are plausibly yours. If it comes back like mine, Blaze is not your next optimization, and you just saved yourself an afternoon of benchmarking to discover a rounding error.

The second reason my numbers would not have moved

There is a subtler point that applies to any content site: rendering cost only matters on requests that actually render.

My site serves guest pages with public cache headers (five minutes browser, an hour on the CDN edge, stale-while-revalidate beyond that) through a middleware that strips session cookies from cacheable responses. The overwhelming majority of guest traffic never touches Blade at all; it is served from edge cache. Server-side rendering cost concentrates on cache misses, logged-in users, and Livewire interactions, which for a blog is a thin slice of traffic.

So the honest ordering for a content-heavy Laravel site is: full-page caching for guests first, query optimization second (my write-ups on fixing N+1 queries and finding slow queries cover the two usual suspects), and template-layer optimization third. Blaze belongs at step three, and it shines brightest on pages you cannot cache: dashboards, admin tables, logged-in feeds, anything Livewire re-renders per interaction.

If your audit says yes: correct setup

The API is small. Install:

composer require livewire/blaze:^1.0

Then either opt in per component by putting the directive at the top of the template:

@blaze
<button {{ $attributes }}>
    {{ $slot }}
</button>

or opt in a whole directory in your AppServiceProvider:

use Livewire\Blaze\Blaze;

public function boot(): void
{
    Blaze::optimize()->in(resource_path('views/components'));
}

Afterward, clear compiled views so you are comparing fresh output:

php artisan view:clear

Benchmark your actual heaviest page before and after, with a warm cache, not the framework's demo scenario. If the win is real it will be obvious.

The limitations that will actually bite

These come straight from the package's documented constraints, and each one describes a codebase pattern that exists in the wild:

• Class-based components are unsupported. If your components have PHP classes with logic in them, they keep using standard Blade. Only anonymous components qualify.
• No $component variable, no view composers or creators, no auto-injected View::share() variables inside folded components. If your components quietly depend on globally shared view data, folding changes behavior, not just speed.
• @aware does not cross the Blaze/Blade boundary. Mixed trees where a Blaze child needs attributes from a Blade parent will not resolve the way they did.
• You cannot render Blaze components via view() directly.

None of these are flaws; they are the contract that makes the speedup possible. Folding is only safe when a component is a pure function of its inputs. The practical rule: opt in your simple, presentational, frequently repeated components (buttons, badges, rows, cards) and leave anything clever alone.

The decision rule

Compressed to three lines:

1. grep -r "<x-" resources/views | wc -l. Low count: stop, optimize queries and caching instead.
2. High count on uncacheable, high-render pages (Livewire tables, dashboards): install, opt in the hot components, benchmark your real page.
3. Trust your own numbers over anyone's benchmark, including the README's and definitely including any blog post's.

Blaze is good engineering, and my respect for it went up, not down, when my audit said "not for this app." Tools with sharply defined win conditions beat tools that promise everything. If you are on the Laravel-plus-AI side of my stack, I documented a similar honest-audit approach to a much newer tool in my hands-on look at the Laravel AI SDK, and the same measure-first mindset applies to Laravel on constrained shared hosting.

If your Laravel app feels slow and you are not sure whether the culprit is queries, caching, or rendering, that diagnosis is a couple of hours of profiling with the right tools. Send me what you are seeing through my contact page and I will tell you honestly which layer to attack first, even if the answer is "not the one the newest package optimizes."