Introducing the Blaze package

Learn how to use Livewire’s official Blaze package to speed up Blade component rendering. Covers how to choose between compile / memo / fold, installation, limitations, and how it works internally.

This article is based on the livewire/blaze README as the primary source. At present there is no dedicated Blaze documentation on laravel.com.

What is Blaze?

Blaze is a Blade component acceleration package published officially by Livewire. It targets not only Livewire components but also ordinary anonymous Blade components.

The README shows a benchmark of 25,000 renders of an anonymous component going from 500ms → 13ms (about a 97.4% reduction). Per-scenario reductions between 91% and 97% are also reported.

Three optimization strategies

Blaze provides three strategies: compile (default), memo, and fold.

Which one to choose

Strategy	When to choose	Benefits	Notes
compile	The standard strategy to start with	High compatibility; easy to speed up without configuration	Common limitations must be checked
memo	Icons, badges, etc. rendered many times with the same props	Reduces the cost of re-rendering after the first render	Cannot be used with components that have slots
fold	UI that can be statically determined; when aiming for maximum performance	Almost eliminates runtime overhead	Mishandling global state or dynamic values leads to inconsistencies

If you’re unsure, the safest approach is to start with compile and apply memo / fold only to bottlenecks you’ve identified.

Installation and enabling

composer require livewire/blaze:^1.0

There are two ways to enable it.

1) Add @blaze to individual components

@blaze

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

Switch strategies as needed.

@blaze(memo: true)
@blaze(fold: true)

2) Enable per directory with Blaze::optimize()

use Livewire\Blaze\Blaze;

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

After enabling, clear compiled views.

php artisan view:clear

@blaze is suited to “try it out first,” while Blaze::optimize() is suited to “apply broadly in production.” The README also recommends applying it gradually, starting from a limited directory.

Limitations

Limitations explicitly listed in the README:

• Class-based components are not supported
• The $component variable is not available
• View composers / creators / lifecycle events do not fire
• View::share() variables are not auto-injected (use $__env->shared('key') explicitly if needed)
• @aware across Blade and Blaze has limitations (both parent and child must be on the Blaze side)
• You cannot render a Blaze component directly via view() (only through the component tag)

Compatibility with Flux UI

The Blaze README notes that if you use Flux UI, you can start using it just by installing Blaze, with no additional configuration.

How it works

Ordinary Blade always goes through a rendering pipeline that includes component resolution and attribute processing. Blaze’s compile compiles this into an optimized PHP function and calls it directly, greatly reducing pipeline overhead.

As the README explains, the conceptual differences are:

• Normal: run Blade’s standard rendering process every time
• Blaze compile: call a pre-compiled function directly
• Blaze fold: inline HTML at compile time to further reduce runtime computation

fold is fastest, but breaks down when factors that invalidate static assumptions (auth state, request-dependent values, session-dependent values, time-dependent values, etc.) are involved. Apply it only to hot spots, gradually, while verifying behavior.