A long list should load before you get to the bottom, not when you arrive
Our product list stopped at 100 of 131 items, and the fix taught us two things about loading long lists that are easy to get almost right — and one of them looked correct in every test we had.
A kitchen with a hundred and thirty products has a scroll problem. Render them all and the screen takes a moment to appear. Show fifty and make people ask for more, and they spend the evening clicking.
The answer everybody lands on is to fetch the next batch as somebody scrolls. It is easy to describe and surprisingly easy to get almost right.
The first thing we got wrong: "ahead" that was not ahead
The list watches for a marker near the end and fetches when it comes into view. We put the marker 500 pixels below the last row, which sounds like a comfortable margin, and it is not. On a laptop, 500 pixels is a third of a screen. By the time the marker came into view the reader was at the bottom, and they watched a loading line for a beat before more rows appeared.
That is the exact experience loading ahead exists to prevent. It is now a screen and a half — the next batch is fetched while you are still reading the middle of the current one, and the list simply never ends.
The second thing, which no test caught
The list stopped at 100 items out of 131. Every automated check passed.
The mechanism only fires when the marker crosses into view. If a batch lands and the marker is still inside the margin — a tall window, a short final batch, a reader already at the end — it never crosses again, and nothing asks for the rest. The list sits there, one batch short, looking finished.
It now tops itself up until the marker is genuinely out of reach. Reading the code, this is invisible. In a browser it is thirty-one missing products.
Two smaller things worth copying
Append, do not redraw. When the next batch arrives it is added to the end. Redrawing the whole table would reset the scroll position and throw the reader back to the top, which is worse than the problem being solved.
Say how many there are. A list that grows as you scroll gives no sense of scale, so there is a line above it: Showing 50 of 131 products while more is coming, and 131 products when it is all there. It also tells you when a filter is hiding something, which a search box otherwise never does.
Checking it on your own system
Scroll a long list at speed. If you ever see a loading line, the fetch is starting too late. Then scroll to the very end and count against the total — if your system does not show a total, that is its own answer.