Blaze Deep-Dive
Blade components are slow. Really slow. At scale, they quietly become the biggest bottleneck in your Laravel application. We discovered this while trying to make Flux as fast as possible, and the result is Blaze: a package that fundamentally rethinks how Blade components are compiled and rendered. With multiple levels of optimization, Blaze can shave hundreds of milliseconds off a page load, making Blade rendering up to 25x faster in some cases.
In this series, we'll install it, benchmark it, build a toy version from scratch so you truly understand how it works, and then master every directive and edge case so you can squeeze maximum performance out of your own apps.

Progress
Series Info
- Episodes
- 20
- Run Time
- 2h 13m
- Difficulty
- Advanced
- Last Updated
- Apr 23, 2026
- Version
- Latest
Series Episodes
- Getting Started (3)
Why Blaze Exists
It started with Flux. Users were reporting slowness, and when we traced the problem, Blade components themselves were the culprit. Not Flux. Not Livewire. Blade. In this episode, we'll look at what we found and why we built an entirely new package to fix it — not just for Flux, but for every Laravel application.Installing Blaze
Blaze takes seconds to install, and if you're using Flux, the gains are immediate. We'll add the package, clear the view cache, and watch a demo page drop from ~700ms to ~35ms. Optimizing your own custom Blade components takes a bit more work — but we'll get there.Three Levels Of Optimization
Blaze isn't a single trick. It's three. The optimized compiler cuts out Blade's overhead. Memoization caches repeated components within a request. And code folding pre-renders components at compile time, eliminating their runtime cost entirely. We'll walk through each level and watch a page go from 750ms to 50ms.
- How Slow Is Blade, Really? (2)
Benchmarking Blade
How slow is Blade, actually? Let's answer that question. We'll benchmark 25,000 button renders across every approach we can think of, from full components all the way down to inline PHP. The results are pretty surprising.How The Blade Compiler Works
Blade compiles your.blade.phpfiles into raw PHP and stores them instorage/framework/views. We'll crack open those compiled files, compare their output, and see exactly where all that overhead comes from. This knowledge pays dividends well beyond Blaze.
- Building a Toy Version (8)
Intercepting Blade Compilation
The best way to understand Blaze is to build your own. We'll hook into Blade's compilation pipeline, match component tags with regex, and replace them with custom output. This is the foundation of how Blaze works under the hood.Refactor Into A Compiler Class
Before we add features, let's clean up. We'll extract our logic into a dedicatedCompilerclass, use named capture groups for component matching, and set ourselves up for the real optimizations ahead.The Optimized Compiler
Now for the first real win. Instead of letting Blade load components the expensive way, we'll compile them ourselves and avoid all that overhead. This is Blaze's default optimization, and it's already dramatically faster.The Blaze Directive
Not every component needs optimization. We'll add support for the@blazedirective so components can opt in explicitly. If a component contains@blaze, we optimize it. If not, normal Blade handles it.How Fast Is Our Toy
Let's benchmark what we've built. Our toy Blaze already delivers huge gains — but when a component itself is expensive, cutting out Blade overhead isn't enough. We need memoization and code folding to go further.Adding Memoization
The idea is simple: render a component once, remember the result, and reuse it every time that same component appears again on the page. The first render pays the cost; every repeat is essentially free. This is the memo: true optimization brought to life.Code Folding
This is the real magic. Code folding renders a component at compile time and bakes the HTML directly into the compiled file. Runtime cost drops to nearly zero. It's the most powerful optimization Blaze offers.From Toy To Real
Now that we've built our own version from scratch, we can crack open the real Blaze source code and actually understand what we're looking at. The architecture is the same, just with more polish and edge cases handled. No more black box.
- Mastering Blaze (7)
Limitations And Edge Cases
Blaze is powerful, but it has boundaries. Class-based components aren't supported.view()->share()needs a workaround.@awareonly crosses same-type boundaries. We'll cover every limitation so you know exactly what to watch for.The Blade Profiler
EnableBLAZE_DEBUG=trueand you get a world-class flame chart of every component on the page — render times, instance counts, self-time vs. total-time, color-coded by optimization level. This is how you find what's slow before you start optimizing.When To Memoize
Now that we know what's slow, let's fix it. We'll optimize the most expensive component in our demo app and learn why memoization is sometimes the right choice over folding. We'll also look at where memo falls short and when you need a different approach entirely.When To Fold
Some components always produce the same output for the same inputs. These are perfect candidates for folding. We'll apply it to the second most expensive component in our app and watch tens of thousands of renders collapse into a fraction of the time.Folding With Dynamic Props
What happens when a component is foldable, but some of its props are dynamic? This is a gnarly problem, and Blaze has an extremely clever solution. Understanding it is key to getting the most out of Blaze, and once it clicks, you'll be able to squeeze performance out of components you thought were off-limits.Punching Holes With Unblaze
Sometimes a component is almost entirely foldable — except for one dynamic piece. The@unblazedirective lets you preserve a small region's runtime behavior while folding everything around it. Perfect for validation errors, current-URL checks, and other bits that need to stay live.Ai Powered Optimization
Blaze ships with a Laravel Boost skill that can analyze your app and apply optimizations automatically. It gets most of the way there, but it's not perfect. We'll run it, review its decisions, and see where human judgment still matters.