Using Inertia.js Partial Reloads to Cut Payload Size

When a user changes a date filter in an Inertia-driven dashboard, the entire page reloads, sending back every prop the server knows about—even though only the chart data changed. That payload bloat slows the transition and can jank the UI.

How partial reloads work

Inertia.js lets a client request a subset of page props by passing only (or except) to router.reload() or router.visit(). The server response then contains only the requested keys instead of the full page object.

• only: includes just the listed props
• except: includes every prop except the listed ones

Server-side adapter responsibility

The server-side adapter must honor the partial request by evaluating only the requested props. If the adapter ignores the contract and computes everything, the optimization saves bandwidth but not database queries or CPU time.

Worked example: filtering a chart

Imagine a dashboard with a date-range filter and a chart that displays stats. After the user selects a new range, the component calls:

router.reload({ only: ['stats'] })

Inertia sends a partial request. If the adapter resolves only the stats prop, the response JSON contains just { stats: ... } and the Inertia-Partial-Data header flags the response. The page component merges these props into its existing state, so the chart updates without re-rendering the whole page or losing open modals and form inputs.

Trade-offs and limitations

• Silent merge failures: If the client and server prop names mismatch, the merge produces undefined without an explicit error.
• Stale data risk: Unrequested props are not refreshed, so filters or pagination can show outdated values until a full visit occurs.
• Adapter compute cost: A prop cheap to serialize may still be expensive to compute if the adapter does not defer evaluation.

Verifying the behavior

Open your browsers devtools, trigger a filtered reload, and check the network tab:

• The response body should contain only the requested prop keys.
• A header named Inertia-Partial-Data (or equivalent per adapter) should be present.
• Compare the response size against a full page load to confirm the reduction.

You can also add a temporary query counter or server-side log around prop resolution to verify that omitted props are not evaluated when a partial request is received.

This approach works well when you need to update a specific data segment while preserving local UI state, but it requires disciplined prop tracking and server adapter cooperation.