Laravel

Blaze just made Blade 10x faster. Here's how it works.

Last Monday, Caleb Porzio launched Blaze at the Laravel Worldwide Meetup. He rendered 25,000 Flux buttons in 6 milliseconds. The same page without Blaze? 1,333 milliseconds.

Daniel Plomp

06 Mar 2026 — 5 min read

That's not a typo. That's a 200x improvement on a single page render.

I've been using Livewire and Blade daily on a production app with 56 models and thousands of components. So when someone tells me they made Blade faster, I pay attention.

Here's what Blaze actually does, when you should use it, and where it'll bite you.

Why Blade got slow

Blade was never slow. Not really. Back in the Bootstrap days, your templates were glorified string concatenators. All the reuse happened in CSS. Blade just had to stitch together some HTML and call it a day.

Then Tailwind happened.

Instead of btn btn-danger btn-sm, you now have 15 utility classes on every element. Nobody copies that everywhere, so you extract components. A button becomes <x-button variant="danger" size="sm">. A table row becomes a component. An icon becomes a component. A badge becomes a component.

Suddenly a normal page has 500 to 1,500 Blade components. A beefy dashboard? 5,000 to 10,000. Each one goes through the full rendering pipeline: container lookup, view resolution, prop merging, attribute bag construction, slot handling. None of these are expensive on their own. But multiply them by thousands and you've got death by a thousand cuts.

Caleb benchmarked 25,000 empty Blade components (just a <button> tag, nothing else) at 80 milliseconds. That's pure overhead. The component does nothing and it still costs you.

What Blaze actually is

Blaze is a drop-in package that sits on top of Blade and pre-compiles your anonymous components into optimized PHP functions. No more container lookups. No more view resolution. Just function calls.

Installation:

composer require livewire/blaze

That's it. No config file. No service provider. If you're running Flux, all eligible components are already marked. Install the package and they get faster automatically.

For your own components, add @blaze to the top of any anonymous component, or optimize entire directories in your service provider:

Blaze::optimize()
    ->in(resource_path('views/components/ui'))
    ->in(resource_path('views/components/icons'));

The three levels

Blaze has three optimization strategies. Each one is more aggressive than the last.

Level 1: Optimized Compiler

This is what you get by default with @blaze. It replaces Blade's rendering pipeline with direct function calls. Everything gets hardcoded at compile time: file paths, component resolution, the works. No more lookups.

The numbers: 25,000 empty components go from 80ms to 14ms. For Flux buttons (which have a lot of internal logic), 1,333ms drops to around 200ms.

This level is safe. Caleb's words: "I don't use any of the stuff we stripped out, and I don't think you do either." The things it drops (view composers, view share, the $component variable) are features most people never touch in anonymous components.

Level 2: Memoization

Add memo: true and Blaze caches the rendered output of components with identical props. The cache key is the component name plus its parameters. Everything lives in a static PHP variable. No Redis, no database.

Three identical buttons that each take 100ms to render? First one costs 100ms. The other two are free.

This is great for icons, avatars, badges. Anything that shows up dozens of times with the same props on a single page.

Level 3: Compile-time Folding

This is the wild one. Add fold: true and Blaze renders the component at compile time and replaces it with the static HTML output. The component literally disappears from the compiled file. Zero runtime overhead.

25,000 buttons with folding: 3.5 milliseconds. Caleb's live demo of 50,000 components: 37ms. 100,000 components: 120ms.

But here's the catch.

Where folding will bite you

Folding works by evaluating your component once at compile time and baking the result into the cached file. If any part of that component depends on runtime data, you have a problem.

Caleb told this story during the launch: he enabled folding on the Flux docs sidebar. Every link looked correct. But when he navigated to a different page, the "current page" highlight didn't change. The URL bar updated, the content changed, but the sidebar was frozen.

The reason? The sidebar component used request()->url() to determine which link was active. Folding evaluated that once at compile time and hardcoded the result. Forever.

This isn't the kind of bug that throws an error. It's the kind you stare at for twenty minutes, blame your browser, clear your cache twice, and then realize something deeper is wrong.

Components that can't be folded:

Anything using request(), auth(), session()
Validation error displays (@error)
Components with side effects or external state
Anything where the output changes between requests

Components that are perfect for folding:

Static UI elements (buttons, cards, layout wrappers)
Components where all props are passed in and nothing is looked up externally
Icons and decorative elements

Blaze handles partial folding too. If a component is mostly static but has one dynamic prop, Blaze replaces the dynamic parts with placeholders, pre-renders the rest, and swaps the placeholders back at runtime. Clever, but you need to explicitly mark props as safe.

The profiler

This might be my favorite part. Blaze ships with a built-in profiler that shows you exactly what's happening:

Blaze::debug();

You get flame charts, per-component timing, a comparison between Blade and Blaze performance, and a breakdown of which components were folded, which were compiled, and which were skipped. It tells you where to focus your optimization effort instead of guessing.

What this means for the Laravel ecosystem

Caleb addressed the obvious question during the Q&A: why isn't this in Laravel core?

His answer was honest. Taylor asked him the same thing. But the optimized compiler strips out features that would be breaking changes in the framework (view composers, view share). And folding is a sharp knife that needs to prove itself in the wild first.

For now, Blaze is a standalone package. No Livewire dependency, no Flux dependency. Pure Laravel. Free and open source.

I think this is the right call. Let the community test it, find the edge cases, build confidence. If it holds up (and the early signs are very good), some version of this will probably end up in Laravel core eventually.

Should you install it?

If you're running any component-heavy Laravel app, yes. The optimized compiler alone (level 1) is a safe, no-config performance win. Start there.

Memoization is a clear win for repeated components. Enable it on icons and avatars.

Folding? Test it carefully. Start with components you know are static. Use the profiler. Don't fold anything that touches request state.

I'm planning to test it on Careerguide this week. With 56 models and a lot of Livewire-powered dashboards, the overhead adds up. Even a 50% reduction in Blade rendering time would be noticeable.