Infinite scroll

The user keeps scrolling. The list keeps growing. The naive answer is to wait for the bottom of the visible content, then fetch the next batch. The tuned answer is to anticipate — fetch before the user reaches the boundary, render skeleton rows for the next batch immediately, and keep the layout stable as the new content lands.

This scenario sits in the 100 MS – 1 S band most of the time. The trigger is what changes from long-list-pagination — instead of an explicit "Next" click, scroll position is the signal.

What is happening

Same list-fetch demo, framed for the scroll case. Naive: fetch fires when the user hits the bottom; the user sees an empty gap until the data arrives. Tuned: an intersection observer ~70 % down the visible viewport triggers the prefetch; skeleton rows render immediately; the data swap is invisible most of the time.

Fitch's Fitch predictive-preloading framing applies: the scroll signal is high-confidence intent. The user is going to keep going; you can begin the next batch's fetch with a low false-positive rate.

What to tune

1. Scroll signal — intersection observer at ~70 % of viewport fires the next-batch fetch. Predictive preloading on a high-confidence intent.
2. In-flight — layout-matching skeleton rows for the incoming batch. The user reaches the boundary and the skeleton is already there.
3. Hit case — data arrives before the user reads past the skeleton. Swap is invisible most of the time.
4. Miss case — skeleton holds the layout until the data lands. No spinner, no scroll jump.
5. Backwards scroll — cached batches via stale-while-revalidate; previously-loaded sections are instant.

When perceived performance hurts you here

Infinite scroll itself is contested as a UX pattern — it disrupts back-button behaviour, makes the footer unreachable, and inflates session weight. The perception layer cannot fix those problems; it can only sharpen the loading affordance within the pattern.

Accessibility

1. aria-busy on the list during the next-batch fetch.
2. Live region announcement every N batches, not every batch — too many announcements is noise.
3. Keyboard navigation must reach new content as it lands.
4. Don't hijack scroll position when the new content appears.

References