Go back

What the Heck Is Blaze and Why Do I Need It?

I’m not a developer. But I care deeply about the performance of our Laravel application. So when Caleb Porzio — the creator of Livewire, Alpine.js, and Flux UI — announced Blaze at Laracon US, I paid attention.

The promise? Your Blade components render up to 97% faster. The cost? One Composer command. The price? Free.

This article is my attempt to understand what Blaze actually does, explain it in plain English, and figure out whether we should be using it.

Table of contents

Open Table of contents

The One-Sentence Explanation

Blaze is a smarter compiler for your Blade components. It takes the templates you already have and makes them render dramatically faster — without you changing a single line of code.

That’s it. No new syntax. No rewriting components. No migration. Just speed.

The Problem Blaze Solves

Every time Laravel renders a Blade component, it goes through a pipeline: locate the file, parse the template, resolve attributes, render slots, merge data, and output HTML. For a single component this is fast. For a page with hundreds or thousands of components — table rows, icons, badges, avatars, navigation items — that overhead adds up.

Caleb demonstrated this at Laracon US: rendering 25,000 anonymous Blade components took 500ms. With Blaze, the same page rendered in 13ms. That’s a 97.4% reduction.

In a more realistic scenario, a data table with 29,000 Blade components dropped from 1.6 seconds to 131 milliseconds.

Even if your app is nowhere near that scale, the overhead compounds. If you’ve ever felt like a Laravel page was a touch sluggish despite caching, database optimisation, and query tuning — the rendering pipeline itself might be your bottleneck.

The Three Things Blaze Does

Blaze offers three levels of optimisation. Think of them as gears — you can use whichever combination suits your components.

1. Optimized Compiler (The Default)

The non-developer explanation: Normally, every time Laravel renders a component like <x-button>, it goes through a multi-step process — a bit like going through airport security every single time, even for the same flight you take daily. Blaze’s optimized compiler is like getting TSA PreCheck. It compiles your templates into streamlined PHP functions that skip the unnecessary steps while still getting you safely to the same destination.

What it does technically: Instead of running through Laravel’s full component rendering pipeline (locating view files, instantiating component objects, merging attributes, resolving slots through multiple layers), Blaze compiles templates directly into optimized PHP functions. The overhead drops by 91-97%.

When to use it: Everywhere. This is the default and works on any anonymous Blade component with no configuration needed.

2. Memoization (Cache Identical Renders)

The non-developer explanation: Imagine you have a page that shows 50 user avatars, and 10 of those users have the same initials “SB”. Without memoization, Laravel renders the avatar component 50 times. With memoization, it renders each unique combination once and reuses the result. It’s like a restaurant kitchen that makes one “medium-rare steak” and clones it for every table that ordered the same thing.

What it does technically: Blaze caches rendered output based on the component name and the props passed to it. If the same component receives the same props multiple times on a page, it renders once and returns the cached HTML for subsequent calls.

When to use it: Great for repeated components like icons, avatars, badges, and status indicators. Only works on components without slots (since slot content varies).

How to enable it:

@blaze(memo: true)

<div class="avatar">{{ $initials }}</div>

3. Code Folding (Pre-Render at Compile Time)

The non-developer explanation: Some components never change. A decorative SVG icon. A static navigation divider. A “powered by” footer badge. Code folding says: if this component always produces the same HTML, why bother rendering it at runtime at all? Just bake the final HTML directly into the compiled template. It’s like printing a document with the letterhead already embedded rather than assembling it from parts every time you hit “print”.

What it does technically: During the compile step, Blaze actually runs the component and replaces the component tag with its static HTML output. At runtime, there’s zero overhead — the component is gone, replaced by its result.

When to use it: Only for truly static components with no dynamic data. Components that access databases, authentication, sessions, the current time, or CSRF tokens must not be folded.

How to enable it:

@blaze(fold: true)

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path d="M12 2L2 22h20L12 2z"/>
</svg>

Components you should never fold: Anything that uses auth(), now(), session(), request(), csrf_token(), database queries, or any other runtime state. Blaze will try to detect these and throw an exception, but it can’t catch everything — so think before you fold.

Why Flux + Blaze Is the Easy Button

Here’s something I wish more people talked about: if you’re using Flux UI (the official Livewire component library), Blaze works out of the box with zero configuration.

Why does this matter for non-traditional developers like us?

Consistency removes complexity. When you use Flux components everywhere — buttons, inputs, modals, dropdowns, tables — you get a consistent, well-tested component library built by the same team that built Livewire and Blaze. Filip Ganyicz (@ganyicz) and the Flux team have already done the hard work of ensuring Flux components are Blaze-compatible.

You don’t need to understand the intricacies of the optimized compiler. You don’t need to manually audit which components can be memoized or folded. Flux handles the complexity. Blaze handles the speed. You just build your product.

This is a strong argument for being consistent with Flux components rather than mixing in custom Blade components, third-party UI kits, or hand-rolled HTML. The more you standardize on Flux, the more Blaze can optimise automatically.

If I used something else I’d constantly be trying to extend it. By using Blade, I’m free to do whatever custom things I want.

— Caleb Porzio, on building the Flux docs with plain Blade, X/Twitter

Installation: One Command

composer require livewire/blaze

That’s it. Blaze is free and open source under the livewire/blaze package on Packagist. It was tagged v1.0.0 today (February 24, 2026) — no longer beta.

If you’re using Flux, you’re done. If you want to opt-in specific components, add @blaze at the top of the template. If you want to enable it across directories, register them in your AppServiceProvider:

use Livewire\Blaze;

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

Three Ways to Approach Blaze (and Which I’d Recommend)

When I first looked at Blaze, I wanted to understand my options. Here are three approaches, roughly ordered from cautious to bold.

Option A: Surgical — Opt-In Per Component

Add @blaze only to components you’ve individually verified. Start with the obvious wins: icons, badges, static UI fragments.

Pros: Lowest risk. Full control. Easy to debug if something breaks. Cons: You’ll miss optimisation opportunities. Tedious to maintain as your app grows. Laravel conventions: Aligns with Laravel’s philosophy of explicit over implicit. Similar to how you’d selectively cache queries.

Option B: Directory-Based — Optimise Whole Folders

Use Blaze::optimize()->in() to enable the optimized compiler across your entire components/ directory. Selectively add memo: true and fold: true to individual components that benefit.

Pros: Good balance of coverage and control. Most developers will land here. Cons: Requires an initial audit of your components directory to check for edge cases. Laravel conventions: Follows the pattern of convention-based configuration (like route model binding or automatic event discovery). You set a sensible default and override where needed.

Option C: Full Flux — Let the Ecosystem Handle It

Use Flux components everywhere. Install Blaze. Trust the ecosystem.

Pros: Maximum performance with minimum effort. The Flux team tests Blaze compatibility. You stay focused on product, not infrastructure. Cons: You’re coupled to Flux. Custom components still need manual attention. Laravel conventions: This is the Taylor Otwell way. Laravel’s philosophy has always been about providing an opinionated, batteries-included stack. Livewire is the official interactive layer, Flux is the official UI kit, Blaze is the official optimiser. Use the stack as designed.

My Recommendation: Option B with a Bias Toward C

Start with directory-based optimisation (Option B). This gives you immediate, measurable performance gains with manageable risk. As you grow more comfortable and standardise on Flux components, you’ll naturally drift toward Option C — and that’s the sweet spot.

The key insight: the more consistent your component architecture, the more Blaze can do for you automatically.

What Would Taylor Otwell Do?

Taylor’s philosophy has always been: use the tools the framework provides, the way they were designed to be used. He champions Livewire as the default interactive layer. He hired Caleb Porzio. He endorsed Flux as the official UI kit. He blessed Blaze as part of the Livewire 4 release.

IMO Livewire takes Blade to the next level. It’s basically what Blade should be by default.

— Taylor Otwell, livewire.laravel.com

Taylor would install Blaze, use Flux, and move on to building features. He wouldn’t over-think it. He wouldn’t benchmark each component individually. He’d trust the ecosystem he built and the team he assembled.

That’s probably what we should do too.

The Limitations (Be Honest About Them)

Blaze is not magic. It has clear constraints:

  1. Class-based components are not supported — only anonymous Blade components
  2. The $component variable is not available inside Blaze-compiled templates
  3. View composers, creators, and lifecycle events do not fire — Blaze bypasses the standard rendering pipeline
  4. View::share() variables are not auto-injected — you can manually access them via $__env->shared('key'), but it’s not automatic
  5. @aware doesn’t work across Blade/Blaze boundaries — both parent and child must be Blaze components for @aware to propagate
  6. You can’t render Blaze components using view() — they must be rendered using the <x-component> tag syntax

These are trade-offs, not bugs. Blaze achieves its speed precisely because it bypasses the parts of the pipeline that enable these features. For most anonymous Blade components, you’ll never notice.

AI Prompt: Check Your Components for Blaze Limitations

Here’s a prompt you can use with Claude or any AI coding assistant to audit your components for Blaze compatibility:

Prompt:

Review the Blade components in my Laravel application and identify any that would be incompatible with Livewire Blaze (https://github.com/livewire/blaze). For each component, check for the following Blaze limitations:

  1. Class-based components — Blaze only supports anonymous Blade components. Flag any components that have a corresponding PHP class.
  2. Usage of $component variable — This variable is not available in Blaze-compiled templates. Flag any templates that reference $component.
  3. View composers, creators, or lifecycle events — These do not fire under Blaze. Check if any components rely on View::composer(), View::creator(), or view lifecycle hooks registered in service providers.
  4. View::share() dependency — Blaze does not auto-inject shared variables. Flag components that use variables not passed via props or slots that may come from View::share().
  5. Cross-boundary @aware usage — If a component uses @aware to access parent data, both the parent and child must be Blaze components. Flag any @aware usage and verify the parent component is also Blaze-enabled.
  6. view() function rendering — Blaze components cannot be rendered via the view() helper. Flag any places where components are rendered programmatically rather than via <x-component> tags.
  7. Folding safety — For components that might be candidates for fold: true, check if they access any runtime state: auth(), session(), request(), now(), csrf_token(), csrf_field(), database queries (DB::, Eloquent calls), config() with environment-specific values, or any other non-deterministic function.

For each flagged component, explain the specific issue and suggest whether it should: (a) use the default Blaze compiler, (b) use memoization, (c) use folding, or (d) be excluded from Blaze optimisation entirely.

Output a summary table with columns: Component Path | Issue | Recommendation.

Debugging with the Built-In Profiler

Blaze includes a profiler that generates flame charts and per-component timing breakdowns. Enable it with:

Blaze::debug();

This is invaluable for identifying which components benefit most from optimisation and verifying that Blaze is actually being applied where you expect.

The Bottom Line

If you’re building with Laravel and Blade components — and especially if you’re using Livewire and Flux — installing Blaze is one of the highest-impact, lowest-effort performance improvements you can make.

One command. No code changes. Free. Up to 97% faster rendering.

The only question is why you haven’t done it yet.

composer require livewire/blaze

Further Reading:

Sources: Research conducted across the official Blaze repository, Laravel blog, Laravel News, Packagist, Flux UI GitHub issues, and X/Twitter posts from Caleb Porzio and Filip Ganyicz.

Livewire Performance Blade
Back to top ↑