Livewire Blaze: Optimizing Blade Component Rendering

The first and more recent Blaze package comes from the Livewire team. It addresses a specific pain point that grows as your application scales: the overhead of rendering hundreds of Blade components on a single page.

The Problem Livewire Blaze Solves

Every time you use a Blade component in Laravel, the framework goes through a process: parsing the template, evaluating attributes, executing PHP logic, and finally outputting HTML. When you have a page with hundreds of components - think data tables, dropdown options, or repeated UI elements - this overhead adds up significantly.

The Livewire team demonstrated this with a benchmark: rendering 25,000 simple button components took about 750 milliseconds without Blaze. With Blaze, the same rendering took only 45 milliseconds. That is roughly 17 times faster.

How Livewire Blaze Works

Livewire Blaze uses a three-tier optimization strategy. You can choose the level that makes sense for your components.

Tier 1: Optimized Compiler

This is the baseline optimization. Blaze replaces Laravel's default Blade compiler with a more efficient version that turns templates into optimized PHP functions. According to the documentation, this alone can reduce rendering overhead by up to 97% for eligible components. You do not need to change anything in your templates to benefit from this tier.

Tier 2: Memoization

When a component receives the same props multiple times on a page, Blaze caches the rendered output after the first render and reuses it for subsequent identical calls. This is particularly useful for components like icons, avatars, or status badges that appear repeatedly with the same data.

Tier 3: Compile-Time Folding

This is the most aggressive optimization. Blaze pre-renders components into static HTML during the compilation phase, before your application even runs. At runtime, these components have effectively disappeared - there is no rendering overhead at all. This works only for components whose output does not depend on any runtime data.

Using the @blaze Directive

To mark a component for optimization, you add the @blaze directive at the top of your Blade component file.

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

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


    {{ \$slot }}

You can also control which optimization strategies are applied:

{{-- Enable all optimizations --}}
@blaze(fold: true, memo: true, aware: true)

{{-- Skip folding but keep memoization --}}
@blaze(fold: false, memo: true, aware: false)

When Not to Use @blaze

Not every component qualifies for optimization. The Livewire team provides a simple litmus test. Ask yourself these questions:

• Does the component render the same way for every user? (no authentication checks, no user-specific data)
• Does it render the same on every request? (no CSRF tokens, no request-dependent logic)
• Does it render the same at any time? (no timestamps, no relative time formatting)
• Does it only use props you explicitly pass? (no session data, no database queries)
• Are all child components also eligible for optimization?

If you answer no to any of these questions, you should not add @blaze to that component. Using it incorrectly can lead to subtle bugs that are difficult to trace.

Examples of components that should never use @blaze include:

• Forms with CSRF tokens
• Components that show authentication state
• Navigation links that highlight the current page
• Any component displaying error messages from validation
• Pagination components

The @unblaze Escape Hatch

Sometimes you have a component that is mostly static but needs a small dynamic section. A good example is a form input component that needs to display validation errors. The errors come from the request, so the component cannot be fully folded.

The @unblaze directive lets you mark specific sections as dynamic while keeping the rest of the component optimized.

@blaze
@props(['name', 'label'])


    {{ \$label }}
    

    @unblaze
        @if(\$errors->has(\$name))
            {{ \$errors->first(\$name) }}
        @endif
    @endunblaze

In this example, the div, label, and input are folded into static HTML during compilation. The @unblaze block remains dynamic and is evaluated at runtime. You get the best of both worlds.

Built-in Profiler

Livewire Blaze includes a profiler that helps you understand which components are benefiting from optimization. You can enable it with a single line of code:

Blaze::debug();

This generates flame charts and per-component timing breakdowns, making it easier to identify performance bottlenecks in your views.

Batch Optimization

If you prefer not to add directives to individual component files, you can optimize entire directories at once:

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

Mvaliolahi Blaze: Static Page Caching at the Web Server Level

The other Blaze package, created by Meysam Valiolahi, takes a completely different approach. Instead of optimizing component rendering, it caches entire page responses as static HTML files that can be served directly by Nginx, bypassing PHP and Laravel entirely.

The goal here is ambitious: achieving response times as low as 4 milliseconds by serving pre-rendered HTML from the file system.

Installation and Setup

You can install this package via Composer:

composer require mvaliolahi/blaze

After installation, you need to add blaze_id to your EncryptCookies middleware exception list:

class EncryptCookies extends Middleware
{
    protected \$except = [
        'blaze_id',
    ];
}

You also need to add the @blaze directive before your closing body tag to handle CSRF tokens properly.

Public vs Private Caching

This Blaze package distinguishes between two types of routes: public and private.

Public Routes

Public routes serve the same content to all users. Examples include your homepage, blog posts, or documentation pages. For these routes, Blaze generates a single cache file that is shared across all visitors. When someone requests the page, Nginx serves the static HTML file directly.

Private Routes

Private routes display personalized content that varies per user. Think of dashboards, profile pages, or settings screens. For these routes, Blaze generates separate cache files for each user, identified by a unique blaze_id cookie. When user-specific data changes, Blaze invalidates only that user's cache files.

You mark routes using middleware:

Route::get('/profile', [ProfileController::class, 'show'])->middleware('blaze:private');
Route::get('/posts', [PostController::class, 'index'])->middleware('blaze:public');

Model Integration and Cache Invalidation

The package includes a trait that you can add to your models. When a model changes, Blaze automatically invalidates cache files for related routes, ensuring users always see fresh content.

use Blaze;

class Page extends Model
{
    use Blaze;

    protected \$blaze_refresh = true;

    protected \$blaze = [
        'private' => ['profile', 'settings'],
        'public'  => ['homepage', 'posts.index'],
    ];
}

The \$blaze_refresh property tells Blaze to automatically regenerate the cache for the specified routes when the model changes. Note that enabling this feature may affect response time during the regeneration process.

Nginx Configuration

To serve cached files directly, you need to configure Nginx properly. The package documentation includes detailed Nginx configuration examples.

A simplified version looks like this:

location / {
    # Try private cache first, then public cache, then fall back to index.php
    try_files \$private_cache_file \$public_cache_file /index.php?\$query_string;
}

The configuration also includes map directives to handle the blaze_id cookie and sanitize URIs for cache file naming.

Considerations and Limitations

This approach works best for read-heavy applications where content changes infrequently. It adds complexity to your infrastructure because you need to configure Nginx and manage cache file storage. Some developers have raised concerns about this approach:

• It ties your caching strategy to the web server configuration
• If you have multiple Nginx instances, you need to synchronize cache files or use a shared storage solution
• The application becomes stateful in terms of cached files, which can complicate deployment

These concerns are valid, but for the right use cases, the performance benefits can be substantial.

Side by Side Comparison

To help you understand the difference clearly, here is how the two Blaze packages compare:

Which One Should You Use?

The answer depends entirely on what kind of performance problem you are trying to solve.

Choose Livewire Blaze If:

• Your application uses many Blade components on each page
• You have a design system with reusable UI components like buttons, cards, and badges
• You are already using Flux UI components (they are pre-marked for optimization)
• You want to optimize rendering without changing your infrastructure
• You are comfortable with experimental packages and can test thoroughly

Choose Mvaliolahi Blaze If:

• You run a content-heavy site where pages change infrequently
• You need the absolute fastest response times possible
• You have control over your Nginx configuration and can manage cache files
• You are willing to add complexity to your infrastructure for performance gains
• You want to reduce server load by serving static files directly

You Could Even Use Both

There is no rule saying you cannot use both packages in the same application. They operate at different levels and solve different problems. You could use Livewire Blaze to optimize your component rendering and mvaliolahi/blaze to cache entire pages. The two approaches complement each other.

Just be mindful of the tradeoffs. Adding more layers of caching and optimization increases complexity. Start with one approach, measure the results, and only add the second if you still need more performance.

Final Thoughts

The existence of two different packages with the same name can be confusing, but it also reflects the vibrant Laravel ecosystem. Developers are actively building tools to solve real performance problems, and sometimes those tools end up with similar names.

When you hear someone mention "Blaze" in a Laravel context, take a moment to understand which Blaze they are referring to. Are they talking about Livewire's new component optimizer, or the static page caching package from Meysam Valiolahi? The context usually makes it clear.

Both packages offer genuine value for the right use cases. Livewire Blaze addresses the overhead of modern component-driven UIs. Mvaliolahi Blaze provides a path to sub-10-millisecond response times for content sites. Understanding the difference helps you make the right choice for your project.

If you have used either of these packages in your projects, we would love to hear about your experience. Drop a comment below or reach out to us on social media.