Infinite scroll in a mobile app: where the feed breaks
Infinite scroll looks like a simple technique: the user reaches the bottom of the content feed — the app loads the next batch.
In practice, infinite scrolling breaks in four predictable places, and each of them is seen by the client as "the app lags" or "cards are duplicated."
The first failure is duplicate cards. Data loading is triggered by several events at once: scrolling, list refresh, returning from the background. Two requests go out in parallel, the responses arrive in a different order, and identical items appear in the feed.
This is not fixed with "foolproofing" but with a single source of truth: pages are numbered, responses are merged by identifier, and a repeated request is blocked until the previous one completes.
The second is loss of scroll position. The user opens a card, comes back — and the feed jumps to the top or to a random place. The reason is that the list is rebuilt from scratch, and the saved position is not tied to a specific item.
The right approach is to store an anchor: the identifier of the visible card and the offset within it, so that returning lands exactly where the user stopped.
The third is stuttering during fast scrolling. While data is loading, the feed shows emptiness or a loading hint, and the finger skips past cards that have not yet been rendered.
What works here is preloading off-screen and fixed-height skeleton placeholders: the list does not change its geometry, and scrolling stays smooth.
The fourth is memory leaks during a long session. An hour of scrolling — and thousands of rendered cards and stalled requests are hanging in memory. The solution is element reuse and canceling requests that are no longer needed.
Let's break down how this is handled in real development.
What a correct implementation of content loading provides
A correctly built infinite scroll is not "a feed that simply keeps scrolling," but a predictable loading system: the page is requested in advance, before the user reaches the edge, elements are not duplicated on repeated requests, and memory does not grow linearly with scroll depth.
The difference shows up in the metrics: app responsiveness stays steady hundreds of screens down, rather than degrading by the third or fourth hundred elements.
The first measurable effect is list stability. When element keys are unique and new pages are inserted without rebuilding what has already been rendered, duplicates and position "jumps" when returning to the screen disappear.
A user who minimizes the app in the middle of the feed and returns an hour later ends up exactly where they stopped — the share of drop-offs on return falls, because the screen is not reloaded from scratch.
The second effect is predictable memory consumption. The feed keeps in memory a window around the visible area, not all loaded elements: items that are done leave the tree, and the image cache is size-limited.
Over long sessions, this eliminates the growth in consumption and the forced app terminations by the system that come with it.
The third is steady app responsiveness during scrolling. Loading of the next page is triggered with a margin, in parallel with scroll inertia, rather than at the moment the bottom is hit; on a slow network a skeleton is shown instead of an empty screen.
Together, this delivers feed performance that does not depend on how long the user scrolls — and that is exactly what we build into the implementation.
Loading approaches: pages, cursor, viewport
There are three ways to serve data into a feed, and the choice between them determines how the application behaves on fast scrolling and with live content edits.
| Approach | When it fits | Limitations |
|---|---|---|
| Offset-based pagination | Static catalogs, infrequent inserts, simple lists | When records are added to the top of the feed, items are duplicated and "jump": page offsets are counted from the beginning, and it has already shifted |
| Cursor-based pagination | Live feeds, chats, marketplaces with frequent edits | Requires a stable sort key and cursor support on the service side; jumping to an arbitrary page is impossible |
| Viewport | A limited dataset that has already arrived in full | Memory grows with the volume, and fresh records are not pulled in without a re-request |
Offset-based pagination is the fastest start: the server returns a slice by page number, and the client simply increments the counter.
The problem shows up under load: while the user is scrolling, new records arrive at the top of the feed, and the next page returns what has already been seen. In the interface, this means duplicate cards and lost items — most noticeable in feeds with frequent publications.
Cursor-based pagination holds position by the last received item, not by its ordinal number. Inserts and deletions above the cursor do not shift the selection, so there are no duplicates even with active edits.
The price is server-side logic: a stable sort key is required, and jumping "straight to the middle" of the list becomes non-obvious.
The viewport works differently: data arrives as a single set, and only the visible part makes it onto the screen. This relieves the server, but shifts the load onto the device's memory — with large volumes, the application starts to lag.
Preloading the next portion 1-2 screens before the end of the list smooths out the wait, but does not remove the limitations of the chosen scheme.
Implementation stages: from feed audit to handover to the team
Implementing infinite scroll starts not with code, but with a feed audit: we look at how the application currently serves data, where pages are cached, and what requests are sent during fast scrolling.
At this step it becomes clear what exactly is slowing things down — the response size, the lack of pagination on the backend, or unnecessary list re-renders. Without an audit, any tuning turns into treating symptoms.
Sequence of work
- Feed audit. We analyze the current data flow: how many requests are sent per screen, how the application behaves when the network is lost, and what happens to memory during long scrolling. We record the bottlenecks in a report.
- Loading scheme. We design the contract: page size, cursor instead of offset, behavior with duplicate records, cache and retry strategy. The scheme is agreed upon with the backend — otherwise the client and server will start to diverge in their expectations.
- Configuration. We implement loading with a prefetch request 1-2 screens before the end of the list, a loading indicator, and protection against parallel identical requests. We separately cover the scenarios: empty response, network error, end of feed.
- Scroll testing. We run it on real scenarios — slow network, a sharp flick to the bottom, returning from the background, screen rotation. We check that the position is preserved and that memory does not grow indefinitely.
- Code handover. We hand over to the client's team the repository with the changes, a description of the loading contract, instructions for adjusting the page size, and a checklist of checks before release.
Each stage ends with an artifact: an audit report, a scheme, working code, test results, documentation. This allows your team to be brought in at any step and avoids dependence on a single contractor. Describe the task — we will come back with an estimate and a stage-by-stage plan.
Artifacts: configurations, state diagrams, guidelines
Feed development does not end with a working screen. To make the application evolvable, transferable to another team, and safe to change the loading behavior, we capture decisions in artifacts — from the data model to the maintenance guidelines. Below is what exactly remains in your hands after delivery.
- Feed configuration — a description of loading parameters: page size, load-more trigger threshold, behavior on an empty response and when data is exhausted. Can be changed without rewriting the screen.
- State diagram — a diagram of transitions between "loading", "data available", "empty", "error", "end of list" and the rules for returning from each state. It shows exactly where the feed can get "stuck".
- Caching rules — what is stored locally and for how long, how it is invalidated on refresh, how the application behaves without a network connection and when returning from the background.
- Data model — the structure of a list item, pagination keys, deduplication rules for repeated loading and merging pages.
- Documentation — a textual description of the loading logic, extension points, and typical change scenarios: a new filter, changing the source, adding a card type.
- Maintenance guidelines — what to check at release, which metrics to monitor (load-more error rate, time to first screen, scroll depth), how to roll back feed changes.
- Integration diagrams — how the feed is connected to analytics, search, and offline mode, so that new modules do not break pagination.
These artifacts remove the main maintenance risk: the loading logic stops being the knowledge of a single engineer. Describe your task — we will come back with an estimate and a plan, including the documentation scope for your process.
Case study: how the feed stopped duplicating cards
The client came with a classic complaint: users see the same cards in the feed, and when scrolling down quickly the list freezes for seconds.
Metrics confirmed the diagnosis: the share of duplicates reached 8% of impressions, the response to a fast swipe dropped to 400–600 ms, and memory during a long session grew linearly — the app reached 700 MB and the system started offloading the process in the background.
What was under the hood
The feed pulled pages by offset number, and the item key was the index in the array. As soon as the data on the server got reordered between requests, the same product arrived twice under different indices, and some positions disappeared. The cache kept all loaded pages in memory without eviction, so a long session turned into a leak.
What was changed
We switched to cursor-based pagination with an opaque token instead of a page number — the server returns "the next one after this one," and insertions in the middle no longer shift the window.
The item key became a stable record identifier rather than a position: a repeated arrival of the same entity now collapses at the storage level.
We added a retention window — we keep the current screen and a couple of screens in each direction in memory, the rest is evicted, and images load as you approach the boundary.
What the result was
The share of duplicates dropped to zero — repeat impressions are caught on entry. The response to fast scrolling was reduced to 80–120 ms, because loading happens in advance, a screen before the edge, and does not block the frame.
Memory during a long session stabilized around 180–220 MB and stopped growing over time: eviction works regardless of how much the user scrolls.
We also handled rollback separately: if the server returns a stale token, the feed does not break, but quietly re-requests the window from the last valid position.
The marketplace case showed the main thing — infinite scroll breaks not on the animation, but on the data model beneath it.
How cursor pagination differs from page-based pagination
Page-based pagination relies on an offset: the client requests "the first 20", then "the next 20" — the server counts records from the start of the result set. As long as the data is static, everything is predictable.
But a feed is alive: a new post arrives between requests, and everything below shifts down by one position. The next page no longer starts at the same record — the user sees a duplicate or loses an item that was never shown.
This is not a client bug, but a property of the offset itself: it is not tied to a specific record, only to its ordinal number at a given moment.
Cursor pagination passes a pointer to the last retrieved record instead of a page number — its unique key and the value of the sort field. The server returns everything that comes strictly after that point.
Inserting new records at the top does not affect such a result set: the cursor points to a specific element, not to a position. The user scrolls the feed without duplicates or gaps — this is what read consistency means.
The cost of queries also diverges. With an offset, the database counts and discards all preceding rows, so deep scrolling gets more expensive with every page: the hundredth batch reads thousands of records for nothing.
A cursor works by index and takes exactly the needed range — response time stays even at any depth of the feed.
The maintenance complexity is higher with a cursor, and that is a fair price. You need a stable sort key, a composite pointer for equal values, and separate logic for "back" and for jumping to an arbitrary position.
On the other hand, page-based pagination, cheap to implement, accumulates workarounds exactly where the feed updates frequently. For infinite scrolling, the choice is unambiguous: cursor.
Technical doubts: leaks, duplicates, returning to the screen
Infinite scroll almost always breaks not on the first screen, but on return: the user goes into a product card, comes back — and the feed jumps to the beginning.
The reason is that the list is recreated from scratch, while the loading state and scroll position live in the memory of the screen that the system unloaded when the app went to the background.
The fix is to keep the feed state separate from the screen itself: the offset, the loaded pages, and the "there is more data" flag go into a model that survives recreation, and on return we restore the position before rendering, not after.
Duplicate entries are the second most frequent complaint, and it is almost always a race between two requests. The user pulls the feed down, loading triggers, they pull again — two requests go out for the same page, and both responses get appended to the list.
This is closed with a lock for the duration of the active request plus deduplication by a stable record identifier rather than by array index: the index shifts on insertion, the identifier does not.
Why does the feed lose its position after the app is minimized?
The system unloads the screen from memory to free up resources, and on return it builds it again from scratch. If the scroll position and loaded pages were stored only in the screen itself, they are lost along with it.
The solution is to move this state into a layer that lives longer than the screen, and to restore the position before the first render of the list.
How do you limit memory during a long session?
Keeping the entire scrolled feed in memory is not an option — over a long session this leads to growing consumption and crashes. We limit the window: we keep the last N screens plus a buffer, unload the rest, and pull it back in when the user returns to the top. The user does not notice this, and memory consumption stops growing with the length of the session.
What should you do if the data on the server changed between loads?
A list assembled from different requests may contain stale records. We mark pages with their load time and refresh the visible window when returning to the screen, and remove deleted records by identifier. This way the feed stays consistent without a full reload.
We close these scenarios at the feed design stage, not after complaints to support — let's break down how this is set up in your app.
Let's discuss the task and come back with an estimate and a plan
To make a relevant proposal rather than a "price-list" one, we need to understand your current feed: how it works now, where it's already struggling, which scenarios are critical for you.
In the first conversation, we look at specifics, not abstract wishes — what's deployed, what's measured, what hurts.
After that, we come back with a work estimate and an implementation plan: what we do first, what can be postponed, where the risks are. Below is what's worth having on hand for the discussion.
- How loading currently works: pages, cursor, batch size — and what happens on a slow network.
- Which scenarios are critical: product feed, chat, social feed, search — each has its own loading requirements.
- What happens on failure: blank screen, duplicate cards, lost position on return — which of these symptoms you've already seen.
- Whether there's a cache and offline mode, how the app behaves when the connection drops.
- How quality is measured: first-batch speed, reload ratio, drop-offs on long scrolls.
- What you've already tried and why it didn't work — so we don't repeat what's been done.
- Constraints on timeline and release cycle: when you need the result and what can't be broken in the current version.
Describe the task in a nutshell — which app, which feed, what's bothering you. We'll come back with an estimate and a plan, no generic words.