Partial reload scroll restoration behavior in Inertia.js v1.x

Short answer

No — Inertia.js v1.x does not automatically restore scroll position after a partial reload, and as of this writing there is no documented configuration option that turns such behavior on. The recommended pattern is to control scroll explicitly per request using preserveScroll plus the visit callbacks (onSuccess), centralized in a shared helper or an app-level listener.

Why partial reloads behave this way

Confirmed behavior: a partial reload (a request carrying the X-Inertia-Partial-Component header, triggered via router.reload({ only: [...] }) or a visit with only/except) re-renders the same component with only the requested props. Because no full navigation occurs, the browser simply keeps the current scroll offset — nothing is restored or reset.

The likely explanation (not officially confirmed by the maintainers in the sources available here) is that Inertia's built-in scroll restoration is tied to history navigation — popstate events from back/forward buttons — not to same-page data refreshes. Leaving scroll untouched during an incremental update avoids jarring viewport jumps, which is usually what you want for polling or infinite lists.

Where the inconsistency comes from

The confusing part is that defaults differ by method:

• router.reload() preserves scroll by default.
• router.get()/router.visit() reset scroll to the top unless you pass preserveScroll: true.

Mixing these across pages — some filters using router.get, some refreshes using router.reload — produces the uneven experience described in the question, and it is a per-call option, not a global default.

Recommended pattern

Pick the intent per interaction and be explicit:

// Filters/pagination: user expects to return to the top
router.get(url, { only: ['results'] }, {
  preserveScroll: false,
})

// Infinite list / background refresh: keep the viewport put
router.reload({ only: ['items'] }) // preserves by default

// Custom target: scroll a specific element into view after update
router.reload({
  only: ['comments'],
  onSuccess: () => {
    document.getElementById('comments')?.scrollIntoView()
  },
})

To avoid per-page boilerplate, wrap these calls in one shared helper (e.g. usePartialReload) or attach an app-level listener to the inertia:page-update event that applies your scroll policy. One caution: a manual scrollTo in onSuccess can race with deferred prop rendering — if the target element isn't laid out yet, defer the scroll with requestAnimationFrame or a short microtask.

Is a config option planned?

As of the knowledge cutoff for this answer, no such option exists in the v1.x API. Whether one is planned is an open project decision and should be verified against the current inertiajs/inertia repository discussions and changelog — do not rely on this answer for post-cutoff releases.

How to verify on your version

1. Check your installed version: npm list @inertiajs/core, then read its changelog for any scroll-related additions.
2. Scroll down a page, trigger router.reload({ only: [...] }), and confirm the offset is unchanged; repeat with preserveScroll: false.
3. In DevTools, confirm the request sends X-Inertia-Partial-Component and the response contains only the requested props.
4. Cross-check the current official docs sections on scroll management and partial reloads.

One detail that would change this recommendation: if your inconsistency appears specifically on back/forward navigation rather than partial reloads, that is history scroll restoration — a separate mechanism with its own settings — and the fix would be different.