Weave Code
Blaze Laravel Package
livewire/blaze
Blaze is a drop-in replacement for anonymous Blade components, compiling templates into optimized PHP functions and eliminating 91–97% of rendering overhead. Optional memoization and folding deliver even faster repeated renders.
Livewire Blaze is a drop-in performance layer for anonymous Blade components in Laravel. It compiles templates into optimized PHP functions, bypassing the standard rendering pipeline to remove up to 91–97% of rendering overhead—turning a 500ms render of 25,000 components into roughly 13ms—with near full Blade feature parity.
Enable it globally via Blaze::optimize()->in(...) for directories or per-component with the @blaze directive, then run php artisan view:clear.
- Drop-in replacement requiring no template changes
- Directory-wide optimization from a service provider
- Memoization for caching repeated renders
- Folding to pre-render components into static HTML
- Flux UI ready with zero configuration
Frequently asked questions about Blaze
- How do I install and enable Blaze in a Laravel application?
- Install it with composer require livewire/blaze:^1.0, then enable it either by adding the @blaze directive to the top of individual anonymous components or by calling Blaze::optimize()->in(resource_path('views/components')) in your AppServiceProvider boot method. After enabling Blaze, run php artisan view:clear so compiled views are regenerated through the new compiler. Flux UI users get optimization automatically and need no configuration at all. Start with a narrow directory and expand coverage only after verifying compatibility against the documented limitations.
- Is Blaze really a drop-in replacement for anonymous Blade components?
- Yes, for anonymous components rendered through component tags, the default function compiler is designed as a drop-in replacement that produces identical HTML with near full Blade feature parity. You do not need to change component markup or data flow to adopt it. The caveats are structural rather than configurational: class-based components, components rendered via view(), and components fed by view composers or creators fall outside what Blaze optimizes.
- Does Blaze support class-based Blade components?
- No. Blaze targets anonymous Blade components only, while class-based components stay on the standard rendering pipeline, and that is a structural exclusion rather than a configuration flag. There is no published roadmap commitment for class-based support. If your design system mixes both kinds, expect partial coverage and benchmark the anonymous subset separately.
- Which Laravel, PHP, Livewire and Flux versions does livewire/blaze support?
- The README documents installation as composer require livewire/blaze:^1.0 but does not publish a formal compatibility matrix for Laravel, PHP, Livewire, or Flux. Version support is only described at a high level, so validate it against your own dependency constraints before adopting. In a regulated environment, confirm the supported matrix with the maintainer rather than inferring it from the 1.0 tag.
- Is Blaze folding safe to use in production?
- Folding is the highest-risk strategy because it bakes static HTML at compile time and explicitly must not be applied to components that touch global state such as the database, auth, session, request, validation, time, or @csrf. Placeholder substitution for dynamic attributes and slots handles many cases but has documented break cases, and dynamic attributes bound to @props silently abort folding instead of failing loudly, so mistakes surface as wrong pages rather than exceptions. Treat folding as opt-in per component, verify output across every state a page can reach, and avoid it for anything that varies per user or per request.
- What is the difference between Blaze's default compiler, memoization and folding?
- The default function compiler converts anonymous components into generated PHP functions that bypass the standard render pipeline; it has near full Blade parity and the lowest risk, so it is the strategy to adopt broadly. Memoization adds caching for repeated renders, applies only to slot-less components, and derives its cache key from the component name plus props. Folding pre-renders a component into static HTML at build time for maximum speed, but it is only appropriate for fully static, state-free markup.
- Does Blaze work with Livewire and Flux UI?
- Blaze is published by Livewire, and Flux UI users get the shortest path: install the package and you are ready to go, with optimization applied automatically and no configuration required. For Livewire apps, the open question worth verifying is how folded output behaves under Livewire partial re-renders and on later requests where data has changed since compile time. The default compiled function strategy carries far less risk here than folding does.
- How do I deploy Blaze and manage compiled views with view:cache?
- Blaze hooks into Blade compilation, so compiled views must be regenerated after enabling it or after changing which components are optimized; run php artisan view:clear locally and in your deploy pipeline. If your CI/CD runs php artisan view:cache, confirm the ordering of view:clear relative to that cache step, since stale compiled views will not reflect the new configuration. Because folding mistakes show up as wrong pages instead of exceptions, include a visual smoke test of optimized pages in your deployment checks.
- Is Blaze mature enough to depend on, and what is the maintenance risk?
- Blaze is MIT licensed, maintained by Livewire, and shipped a single 1.0 release with roughly 750 GitHub stars and zero dependents, which is thin external validation for a package that changes how templates compile. The published release date looks anomalous relative to typical registry data, so consider validating provenance before pinning it in a regulated environment. Given the small integration surface, a sensible mitigation is keeping Blaze opt-in per directory so removal is just deleting one provider call.
- What are the known limitations and real performance gains of Blaze?
- Blaze does not support class-based components, components resolved through view(), or components whose data is injected by view composers and creators. Folding must be avoided on components touching the database, auth, session, request, validation, time, or @csrf, and dynamic attributes bound to @props silently abort folding rather than erroring. The advertised 91-97% reduction is measured on 25,000 component renders in a loop, so treat it as an upper bound on rendering-pipeline overhead rather than application TTFB and re-measure on your real pages.
Weaver
How can I help you explore Laravel packages today?