Long list / pagination

The user scrolls through a 200-item list, or clicks "Next" on a paginated table. The naive answer is to wait for the next page's data, then drop it in. The tuned answer is to render skeleton rows for the next page immediately and to predictively preload before the user reaches the boundary — most of the time, the data is already there when the skeleton renders.

This scenario sits in the 100 MS – 1 S band. Miller 1968's Miller 1968 simple-inquiry tier is roughly the latency budget for a paginated query. James 1890's James 1890 filled-duration principle frames why the skeleton rows fill the wait. Fitch's Fitch predictive-preloading framing is what shrinks the wait further by starting the fetch before the user signals.

What is happening in the demo

The demo is the same list-fetch you saw in page-load-cold, framed differently. Imagine the wait you are watching is the next-page fetch, triggered when the user approached the bottom of the visible list. The naive side waits silently; the tuned side renders five skeleton rows that match the final-row dimensions exactly, so the visual transition when data arrives is a swap, not a jump.

The skeleton rows are honest — they reflect the layout the data will take. A different number of rows, or rows of different heights, would create a layout shift the user sees. Layout-matching is the only configuration that earns the perception gain.

The full implementation also includes the predictive preloading on scroll trick: as the user scrolls into the last 30 % of the visible list, kick off the next-page fetch in the background. By the time the user reaches the boundary, the data is often already there — the skeleton appears and disappears in the same frame, or never appears at all.

What to tune

1. Scroll signal — as the user scrolls into the last 30 % of the visible list, fire the next-page fetch in the background. Predictive preloading on a high-confidence intent.
2. Click on "Next" — pre-action button echo within ~50 ms; the page change should not wait for the data.
3. First 500 ms — layout-matching skeleton rows replace the previous page's content. Same row count, same column widths.
4. Hit case — prefetched data lands before the user reads past the skeleton. The skeleton may never appear at all.
5. Repeat visits — stale-while-revalidate. Cached page lands instantly; background refresh is invisible.

When perceived performance hurts you here

Predictive preloading on scroll has the same trap as the broader predictive-preloading-on-hover pattern: false positives. A user who scrolls down and then back up costs you a wasted page fetch. With infinite scroll the cost is small (the next page would have loaded eventually); with paginated rows that the user might never visit, the cost is wasted bandwidth.

Tune the trigger threshold against your real user behaviour. 70 % is a starting point. If your false-positive rate is high, push to 80 % or 85 %; if your hit rate is high, drop to 60 % to extend the head-start.

The other failure: shipping skeleton rows that do not match the final row. A skeleton with three lines per row when the data has two creates a layout shift on swap. CLS spikes; the perceived gain reverses.

Accessibility

1. aria-busy="true" on the next-page skeleton container.
2. aria-label="Loading more items" describing what is loading.
3. Live region announcement when a substantial batch of new items appears, so screen-reader users on long lists know the count changed.
4. Keyboard navigation: arrow keys / page-down should reach new content as it becomes available, not get stuck at the previous boundary.
5. Don't hijack scroll position. When new content appears at the bottom, the user's scroll position must not jump.

References