Laravel Blaze: What It Actually Does, When to Use It, and When It'll Break Your App

Your Blade components are slower than you think.

Not because you wrote bad code. The rendering pipeline itself carries overhead that compounds with every component you nest. A button component that takes microseconds on its own becomes a real bottleneck when you're rendering 500 of them across a dashboard. Caleb Porzio has been talking about this problem since Laracon US 2025: cached Blade components are still about 10x slower than plain PHP. Yesterday, at the Laravel Worldwide Meetup, he launched Blaze and ran the benchmark live: 25,000 components rendered in under 17ms

That's the problem Blaze solves.

Blaze is a new package from the Livewire team (livewire/blaze) that pre-compiles your Blade components into optimized PHP functions, skipping the standard rendering pipeline entirely. The numbers from the GitHub README are hard to ignore: 500ms down to 13ms for those same 25,000 components. That's a 97% reduction in rendering overhead.

But here's the thing most people will miss when they rush to install it. Blaze has three distinct optimization tiers, and the most aggressive one can silently break your app if you don't understand how it works. I've spent the morning reading through the entire source, the docs, and every edge case warning. This is the breakdown you need before you composer require anything.

What Blaze Actually Is (And Isn't)

Let's be clear about what Blaze does. It optimizes the Blade component rendering pipeline. Not your database queries. Not your API calls. Not your business logic. If your page is slow because of a 2-second Eloquent query, Blaze won't help you. You'll want to look at query-level optimizations for that.

What Blaze targets is the overhead that Blade itself introduces every time it resolves a component. Each anonymous Blade component goes through a multi-step process: locate the view file, resolve props, merge attributes, handle slots, compile the template, and render the output. For a single button, this is negligible. For a data table with hundreds of rows, each containing multiple nested components? That's where the milliseconds stack up.

Blaze replaces that pipeline with direct PHP function calls. Your template gets compiled once into an optimized function, and every subsequent render just calls that function. No view resolution. No pipeline overhead.

One important note: Blaze currently works with anonymous Blade components only. If you're using class-based components (the ones with a dedicated PHP class), Blaze won't optimize those. Anonymous components are the .blade.php files in your resources/views/components directory that don't have a corresponding class.

Installation and Basic Setup

Getting started takes about 30 seconds:

composer require livewire/blaze:^1.0@beta

That's it. No config file to publish. No service provider to register. Blaze auto-discovers and registers itself.

If you're running Flux UI (the official Livewire component library), you don't even need to do anything else. All eligible Flux components are already marked with @blaze. Install the package and your Flux components get faster automatically.

For your own components, you have two approaches.

Option A: Per-component directive

Add @blaze to the top of any component file:

{{-- resources/views/components/button.blade.php --}}

@blaze

@props(['variant' => 'primary'])

<button type="button" class="btn btn-{{ $variant }}">
    {{ $slot }}
</button>

Option B: Optimize entire directories

Register directories in your service provider:

use Livewire\Blaze\Blaze;

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

You can mix and match. Start with specific directories and expand coverage as you verify compatibility.

After enabling Blaze, clear your compiled views:

php artisan view:clear

This forces Blaze to recompile everything with its optimized pipeline. If you're curious what the compiled output actually looks like, you can diff the before and after in your storage/framework/views directory. It's a good way to build intuition for what Blaze is doing under the hood.

The Three Optimization Tiers

This is where it gets interesting. Blaze doesn't just have one optimization strategy. It has three, each progressively more aggressive. Understanding the differences is critical because picking the wrong tier for the wrong component is how you introduce bugs.

Tier 1: Optimized Compiler (Default)

This is what you get out of the box when you add @blaze or use Blaze::optimize(). Your Blade templates get compiled into optimized PHP functions instead of going through the standard rendering pipeline.

No configuration needed. No changes to your templates. It's a drop-in replacement that works with virtually all anonymous components.

Performance gain: Up to 97% overhead reduction.

Risk level: Very low. This tier maintains near-full feature parity with standard Blade. You can safely apply it to most components without worrying about edge cases.

Best for: Everything. Start here and stay here unless you have a specific reason to go further.

Tier 2: Memoization (Opt-in)

Memoization caches the rendered output of a component. If the same component appears multiple times on a page with identical props, it renders once and reuses the output.

Think about a dashboard with 200 status icons. Without memoization, each <x-icon name="check" /> goes through the full render cycle even though the output is identical. With memoization, it renders once, and the rest are cache hits.

@blaze(memo: true)

@props(['name'])

<svg class="icon icon-{{ $name }}">
    <use href="#icon-{{ $name }}" />
</svg>

Important limitation: Memoization only works on components without slots. If your component accepts {{ $slot }} content, memo won't apply because the slot content varies per usage.

Best for: Icons, avatars, badges, and any component that appears many times with the same props.

Tier 3: Compile-Time Folding (Opt-in)

This is the nuclear option. And I mean that in both the "extremely powerful" and "handle with extreme care" senses.

Folding pre-renders your component at compile time and embeds the raw HTML directly into the parent template. The component ceases to exist at runtime. No function call. No variable resolution. No overhead whatsoever.

@blaze(fold: true)

@props(['variant' => 'primary'])

<button type="button" class="btn btn-{{ $variant }}">
    {{ $slot }}
</button>

When you use this button with static props:

<x-button variant="secondary">Save</x-button>

Blaze doesn't render a component at runtime. It literally bakes the output into your template during compilation:

<button type="button" class="btn btn-secondary">Save</button>

Zero runtime cost. The component just becomes HTML.

But here's the catch. Folding only works when Blaze can determine all values at compile time. If you pass a dynamic variable:

<x-button :variant="$user->theme">Save</x-button>

Blaze can't fold this because it doesn't know what $user->theme is during compilation. It falls back to the function compiler (Tier 1) automatically. No error, no crash. Just no folding benefit.

Performance gain: Total elimination of runtime overhead. Rendering time becomes constant regardless of component count.

Risk level: High. This is where things can break.

When Blaze Will Break Your App

I'm spending extra time on this section because the Blaze docs include multiple warnings, and for good reason. Folding is the feature people will be most excited about, and it's also the one most likely to cause subtle, hard-to-diagnose bugs.

The Purity Test

Before you add @blaze with folding enabled, ask yourself these five questions about your component:

1. Does it work the same for all users? (no @auth, no auth()->user())
2. Does it work the same on every request? (no request(), no @csrf)
3. Does it work the same at any time? (no now(), no Carbon::now())
4. Does it only use props you pass in? (no session(), no config(), no DB queries)
5. Are all child components also foldable?

If you answered no to any of these, don't use folding on that component.

The Blaze docs call this the "pure function" mental model. Your @blaze components should be like pure functions in programming: same input always produces same output, with no side effects.

The Sneaky Failures

Here's what makes folding dangerous. These patterns look innocent but will produce bugs:

Config values that change between environments:

{{-- This button URL will be baked in at compile time --}}
@blaze

<a href="{{ config('app.url') }}/dashboard">
    Dashboard
</a>

If you compile views in production, config('app.url') gets baked in as whatever value it has at compile time. If you later change your .env, the link won't update until you clear compiled views. Easy to miss.

Components with CSRF tokens:

{{-- NEVER use @blaze with forms containing @csrf --}}
@blaze

<form method="POST">
    @csrf
    <button type="submit">Submit</button>
</form>

The CSRF token changes per session. Folding would bake in one token permanently. Every form submission would fail.

Time-dependent content:

@blaze

<footer>
    &copy; {{ date('Y') }} My Company
</footer>

On January 1st, this footer will still say last year's date until you clear views.

Components that contain non-foldable children:

@blaze

<div class="card">
    <x-user-greeting />  {{-- If this uses auth(), the parent breaks too --}}
    {{ $slot }}
</div>

Folding is contagious in reverse. A parent can't safely fold if any of its hardcoded children depend on runtime state.

What Blaze Catches (And What It Doesn't)

Blaze does try to protect you. It will throw an exception when it detects global state usage like auth(), session(), or request() inside a folded component. But the docs are explicit: it cannot catch everything. Patterns like accessing a helper function that internally queries the database, or using a Blade directive that resolves at runtime, can slip through undetected.

The rule of thumb: if you're unsure whether a component is safe to fold, don't fold it. The default Tier 1 compiler already gives you 97% overhead reduction. That's probably enough.

The Built-in Profiler

Blaze ships with a profiler that generates flame charts and per-component timing breakdowns. This is genuinely useful for identifying which components benefit most from optimization.

Enable it with:

Blaze::debug();

This adds a debug overlay to your pages with an "Open Profiler" button. The profiler shows every component rendered during the request, its duration, nesting depth, and which optimization strategy was used (compiled, folded, memoized, or standard Blade).

The profiler stores data in your application's default cache store, so make sure you're not using the array cache driver in development. Redis or file-based caching both work fine.

This is the right way to approach Blaze: enable the profiler first, identify your heaviest components, then apply optimizations strategically rather than blanketing everything with @blaze.

Blaze vs. Standard Performance Optimization

Here's where I want to be honest about expectations. Blaze solves a very specific problem: Blade component rendering overhead. For most Laravel apps, this isn't your primary bottleneck.

If your app is slow, the usual suspects are still database queries, external API calls, and unoptimized asset loading. I wrote about seven quick performance wins that cover those fundamentals, and honestly? Most apps will benefit more from proper indexing and query optimization than from Blaze.

Where Blaze shines is in component-heavy applications. If you've built a design system with reusable Blade components, or if you're running a Filament admin panel with complex table views rendering hundreds of components per page, the overhead reduction is genuinely meaningful.

Blaze is also particularly relevant for Livewire apps. Every Livewire re-render triggers Blade component rendering, so reducing that overhead has a compounding effect on interactivity. If you're rendering complex Livewire tables or dashboards, Blaze can make the difference between a snappy interface and a sluggish one.

My Recommendation

After reading the full source and docs, here's my take:

Install it. The Tier 1 compiler is safe enough for almost any project. The risk-to-reward ratio is heavily tilted toward reward. If you're on Laravel 10, 11, or 12 and you use anonymous Blade components (which you almost certainly do), there's very little reason not to add Blaze.

Start with Tier 1 only. Don't jump straight to folding. The 97% overhead reduction from the optimized compiler is already significant. Apply @blaze or Blaze::optimize() to your component directories and run the profiler to see the impact.

Use memoization selectively. If the profiler shows a component being rendered dozens of times with identical props (icons are the classic example), add memo: true. But don't blanket-enable it.

Approach folding with caution. Only fold components you've personally verified are pure. When in doubt, skip it. The difference between Tier 1 and Tier 3 matters most at extreme scale (thousands of components per page), and most apps don't hit that threshold.

One more thing. The package is marked as early-stage beta (v1.0.0@beta). The API could change, and there are edge cases still being worked out. Use it, but test thoroughly and keep an eye on the GitHub issues.

Frequently Asked Questions

Does Blaze work with Livewire components?

Blaze is specifically designed for anonymous Blade components, not Livewire components directly. But since Livewire components render Blade templates internally, optimizing the Blade components within your Livewire views does have a positive effect on overall Livewire performance.

Will Blaze conflict with my existing Blade setup?

No. The Tier 1 compiler is a drop-in replacement that maintains feature parity with standard Blade. If you experience any issues, you can remove the @blaze directive or uninstall the package entirely, and everything reverts to normal.

How do I know if Blaze is actually helping my app?

Use the built-in profiler (Blaze::debug()). It shows per-component timing and the optimization strategy applied to each component. Compare rendering times with and without Blaze to measure the actual impact on your specific application.

Does Blaze work with Laravel 10?

Yes. Blaze supports Laravel 10, 11, and 12 and requires PHP 8.1 or higher.

Should I use Blaze in production?

The Tier 1 optimized compiler is safe for production use. The package is marked as beta, but the core compilation strategy is well-tested. Folding (Tier 3) requires more careful validation before deploying to production. Always test thoroughly in a staging environment first.

Final Thoughts

Blaze addresses a problem that most Laravel developers didn't even know they had. Blade's component rendering overhead is invisible until you have enough components that it becomes visible, and by then you're usually blaming something else.

The fact that it's a one-line install with immediate benefits (Tier 1) and optional advanced features (memoization, folding) for when you need them makes it an easy recommendation. Just don't get too excited about folding before you understand the implications.

If you're building something component-heavy and performance matters, give Blaze a try. And if you need help optimizing your Laravel application's performance beyond just the rendering layer, let's talk