Livewire 4 shipped the Islands architecture as its headline performance feature, and it is worth understanding in depth if you are still on Livewire 3 or evaluating the upgrade. The short version: only the parts of a component that actually change get diffed and updated, resulting in roughly 60% fewer DOM operations in typical applications. Here is how it works.
The Problem With Full-Component Re-Renders
In Livewire 3, every time a component updated, Livewire would re-render the entire component template on the server and diff the result against the current DOM on the client. For simple components this was fine. For components with large static sections, navigation bars, headings, or anything that never changes, it was wasteful. The server was doing work it did not need to do, and the client was comparing DOM nodes that would never change.
The more properties a component had and the more complex its template, the more noticeable this became. Components with lists, nested templates, or expensive computed properties felt slower than they needed to.
What the @island Directive Does
The @island directive tells Livewire that a section of the template is a dynamic island. Everything outside the island is treated as static and excluded from the diff cycle entirely. Livewire only tracks, updates, and sends changes for the content inside island blocks.
The pattern is straightforward. You wrap the parts of your template that change in @island and @endisland tags. The rest of the template renders once on initial load and is never touched again.
For a component with a static header, a filter panel, and a dynamic results list, you would wrap only the results list in an island. The header and filter panel are out of the update cycle. When the user changes a filter and the results update, only the results island is re-rendered and diffed.
Lazy Islands for Below-the-Fold Content
Islands also support lazy loading with the lazy: true option. A lazy island does not render on initial page load. It loads when the island is scrolled into the viewport. While loading, a @placeholder block is displayed. This is useful for expensive sections that are not visible above the fold: analytics charts, related content sections, or any panel that requires a slow query.
The placeholder content can be a skeleton loader, a spinner, or a simplified version of the final content. The transition from placeholder to loaded content uses the native View Transitions API when available, giving a smooth visual update without any animation library.
wire:transition and the View Transitions API
Livewire 4 replaced its custom transition system with the browser's native View Transitions API. In Livewire 3, transitions used modifier syntax like wire:transition.opacity or wire:transition.fade. In Livewire 4, you use bare wire:transition and the browser handles the animation using the same mechanism that Chrome uses for page transitions.
This means transitions are hardware-accelerated, composable with CSS, and consistent with other transitions happening elsewhere in the browser. The modifier syntax from v3 will cause errors in v4 and needs to be removed during migration.
PHP 8.4 Property Hooks and Livewire 4
PHP 8.4 introduced property hooks, which allow you to define get and set behaviour directly on class properties without writing explicit getter and setter methods. Livewire 4 integrates with this feature to replace the old lifecycle hook pattern for intercepting property changes.
In Livewire 3, you would write an updatingPropertyName method to intercept a property change. In Livewire 4 with PHP 8.4, you define the logic directly on the property using the set hook. This keeps the behaviour collocated with the property definition, which is easier to read and maintain in components with many properties.
The SFC Format
Livewire 4 introduced single-file components, where the PHP class and the Blade template live in the same file in resources/views/livewire/. The PHP class uses the anonymous class syntax at the top of the file, above the template. No separate class file in app/Livewire/ is needed.
This is a significant ergonomic improvement for component-heavy applications. Finding, reading, and modifying a component is a single-file operation instead of jumping between a class file and a view file.
If you are building on Laravel and want to use Livewire 4 properly from the start, Cystall builds Laravel and Livewire applications for startups that want production-ready code without the trial-and-error of figuring out the framework yourself.