Page Numbers, Load More, or Endless Scroll: Choosing List Browsing for Vibe Projects

List pagination is the most unremarkable and most easily broken part of a product. Users flip through lists every day: orders, articles, products, messages, files. Done right, nobody praises it. Done wrong, users feel it immediately: the item they were halfway through is gone, pressing back returns them to the top, the footer can never be reached, and the page gets slower the further they scroll. Worse, these problems rarely appear in a demo — they only surface with real data volumes and real usage paths.

This guide covers how to choose among four list-browsing patterns, the details each one demands, the data-layer traps, and how to verify before launch. All example products and people in this guide are fictional: the example product is "Qinghe Market" (a fictional second-hand marketplace app), and the example user is Xiao Chen (a fictional person).

First, define the job: what is the user doing in the list?

Before choosing a pattern, ask which task the user is performing in the list. Different tasks demand very different pagination.

The first task is "finding one specific thing": Xiao Chen wants the coffee machine bought last week. There is a clear target; paging is just a means, and faster locating is better. This task needs jumpable, searchable, locatable navigation: page numbers, jump-to-page, sorting, and filters.

The second is "browsing to see what is there": Xiao Chen idly scrolls nearby second-hand items on a weekend. There is no target; browsing itself is the point, and smoothness and immersion matter most. This suits infinite scroll — provided users never need to find something again.

The third is "working through a batch": Xiao Chen checks 30 pending-shipment orders one by one. This needs a stable, reviewable sense of position: which item is done, how many remain, whether the last one was processed. The paging method must make progress visible and returnable.

The fourth is "reading through in order": notifications by time, content by chapter. The order itself is information, and paging must not disturb the order or silently drop items.

In short: the task decides the pattern, not aesthetics. Name your list's task type first, then discuss pagination versus infinite scroll.

Four patterns, and what each suits

Classic pagination: a row of page numbers at the bottom — page 1, page 2, and so on. It suits "finding a specific thing" and "working through a batch". Its strength is the strongest sense of position: users know which page they are on and how many there are, can jump to a page directly, and can share a link to a page. Its weakness is interruption: every page turn breaks the flow, so browsing feels less smooth.

A "Load more" button: a button at the bottom of the list that appends a batch when clicked. It suits the middle ground: users who want to browse but also stop occasionally. It preserves user control — loading is actively triggered, so the page length never changes silently because of scrolling — while feeling smoother than classic pagination because no full-page refresh is needed. Its cost is one extra click, and the button copy must be honest: "Load more" and "Show all" promise completely different things.

Automatic infinite scroll: more items load when the user reaches the bottom. It suits pure browsing: feeds, image walls, short-video-style lists. Its strength is maximum immersion; its weaknesses cluster: no footer landing point (footer content is forever pushed past the next load), scroll position easily lost on back navigation, no sense of how much has been seen, and no easy way to share "the item I saw".

Virtual scrolling: only items near the viewport are rendered, with placeholders holding the height of the rest. It suits very long lists (thousands of items) where each item is expensive to render, such as admin data tables. It is not a "browsing pattern" but a performance technique, and it can pair with pagination or "Load more". Before deciding "do we need virtual scrolling", confirm the list is genuinely long enough to need it — for a few hundred items, ordinary rendering plus pagination is usually enough.

Decision table: match the scenario directly

Orders, bills, tickets, approval records: classic pagination. Users need to verify, revisit, and send a specific page to a colleague; page numbers and links are hard requirements.

Article lists, product browsing, image walls: it depends on the task. Search results with a clear target suit pagination or "Load more"; pure browsing feeds can use infinite scroll, but must also provide "back to top" and position restoration.

Notifications, activity feeds, message history: read-in-time-order scenarios should prefer "Load more" or pagination, so infinite scroll does not blur the "read up to here" boundary.

Large admin tables: pagination plus virtual scrolling combined, with adjustable page sizes (20 / 50 / 100), keeping sort and filter state intact.

Mobile deserves special attention: a phone screen shows only a few items at a time, so users page far more often than on desktop; page buttons must be large with wide spacing; infinite scroll on mobile more easily triggers accidental actions (trying to tap the footer triggers a load instead).

Classic pagination: the details checklist

How page numbers are shown: do not lay out pages 1 through 200. The common approach shows two pages on either side of the current page, keeps the first and last pages always visible, and uses ellipses in between. The current page must be recognizable at a glance (color, bold, or underline — at least one), and must not be clickable — a button that does nothing when clicked is the worst feedback.

Items per page: give users a choice, but pick a sensible default. Management lists default to 20 items, product lists to 20–40; offer 20 / 50 / 100 switching, and after switching, remember the choice and return to page 1 — staying on page 7 after changing the page size leaves the position wrong.

Jump to page: lists over 20 pages must offer a jump-to-page input ("Go to page __"), with input validation: below 1 or above the total page count should produce a clear message, not a silent jump to page 1.

URL and sharing: page number, sort order, and filter criteria belong in the URL. That way users can share "page 3, sorted by price ascending" as a link, and a refresh keeps them on the same page. Pagination that lives only in memory and is lost on refresh is the most common half-finished form.

Total and range hints: write "1,284 items total, showing 21–40" at the top of the list, not just "page 2". Users judge workload from the total and judge whether anything was missed from the range.

Empty and out-of-range pages: when deletions shrink the data below a full page, the page being viewed can become empty. The correct behavior is to fall back automatically to the last page with data and say so ("This page is empty now, returned to the last page"), rather than leaving users to guess at a blank page.

Infinite scroll's five traps, each one real

First, lost position on back navigation. Xiao Chen scrolls to item 80 in a feed, opens a product detail, presses back, and lands at the top — the position is gone. This is the most damaging trap. The fix is scroll restoration: restore by item ID rather than pixel value, restore the loaded batches first on back navigation, then scroll to the item; if restoration fails, at least offer a "return to where you were" entry instead of making users scroll again.

Second, an unreachable footer. Help centers, legal information, and sign-out links live in the footer, and infinite scroll keeps the footer forever "one more scroll away". The fix is to move critical entries out of the footer into the top navigation, sidebar, or account area; the footer should hold only content that is not needed frequently.

Third, unclear loading feedback. After scrolling to the bottom there is no indication, and users cannot tell whether more is loading or there is nothing more. The correct behavior distinguishes three states clearly: loading shows a skeleton or spinner; a failed load shows "Failed to load, tap to retry" while keeping loaded content; and when there genuinely is nothing more, say so explicitly ("You have reached the end") instead of leaving users scrolling into blank space.

Fourth, performance collapse. Infinite scroll easily grows thousands of DOM nodes: the further the page scrolls, the laggier it gets, and low-end phones give up first. Content more than a screen and a half away should be recycled or virtualized; images should lazy-load; scroll listeners should be throttled. The test is simple: scroll 200 items on a low-end phone, and frame rate and memory should not visibly degrade.

Fifth, accessibility and keyboard use. Infinite scroll that only works with a mouse wheel is hostile to keyboard users and screen reader users. It must be possible to load more without a mouse (a button or keyboard-reachable trigger), newly loaded content must be perceivable by screen readers, and focus must not be thrown back to the top of the page after a load.

The data layer: cursor versus offset — pick wrong and get ghosts

After the front-end pattern is set, the data layer poses one more choice: offset-based paging ("skip the first N, take M") or cursor-based paging ("take M after the last item of the previous page"). Offsets are simple and intuitive and suit mostly static data where jumping to a page matters; their flaw is drift when data changes — if someone lists a new product while Xiao Chen is on page 2, the first item of page 3 duplicates the last item of page 2.

A cursor anchors on the last item's unique sort key (for example, created time plus ID). When items are added or removed, cursor paging neither duplicates nor skips — it suits dynamic lists and infinite scroll. Its cost is that arbitrary jumping has no direct equivalent: "jump to page 37" has no natural operation in a cursor system.

So the pairing is fixed: classic pagination pairs with offsets, so jumping makes sense; infinite scroll and "Load more" pair with cursors, so stability is guaranteed. Mixing them is the most common trap: infinite scroll on offsets produces duplicate items the moment data changes, and users will conclude the product is buggy — when really the paging parameter was wrong.

One more rule that is easily missed: sorting must be stable. Sorting by "published time" alone is not enough — two records published in the same second will drift in order. The sort key needs a unique tiebreaker, such as "published time descending, ID descending". With unstable sorting, paging produces the same item on two pages, or an item that can never be reached.

The hybrid: "Load more" plus two reinforcements

If you cannot decide between pagination and infinite scroll, prefer a "Load more" button with two reinforcements: first, show progress under the button ("Loaded 60 of 1,284 items"); second, support position restoration, so opening a detail and coming back keeps the user at the same batch and item.

The combination is attack-and-defense in one: users who want to browse can keep clicking through; users who want to stop can stop at any time; the footer stays reachable (it sits right after the button); loading is user-triggered, so network jitter never silently changes the page. Many content and management products end up here — not because it is fashionable, but because it does not fail badly under any task type.

One anti-pattern to avoid: turning "Load more" into infinite scroll after it is clicked, or vice versa. The pattern should stay consistent within a session; switching mid-session destroys the user's judgment of "how long is this page".

Test matrix: run this table before launch

Data volume: 0 items, 1 item, exactly one page, exactly one page plus one item, and 1,000+ items — run the paging flow for each. "Exactly one page plus one item" is the boundary most likely to expose a spurious "next page" button.

Change: add one item, delete one item, and change a sort field mid-paging, checking for duplicates, skips, and blank pages.

Navigation: go from list to detail and back — is position restored? Refresh the page — are page number and filters still there? Send a page link to someone else — do they open the same page?

Network: page repeatedly on a weak connection; after a failed load, does retry preserve loaded content? Do rapid consecutive "next page" clicks cause concurrent requests to overwrite each other?

Devices: scroll 200 items on a low-end phone and check frame rate and memory; operate the whole flow by keyboard; walk the loading flow with a screen reader.

Launch checklist (ten items)

One: the task type is decided — find, browse, process a batch, or read in order — and written into the requirements. Two: the pattern matches the task, with the decision table as evidence. Three: page-number display rules are complete — current page distinguishable, ellipsis rules, jump validation. Four: items-per-page is adjustable and switching returns to page 1. Five: page, sort, and filters live in the URL — shareable and refresh-proof. Six: total and range hints are present (how many total, which range). Seven: empty and out-of-range pages fall back with a message. Eight: infinite scroll passes all five checks — position restoration, reachable footer, three loading states, performance, keyboard and screen reader support. Nine: paging parameters pair with the pattern — offsets for pagination, cursors for scrolling — with a unique sort tiebreaker. Ten: the five-dimensional test matrix has been run, with boundary cases (0 items, one page plus one item) recorded.

One last reminder: paging is not a visual problem, it is a trust problem. Users hand your list the trust that "the next page still holds what I need", and your paging method must never betray it — positions must not be lost, items must not repeat, totals must not lie. Keep those three, and no pattern choice will go badly wrong; break them, and the smoothest scroll only disappoints users faster.

Migrating from pagination to "Load more": a practical sequence

Many teams do not choose a pattern from scratch; they migrate from one to another. The most common migration is from classic pagination to "Load more", usually because mobile share has grown and users complain about page-turn interruptions. The riskiest parts of a migration are not front-end components but old links and old habits.

First, preserve URL semantics. Old paginated links (such as ?page=3) must not all break overnight: links already shared, pages indexed by search engines, and pages users bookmarked all point at those addresses. After migration, a link carrying a page parameter should still open and land at the start of the corresponding batch — not jump back to page 1 or return a 404. Failing this turns a migration into an outbound-link incident.

Second, roll out gradually, never all at once. Pilot with one list (for example, the article list) for two weeks, comparing three metrics: list-page bounce rate, detail-page entry rate, and paging complaints in user feedback. If two of the three get worse, roll back — a pattern migration is a behavioral experiment, not an aesthetic upgrade.

Third, clean up remnants of the "page N" concept. Support scripts, help documentation, and tutorials sent to users may all say "turn to page 3". When the pattern changes, those texts must change with it, or users following old instructions will conclude the product is broken. The migration checklist needs an item specifically for checking help text inside and outside the product.

Fourth, keep monitoring on. In the first week after migration, watch three numbers daily: load failure rate, average batches loaded, and items viewed per session. A rising failure rate means the new pattern is more sensitive to weak networks; a surging average batch count may mean users are loading unintentionally (for example, by accidental taps); more items viewed but a falling detail-entry rate means users are "scrolling" rather than "looking" — immersion up, purpose down.

Two details easily missed: accessibility and multiple languages

On accessibility, beyond keyboard and screen reader support, check focus management: after tapping "Next page", focus should land at the start of the new content region, not stay put or return to the top; after "Load more" appends content, screen readers should announce a state change such as "Loaded 20 more items, 100 total" rather than silently changing the page. For color, the current page must not be distinguished by color alone — users with color vision deficiency also need bold, underline, or a text marker.

On multiple languages, page-count and quantity copy must leave room for plurals and word order. The Chinese "共 1,284 条" becomes "1,284 items" in English, and in some languages the number-noun order and plural forms differ; range expressions like "items 21–40" must also go through localized strings rather than being hard-coded from a Chinese template. Extract list-component copy into translatable keys from the start, so adding a language later does not require rework.