Reducing Payload Bloat with Livewire Computed Properties

The Cost of Public State

In Livewire, every public property is serialized and sent to the browser as part of the component's state. When the component re-renders, that state is sent back to the server. This creates a performance bottleneck when dealing with large datasets or complex Eloquent models. If you store a collection of 50 users in a public property, you are transmitting that entire dataset over the wire on every single interaction, even if the data hasn't changed.

The solution is to move derived data out of the public state and into Computed Properties. These allow you to define data that is calculated on the server and accessed in the view, without ever being stored in the client-side snapshot.

How Computed Properties Optimize State

A computed property is essentially a method that returns a value, but Livewire treats it as a property. The primary advantage is the reduction of the network payload. Because the data is not "public," it is not serialized into the JSON object sent to the browser.

Furthermore, Livewire implements internal request-level caching for these properties. If you reference a computed property five times in your Blade template, the underlying logic (such as a database query) executes only once. This prevents the "N+1" query problem within a single render cycle.

Implementation Example: Filtered Product List

Consider a scenario where you have a search filter. Storing the resulting product list in a public property would bloat the payload. Instead, keep the search term as public state and the products as a computed property.

// App\Livewire\ProductSearch.php

namespace App\Livewire;

use Livewire\Component;
use Livewire\Attributes\Computed;
use App\Models\Product;

class ProductSearch extends Component
{
    public string $search = '';

    #[Computed]
    public function products()
    {
        // This query runs once per request, regardless of how many 
        // times $this->products is called in the view.
        return Product::where('name', 'like', "%{$this->search}%")
            ->where('active', true)
            ->get();
    }

    public function render()
    {
        return view('livewire.product-search');
    }
}

In your Blade view, you access the computed property as if it were a standard variable:

<div>
    <input wire:model.live="search" type="text">

    <ul>
        @foreach($this->products as $product)
            <li>{{ $product->name }}</li>
        @endforeach
    </ul>
    
    <p>Total results: {{ count($this->products) }}</p>
</div>

Execution Details

• Location: The #[Computed] attribute is applied to a method within the Livewire component class.
• Permissions: Requires standard Laravel application permissions to execute Eloquent queries.
• Expected Check: The $this->products call in the view should trigger the products()` method only once per request.
• Risk: If the logic inside the computed method is computationally expensive or lacks database indexing, it will slow down every server response.

Trade-offs and Limitations

Computed properties are not "reactive" in isolation. They do not trigger a re-render on their own; they are dependencies of other state changes. For example, the products list only updates because the $search property changed, triggering a component refresh.

Additionally, because the data is not stored on the client, you cannot access computed properties via JavaScript using @js or Livewire's JS API without triggering a new server request. If your frontend needs immediate access to the data for a JS library, a computed property is not the right tool.

Verifying the Performance Gain

To confirm that computed properties are reducing your overhead, you can perform two checks:

1. Network Payload: Open the Browser DevTools Network tab. Compare a request where a collection is a public property versus one where it is #[Computed]. You will see a significant reduction in the size of the snapshot object in the response.
2. Query Count: Use Laravel Telescope or the Clockwork extension. Verify that the database query inside the computed method executes exactly once, even if the property is referenced multiple times in the Blade template.