Reduce Payload Size with Inertia.js Partial Reloads and Lazy Props

The problem: full visits resend every prop

In a typical Inertia.js page, the server renders props once and the client receives them as JSON. When a user interacts with the page—say, toggling a filter or incrementing a counter—a full inertia.visit usually asks the server to rebuild the entire page and resend every prop, even the ones that did not change. On pages with large datasets, nested relationships, or expensive report queries, that repeated payload slows the network and the browser.

Partial reloads request only the keys you need

Inertia.js supports partial reloads through the only option on Inertia.reload or inertia.visit. Instead of asking for the whole prop set, the client tells the server which prop keys it wants. The server responds with a JSON object containing only those keys, and Inertia merges them into the existing page state.

Lazy props make the saving real

The only filter reduces what travels over the network, but it does not automatically reduce server work. Standard props are evaluated on every request, so an expensive database query inside a standard prop still runs even if the client did not ask for it. To avoid that, wrap expensive data in a closure. Inertia treats that closure as a lazy prop and executes it only when the prop key appears in the only list.

This behavior depends on the server adapter. The Laravel adapter supports lazy props through closure-based prop values. Other adapters may handle them differently, so check your adapter's documentation before relying on deferred execution.

Worked example: refresh a single counter without reloading the page

Imagine a Laravel-backed Inertia page that displays a notification count alongside a large activity feed. The feed rarely changes, but the count updates when the user marks items as read. You want to update the count without resending the feed.

In the controller, define the feed as a standard prop and the count as a lazy prop:

use App\Models\Notification;
use Inertia\Inertia;

public function show()
{
    return Inertia::render('Dashboard/Show', [
        'feed' => ActivityFeed::latest()->paginate(50),
        'unreadCount' => function () {
            return Notification::where('user_id', auth()->id())
                ->where('read_at', null)
                ->count();
        },
    ]);
}

When the user marks a notification as read, call a partial reload from the frontend:

import { Inertia } from '@inertiajs/vue3';

async function markAsRead(notificationId) {
    await axios.post(`/notifications/${notificationId}/read`);

    await Inertia.reload({
        only: ['unreadCount'],
        preserveState: true,
        preserveScroll: true,
    });
}

Place the controller code in the relevant Laravel controller method, typically under app/Http/Controllers. Place the frontend code in the Vue component that handles the interaction. No special filesystem permissions are required beyond normal write access to those files. The expected result is a smaller JSON response containing only unreadCount. A risk is that if unreadCount is defined as a standard value instead of a closure, the server still evaluates it on every request regardless of the only list.

Verify the behavior in the browser

1. Open the page in a browser with developer tools open.
2. Go to the Network tab and filter for XHR or Fetch requests.
3. Trigger the action that calls Inertia.reload with only.
4. Select the Inertia request and inspect the response JSON. It should contain only the keys listed in only, plus Inertia metadata such as the component name and URL.
5. Open the server logs or add a temporary log statement inside the lazy closure. Confirm the closure runs only when its key is requested and not during unrelated partial reloads.

If the response contains every prop, or if the slow query runs regardless of the only list, the prop is likely defined as a standard value rather than a closure, or the adapter does not support lazy evaluation for that prop type.

Trade-offs and limitations

• Standard props are always sent. Partial reloads filter the response, but they do not skip the evaluation of non-lazy props.
• Client state can become fragmented. If a component expects data that was not included in a partial reload, it may render stale or missing values until a full visit refreshes the page.
• Adapter support varies. Lazy prop behavior is not guaranteed across every Inertia server adapter, and the syntax for defining closures differs by framework.
• Debugging is harder. Because the server response changes based on the only list, reproducing an issue may require knowing exactly which keys were requested.

Use partial reloads for targeted updates, not full-page replacements

Partial reloads are most useful when a page mixes stable, expensive data with small, frequently changing values. Keep the full page visit for navigation and major layout changes, and use only with lazy props for incremental updates. Verify with the Network tab before assuming the payload is smaller, and confirm lazy closures are not firing unnecessarily in server logs.