Infinite Scroll

You’re looking for hiking boots. You scroll through 80 products, spot a nice pair, tap it, read the details and press Back. You’re at the top of the list again, with 12 products. The other 68 are gone, and so is your place. You try to find the Returns policy in the footer instead, but every time you get close, twelve more products push it away. You close the tab.

infinite scrollInfinite scrollLoading more items automatically when the user reaches the bottom of a list.Open in glossary → feels effortless when it works. Underneath, it’s a little machine: something watches the end of the list, requests the next page, appends it, and has to handle slow networks, errors, the end of the data, the Back button and people who don’t use a mouse. Every part of that machine has its own bugs.

What is infinite scroll?

Infinite scroll loads the next batch of items automatically when the user nears the bottom of a list. There’s no “Next” button: scrolling is the action. You know it from social feeds, photo streams, news apps, shop categories and search results in many apps.

It’s still pagination underneath. The app asks the server for a page of items (say 20), shows them, and asks for the next page when it’s needed. The difference is only who decides when: the scroll position, not a tap.

Anatomy

How it works

The page size matters too: 10–30 items is typical. Tiny pages mean many requests and frequent waits; huge pages mean slow responses and lots of memory on cheap phones.

How it differs from similar patterns

Designs & variants

• Endless feed (list): one column of posts or articles, newest first. Social apps, news.
• Product or photo grid: two to four columns. Each page fills whole rows, or the last row looks broken.
• Reverse list (chat): older messages load at the top when you scroll up, and the list must keep your place while they’re inserted above you.
• Hybrid “load more”: the first two or three pages load on scroll, then a Load more button appears. It keeps the footer reachable and gives keyboard users a stop.
• With helpers: a “Back to top” button after a long scroll, a “New posts” pill when fresh items wait above, or a result count (“312 results”).

Try it: scroll lab

A correct infinite scroll on a recipes feed. The red dashed line is the sentinel, the blue one shows where loading starts. Play with the settings and watch the counters and the network log:

• Scroll to the bottom with prefetch 0 px (you wait for the spinner), then with 1 screen (you rarely see it).
• Switch the network to Fails, scroll down, then back to Fast and tap Retry. Nothing loads on its own after an error until you retry.
• Use 45 recipes to reach the end and the footer. Use 1,000, load a few pages and turn on Virtualize: the rows in the DOM drop to a handful.
• Open a recipe far down the list and go Back. Try Load more button mode with the keyboard.

When to use it

Infinite scroll fits when people browse without a specific goal:

• Feeds and streams: social posts, news, photos, short videos, activity.
• Discovery lists: “Inspiration”, “For you”, a category people scroll through for fun.
• Mobile lists where tapping a tiny “Next” would be awkward, and nothing important lives below the list.

Good and bad uses

How good infinite scroll behaves

One request per page, no duplicates or gaps

Only one request may run at a time. The classic bug: the trigger fires, the user keeps scrolling while the page loads, the trigger fires again (a throttle or debounce doesn’t help if the request is slower than it), and the same cursor is requested twice. The page then shows the same items twice. Good apps keep an “already loading” flag and also merge results by item ID.

Data also changes while people scroll: new posts arrive, items sell out. With offset paging (“skip 40”) that causes duplicates and skipped items; cursor paging avoids most of it. The Pagination page has a live demo of both. Test it by adding or deleting items (with a second device or an admin tool) while you’re halfway down the list.

A small loading row, not a full-screen spinner

While the next page loads, a short row with a spinner at the bottom (“Loading more…”) is enough. The items already on screen stay usable. With a good prefetch distance, people on a normal connection rarely see it at all. See Progress & spinners for indicator timing.

Errors stay inline, with Retry

If a page fails, the loaded items stay, and an error row appears at the bottom: “Couldn’t load more. Retry”. Two common bugs are opposites of each other:

• Silent dead end: the spinner disappears, nothing more ever loads, and nothing says why. Users think they’ve reached the end.
• Retry storm: the app retries automatically on every scroll event and floods the server (and the battery). Automatic retries need limits and a growing delay (retry with backoffRetry with backoffAutomatically trying a failed request again, waiting longer between each attempt.Open in glossary →).

The end is an end

When the server says there are no more items, the spinner stops and a message says so: “You’ve seen all 45 recipes” or “You’re all caught up”. Without it, users keep scrolling and waiting. Test the end with a short list too: a filter or a category with only 7 items is the fastest way to reach it.

Back returns to the same place

After opening an item and going Back, the list must look exactly as before: the same loaded items, the same scroll position, the same filters. On iOS and Android this usually works when the list stays in memory, and breaks after the OS kills the app in the background (state restorationState restorationBringing the user back to the same screen and data after the OS closed the app in the background.Open in glossary →), on rotation or when the app reloads the list “to be safe”. On the web, the browser restores the position for normal page loads, but a single-page app that rebuilds the list from page 1 has to store the loaded pages and position itself.

Deep links and refresh

Infinite lists are hard to link to. Good web apps write the position into the URL (?page=4 or ?after=r80) or an anchor for the item, so Refresh, Back and shared links land near the same spot instead of the top. In apps, a deep linkDeep linkA link that opens a specific screen inside an app instead of just its home screen.Open in glossary → to an item opens the item, and Back goes somewhere sensible, not an empty list.

The footer stays reachable

If a footer is below the list, people can’t reach it: each time they get close, more items load. Fixes: switch to Load more after a few pages, put the footer links in a menu, or stop auto-loading at a fixed limit. As a tester, try to click every footer link on a page with infinite scroll.

Thousands of items stay fast

A list that has loaded 2,000 items can get slow, janky and memory-hungry, especially on older phones. Native lists only create views for visible rows. On the web, apps use virtualization: only the rows near the viewport exist in the page, the rest are empty space. It’s a performance fix with side effects: the browser’s Find in page can’t find rows that aren’t rendered, and screen readers may not see the whole list. Test long sessions: scroll for a few minutes, then check speed, memory and that scrolling back up still shows the right items.

Common bugs

Find the bug

This outdoor shop loads products as you scroll, and it has six bugs. Each request takes about 1.3 seconds. Explore it like a tester:

• Scroll down quickly and keep scrolling while “Loading more…” is shown. Then look closely at the products and the network log.
• Scroll a long way, open a product, then press Back to products.
• Open the Sale category and scroll to the bottom. Wait.
• Turn on server errors, scroll down, then turn them off again and keep scrolling.
• Try to open Contact or Imprint in the footer of All products.
• Click All products, then use only the Tab key to move through the products.

How to test it

Checklist

Example test cases

Tools

• Network log: DevTools › Network on the web, a proxy tool like Charles or Proxyman for apps. Filter by the list’s API path and compare the cursor or page parameter of every request. Two identical requests are proof of the duplicate bug.
• Throttle: network throttlingNetwork throttlingDeliberately slowing the connection to test how an app behaves on poor networks.Open in glossary → (“3G” in Chrome DevTools, Network Link Conditioner on iOS, emulator settings on Android) makes loading rows, double requests and race conditions visible.
• Break a single page: use a proxy rule or proxy breakpointProxy breakpointPausing a request or response in a proxy tool so you can edit it before it continues.Open in glossary → to fail only the second or third page request, then check the error row and Retry.
• Force the end: filter or search for something with very few results, or use a test account with little data.
• State restoration: on Android, Developer options › Don’t keep activities; on iOS, put the app in the background and stop it from Xcode, then reopen. Rotate mid-scroll.
• Performance: scroll for several minutes. Watch memory in Xcode’s Debug navigator, Android Studio’s Profiler or DevTools’ Performance monitor.

Accessibility

Infinite scroll is one of the hardest patterns to make accessible. Check these:

• Keyboard focus stays put. When items are appended, focus must stay on the item the user was on. Re-rendering the whole list or moving focus to the top sends keyboardKeyboard navigationUsing a website with only the keyboard: Tab to move, Enter or Space to activate, Esc to close.Open in glossary → users back to the start (WCAG 2.4.3 Focus Order, A). See also focus orderFocus orderThe order in which the Tab key moves through interactive elements.Open in glossary →.
• Offer “Load more”. A visible button lets keyboard, switch and screen reader users decide when to load, and lets them reach what’s below the list. Many sites load the first pages automatically, then show the button.
• Announce new items. A polite live region (“12 more products loaded”) tells screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → users something changed without moving focus (WCAG 4.1.3 Status Messages, AA). Announce the end and errors too.
• Give it structure. A feed or a plain list with a heading and a result count.
  Dev note

  On the web, the ARIA feed pattern fits: role="feed" on the container, each item an article with aria-posinset and aria-setsize (-1 if the total is unknown), and aria-busy="true" on the feed while it loads. A plain list (ul/li) with a heading and a result count also works.
• The footer and skip links. Keyboard users must reach everything after the list. A “Skip to footer” link or footer links in the header avoid an endless Tab journey.
• VoiceOver and TalkBack swipe through items one by one. Check that new items are reached naturally when swiping past the last one, and that the loading row and errors are read out.
• Virtualized lists can confuse screen readers (“item 5 of 12” when there are 400). Check positions and counts are announced correctly.
• Touch targets for Retry and Load more: at least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px; 44×44 px (2.5.5, AAA) is the comfortable target.

Mobile vs web

Check your understanding