Pagination vs Infinite Scroll vs Load More

List navigation determines how people explore a collection, find their place, and return to something they already saw. Pagination, infinite scroll, and load more are not interchangeable visual treatments. Each changes the relationship between effort, continuity, and control. Choose the pattern before designing the decorative details of the cards inside it.

Match the pattern to the browsing task

Start by describing the primary task in one sentence. “Find a specific invoice” suggests bounded navigation and recoverable position. “Browse visual inspiration until something looks interesting” suggests continuity. “Compare several products, then open a shortlist” requires both exploration and reliable return behavior.

Use the CSS grid generator to prototype the repeated list region at several column counts. Try realistic titles and image shapes before selecting a batch size. Twelve items form four rows in a three-column grid but twelve rows on a narrow screen, so an identical item count creates very different browsing effort.

Write down the expected collection size, whether totals are reliable, and whether people need to share their position. These are navigation requirements, not backend implementation details. The dashboard layout guide can help when the collection shares space with filters or a persistent sidebar.

Do not choose infinite scroll simply because the interface looks modern. A useful decision is one you can explain in terms of finding, comparing, browsing, or resuming, rather than aesthetic preference.

Use pagination for bounded, repeatable navigation

Pagination divides a collection into explicit destinations. It works well for administrative records, reference catalogs, and search tasks where people value a sense of progress. A visible “Page 3” is also an understandable return point, although changing data can still shift which records appear there.

Keep previous and next controls in stable positions. Show the current page distinctly, and use ellipses to shorten long ranges without disguising them as interactive destinations. On small screens, a compact “Previous / Page 3 / Next” treatment can be clearer than squeezing ten tiny numbered targets into one row.

Use links when controls navigate to addressable pages. Put them inside a labeled navigation region, and identify the current destination with the appropriate current-page state. The MDN aria-current reference explains this attribute without requiring a custom widget.

Do not invent precision. If the total is unknown, previous and next navigation can still work without claiming “Page 3 of 500.” If filters change, reset to a valid position and make the updated result context clear. Avoid leaving users on an apparently empty page because the new collection has fewer pages.

Pagination is less fluid for exploratory browsing, but that cost may be worthwhile. It creates stopping points, keeps the rendered list bounded, and makes a footer predictably reachable.

Use load more when people should control expansion

A load more control appends another batch after an explicit request. It suits galleries, product discovery, and medium-sized collections where continuity matters but automatic expansion would feel pushy. Existing items stay in place, supporting comparison across batches.

Label the action precisely. “Show 24 more products” is useful when the next batch size is known; otherwise, “Load more products” avoids a false promise. A supporting count such as “Showing 48 of 136” gives progress only when the total is dependable. Do not present an estimate as an exact inventory count.

Keep the control in a predictable place below the list. During loading, preserve its footprint and show a loading label. On failure, leave existing items untouched and offer retry in the same region. After the last batch, replace the control with a clear end message rather than letting it silently disappear.

Plan focus continuity explicitly. Appended items often enter the document before the load-more button, so ordinary forward tabbing may skip them if focus stays on the button. Depending on the list, move focus to a suitable heading or first new item after activation, or provide a clear route into the new batch. Test the chosen behavior rather than assuming appending is sufficient.

Reserve infinite scroll for continuous discovery

Infinite scroll loads more as the reader approaches the end of the current content. It can support image discovery and feeds where the next item matters more than a particular page. It also removes a natural stopping decision and makes position harder to communicate.

Keep essential footer content reachable elsewhere or provide an explicit way to stop automatic loading. A footer that repeatedly escapes just as someone approaches it is a broken layout promise. Avoid automatic expansion in workflows that depend on completing a finite set or finding a known record.

Place loading feedback near the boundary and show recoverable errors there. Distinguish “loading,” “unable to load,” and “you have reached the end.” Do not allow a failed request to trigger an endless observer loop. The MDN Intersection Observer guide explains a common detection mechanism, but detecting visibility does not solve the interaction design.

If you adopt a specialized feed interaction, review the WAI feed pattern. Do not add feed roles to an ordinary card grid just because it loads continuously; that pattern has its own structural and keyboard expectations.

For some screens, a hybrid works best: automatically load one or two additional batches, then offer load more. Make the switch deliberate and consistent, not an undocumented side effect of network conditions.

Design return behavior and loading states together

The strongest pattern can still fail if opening an item and pressing Back returns people to the top. Treat return position as a first-class specification. Preserve the query, sort order, filters, expanded batches, and a useful position anchor when navigating away and back.

For pagination, encode the meaningful navigation state in the URL. For appended lists, restoring the scroll offset alone is insufficient if earlier batches have not been restored. Store enough state to reconstruct the region or provide a stable item anchor. Explain the intended behavior to developers without assuming browser restoration will cover every application route.

Specify these visible outcomes before implementation:

const listFeedback = {
initial: "Loading products…",
appending: "Loading more products…",
failedAppend: "Couldn't load more. Try again.",
complete: "You've reached the end of the products."
};

Use the asynchronous UI states guide to keep empty, loading, and error treatments distinct. Place polite status feedback where it will announce meaningful changes without reading the entire list repeatedly.

Test each pattern through the same task checklist: open the twentieth item and return, change filters midway, retry a failed append, reach the end with a keyboard, and access the footer on mobile. Include a long title and variable-height media. The winning interface is the one that preserves orientation through these transitions, not the one with the smoothest demonstration scroll.

Key takeaways

• Choose pagination for bounded navigation and explicit return points.
• Choose load more when browsing should remain user-controlled.
• Use infinite scroll only when continuous discovery justifies its costs.
• Preserve list context when people open an item and return.
• Design loading, failure, completion, and focus behavior before shipping.