Infinite-scroll restore depends on how much was loaded; returning too deep retriggers fetch

What it is

An infinite list has no page number. Place lives in “the window already fetched.” That window may hold hundreds of rows on leave; on return the component rebuilds from page one and the anchor id is not in memory. Restore depends on loaded volume: putting the person back on that row requires fetching again from the start to that row (or jumping the window by cursor). The deeper they went, the heavier that fetch, and they will see the top or a skeleton first and conclude restore failed. A virtual list that only paints DOM near the viewport has the same problem: it is the data window, not the node count.

Why it happens

A paged list’s “page 3” is a coordinate that can be requested again. An infinite list’s coordinate is a cursor or offset plus the items then in the window. After the window is torn down, remembering the id is not enough—the server may not offer “a page around any id,” only page-after-page from the newest end until that id is hit. Depth and backfill time are nearly linear; on a weak network that is tens of seconds. If the product hands over an interactive first page before backfill finishes, people start scrolling down, then get yanked to the anchor when backfill completes—a second interruption.

Virtualization adds unknown heights: unmeasured items occupy estimated height, total height jumps when backfill lands, and scrolling to the “estimated place” misses the real item. Deep restore therefore has three costs: fetching the window, measuring layout, and not exposing the wrong first screen before that is done. Without all three, scroll restoration on infinite lists only succeeds by accident at shallow depths.

Studying it

Have people scroll to different depths (one screen, ten, fifty), open a detail, return. Compare a cached window, a cursor fetch of the surrounding page, and replay from the top to the anchor.

• Independent variables: depth, whether the window from leave is kept, a throttled network.
• Dependent variables: time until the anchor is in the viewport, whether the top appears first, secondary jumps during backfill.
• Methodological note: lab Wi-Fi hides the cost of fifty screens. Throttle. Do not score only “eventually on that row”—a flash of the top then a jump is still a failure. Split cold start from in-session return; the window is certainly gone in the former.

Where it stops holding

A finite list with a “load more” button is not this leaf: the page number itself can be requested. Shallow depths whose window still sits inside page one have no reload problem. If the server offers something like around=id, cost unhooks from depth and the linear penalty in this leaf does not hold—though painting the top first is still forbidden. A manual pull-to-refresh is the user discarding the current window.

Applying it

• On leaving an infinite list, cache the data window and the anchor id. In-session return must reuse the window, not replay from page one.
• When the window is gone, use an around-id page API. If none exists, backfill in the background and hold the original viewport with a skeleton; do not hand over a scrollable first page.
• If depth cannot be fetched back in a short time, land on the nearest fetchable window and say “content needs to reload,” rather than pretending to still be on the original row.
• Verify: scroll at least ten screens, open a detail, return. The anchor should be in the viewport with no interactive top in between. Kill the process and walk it again: a skeleton is allowed, scrolling page one first is not. Throttle to 3G and repeat past ten screens; record secondary jumps.

Related

• Within the group: G4.07.1 When a list mutates while away, restore the item, not the pixel offset · G4.07.3 Unsubmitted input drafts should survive leaving by navigation, not be cleared · G4.07.4 When position restore fails, say why—deleted or reordered · G4.07.5 Cross-device resume stores position on the account, not in local state
• Adjacent: E5.07 Infinite scroll · G4.03 State persistence · I2.03 Chunked loading
• Search terms: infinite scroll · virtual list · scroll restoration