Reducing Payload Bloat with Inertia.js Partial Reloads

The Over-fetching Problem in Monolithic SPAs

When building an application with Inertia.js, it is easy to fall into the habit of passing every piece of required data in the controller's render method. While this works for simple pages, it creates a performance bottleneck as the application grows. If a page has a heavy data table, a complex sidebar, and a user profile section, every single navigation or state update triggers a full server-side refresh of all those datasets.

This results in "over-fetching," where the server spends CPU cycles calculating data the user isn't currently looking at, and the browser spends time downloading a JSON payload larger than necessary. The solution is Partial Reloads: a mechanism to request only specific keys of the data object from the server.

How Partial Reloads Work

Partial reloads allow the client to signal to the server exactly which props are needed for the current interaction. Instead of the server sending the entire state, it filters the response to include only the requested keys.

To make this effective, you must distinguish between eager data (required for the first page load) and lazy data (expensive data that can be loaded on demand). In a Laravel environment, this is achieved using closures. When you wrap a data key in a closure, Inertia will only execute that code if the key is explicitly requested in a partial reload or if it is the initial page visit.

Practical Implementation: Lazy Loading a Heavy Report

Consider a dashboard where the main page loads quickly, but a "Detailed Analytics" table takes several seconds to query. You don't want to delay the initial page render for this table.

Server-Side Configuration (Laravel)

Run this logic within your controller. Note the use of a closure for the analytics key.

public function index()
{
    return Inertia::render('Dashboard', [
        // Eagerly loaded: always sent on first visit
        'user' => Auth::user(),
        'notifications' => Notification::latest()->take(5)->get(),
        
        // Lazy loaded: only sent on first visit or explicit partial reload
        'analytics' => Inertia::lazy(fn () => 
            AnalyticsService::getHeavyReport()
        ),
    ]);
}

Client-Side Request (Vue.js)

Use the only property within the router.reload method to fetch the analytics data without refreshing the rest of the page state.

import { router } from '@inertiajs/vue3'

const loadAnalytics = () => {
    router.reload({
        only: ['analytics'],
        onSuccess: () => console.log('Analytics loaded!'),
    });
}

Verification and Diagnostics

To verify that partial reloads are working and not just triggering a full refresh, follow these steps:

1. Open your browser's Network Tab.
2. Trigger the loadAnalytics function.
3. Inspect the XHR/Fetch request. The response should be a JSON object containing only the analytics key and the component metadata, omitting the user and notifications data.
4. Check your server logs. The AnalyticsService::getHeavyReport() method should not appear in the logs during the initial page load, only during the partial reload request.

Trade-offs and Limitations

Partial reloads are powerful, but they introduce a risk of undefined props. If your frontend component expects analytics to be an array to map over, but you haven't loaded it yet, the application will crash with a TypeError.

Mitigation Strategy: Always provide a default value in your component props or use optional chaining (e.g., analytics?.data) to handle the period before the partial reload completes.

Additionally, partial reloads do not automatically handle dependent data. If updating prop A requires a change in prop B, you must include both in the only array: only: ['propA', 'propB'].

Actionable Summary

To optimize your Inertia.js application, audit your controllers for expensive queries. Wrap those queries in Inertia::lazy() and move the trigger to the client side using router.reload({ only: [...] }). This reduces server load and improves the perceived speed of your UI by eliminating unnecessary data transfer.