How to Lazy Load Slow Dashboard Components in Laravel Livewire

A Laravel dashboard can feel slow when a chart, report, or summary card runs an expensive database query before the page appears. Livewire can wait to load one component while the rest of the dashboard renders. Lazy loading starts a component’s request when the component enters the browser’s visible area; deferred loading starts it after the initial page load finishes.

Use lazy loading for dashboard components that sit farther down the page. Use deferred loading when a component should load after the page appears regardless of whether the reader has scrolled to it. Both approaches change when Livewire loads a component, so they can keep its work from blocking the initial dashboard response.

Choose which dashboard component to delay

Start with the component whose query or rendering work slows the initial dashboard. Keep quick, useful content in the initial render, and delay the slow card or chart. Lazy loading changes when that component’s work runs; it does not make the underlying query faster.

Laravel Pulse reports performance data, including slow jobs and endpoints. Use those reports alongside your dashboard’s own measurements to find a component worth delaying. The Laravel Pulse documentation describes the performance and usage insights it tracks.

Add lazy to the component

In the dashboard’s Blade view, pass lazy to the Livewire component:

<livewire:revenue lazy />

Livewire loads the component when it enters the visible part of the browser window. The Livewire lazy-loading documentation also documents deferred loading, which starts after the initial page load, and class attributes such as #[Lazy] and #[Defer] for setting a component’s loading behavior by default.

For a full-page Livewire component, a route can enable lazy loading directly:

Route::get('/dashboard', Dashboard::class)->lazy();

Wire Elements’ explanation of Livewire lazy loading shows this route syntax. Check the documentation for your installed Livewire version before adopting version-specific syntax.

Show a placeholder while the component loads

Show readers when a delayed chart or card is loading. Livewire supports placeholder HTML through the @placeholder directive or a component’s placeholder() method. Without a placeholder, the lazy component appears as an empty <div> until its content arrives, then appears suddenly. The Livewire documentation describes both placeholder options.

Match the placeholder’s size and general shape to the content it replaces. For example, use a chart-shaped placeholder for a chart and a short text block for a summary card. This helps readers understand where the delayed content will appear while the component loads.

Account for requests and component inputs

Livewire sends a separate network request for each lazy or deferred component by default, and those requests run independently in parallel. If a dashboard contains many delayed components, their separate requests add work for the server. Livewire’s bundle parameter lets you group multiple lazy components into one request; consider it when several components load together and request count is a concern.

Also check what data you pass into a lazy component. Livewire serializes component props and re-queries them from the database before handling the next request. Complex props can behave differently after Livewire serializes them and restores them for the next request, so test the component with the actual inputs it receives. If you see unexpected results, inspect how the component reconstructs its data for the later request.

For Filament dashboards, the $isLazy property controls whether widgets wait to load until they are visible on the page. A widget that reads related database records still needs eager loading, which fetches those records ahead of time. The Filament guidance on scalable dashboard widgets warns that loading relationships on list pages can create N+1 queries, with an extra database query for each item. It recommends eager loading through with().

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com