Design an Infinite Feed

An infinite feed is three problems wearing one UI: stable pagination over a dataset that keeps changing, scroll-edge detection that does not block the main thread, and rendering enough items to feel endless without melting the device. This article gives you the mental model, the source-backed defaults, and the failure modes that matter when the feed grows from hundreds of items to millions.

Mental model

Three layers, each owned by a different failure mode:

1. Pagination — keyset (cursor) traversal so insertions and deletions don’t shift the user’s position. Compound cursors (timestamp, id) break ties deterministically. (use-the-index-luke / Markus Winand)
2. Detection — IntersectionObserver on a sentinel node near the viewport edge. The observer runs off the main thread, so scroll never blocks on JavaScript.
3. Rendering — virtualization: render only the items in (or near) the viewport. A 50,000-item feed lives comfortably under the Lighthouse “excessive DOM” thresholds.

The five decisions that matter most:

Why offset pagination breaks

The naive shape — OFFSET and LIMIT — fails for two independent reasons.

1SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 40;

It is not stable under writes. A new row inserted at the top shifts every row down by one. The next page (OFFSET 60) starts one row earlier than it should, so the user sees a duplicate or skips an item. This is not a race in the strict sense — it happens with any concurrent write, even on a single connection. (Markus Winand, PostgreSQL row-wise comparison docs)

It does linear work in the offset. PostgreSQL (and MySQL) cannot “seek” past OFFSET rows. The executor reads and discards every row before the offset, even when an index covers the order. At OFFSET 1_000_000, the query reads 1,000,000+ rows before returning anything. (Markus Winand)

Offset still has its place: admin tables with stable data, reports with bounded depth, and any UI that genuinely needs “go to page 47”. For a live feed, it is the wrong tool.

Browser constraints

These are the budgets a feed has to live inside:

• Frame budget. 60 fps means every frame has ~16.67 ms of main-thread time. Any synchronous work that forces layout (offsetHeight, getBoundingClientRect after a write) inside a scroll handler eats into that budget. (web.dev: how large DOMs affect interactivity)
• DOM size. Lighthouse warns at >800 body nodes and flags an error at >1,400, with extra warnings for depth >32 or >60 children under one parent. These are heuristics, not hard limits, but they correlate well with Interaction-to-Next-Paint regressions. A naive feed at 50,000 items × 5–20 nodes per item blows past the error threshold immediately. (web.dev: avoid an excessive DOM, Lighthouse audit reference)
• Memory pressure. Large feeds accumulate JS heap (item state, cached pages) and GPU/ tile memory (rendered nodes, images). When the OS runs low, mobile browsers reload tabs without warning. Direct heap visibility from JS is non-standard — see Memory monitoring.
• Passive scroll. Modern browsers default touchstart, touchmove, and wheel listeners on window/document/document.body to passive: true so scroll never blocks on JS. Don’t fight this — never call preventDefault() inside a scroll-relevant handler unless you actually need to (e.g. a custom pull-to-refresh). (Lighthouse: use passive listeners)

UX expectations, on top of those budgets:

Choosing a path

There are three viable shapes for a feed UI. The decision turns on item count, height variance, and accessibility constraints.

Path 1 — IntersectionObserver + keyset cursor

The default for most feeds under ~1,000 items per session: dense enough to need infinite scroll, small enough that you don’t need virtualization yet.

The observer watches a sentinel positioned just below the last rendered item. When the sentinel intersects the (expanded) viewport, the callback fires and the next keyset page is requested. No scroll handlers, no forced layout.

Show 2 hidden lines34function createFeedObserver(5  onLoadMore: () => void,6  options: { rootMargin?: string; threshold?: number } = {},7) {8  const { rootMargin = "0px 0px 200px 0px", threshold = 0 } = options9  return new IntersectionObserver(10    (entries) => {11      const [entry] = entries12      if (entry.isIntersecting) onLoadMore()13    },14    { rootMargin, threshold },15  )16}1718const sentinel = document.getElementById("load-more-sentinel")!19const observer = createFeedObserver(() => fetchNextPage(currentCursor))20observer.observe(sentinel)

Best for social feeds, comment threads, search results — anything where the dataset is large but the typical session reads a few dozen to a few hundred items.

Trade-offs:

• ✅ Off-main-thread detection; battery-friendly.
• ✅ Layered cleanly under virtualization when you outgrow it.
• ❌ No direct page jumping — total count is often unknown.
• ❌ “Find in page” only sees rendered items — see Accessibility limitations.

Path 2 — Virtualized list + keyset cursor

Once you cross ~1,000 items per session, or the per-item DOM is rich enough to push you near Lighthouse limits, you need virtualization. The list maintains a known total height via spacer elements and only renders the items currently inside the viewport plus a small overscan buffer.

Show 3 hidden lines45type FeedItem = { id: string; content: string }6type PageResponse = { items: FeedItem[]; nextCursor: string | null }78function VirtualizedFeed() {9  const parentRef = useRef<HTMLDivElement>(null)1011  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfiniteQuery({12    queryKey: ["feed"],13    queryFn: ({ pageParam }) => fetchFeedPage(pageParam),14    initialPageParam: null as string | null,15    getNextPageParam: (lastPage) => lastPage.nextCursor,16    maxPages: 10,17  })1819  const allItems = data?.pages.flatMap((page) => page.items) ?? []2021  const virtualizer = useVirtualizer({22    count: hasNextPage ? allItems.length + 1 : allItems.length,23    getScrollElement: () => parentRef.current,24    estimateSize: () => 100,25    overscan: 5,26  })27Show 18 hidden lines46              width: "100%",47              transform: `translateY(${virtualItem.start}px)`,48            }}49          >50            {virtualItem.index < allItems.length ? (51              <FeedItemComponent item={allItems[virtualItem.index]} />52            ) : (53              <LoadingPlaceholder />54            )}55          </div>56        ))}57      </div>58    </div>59  )60}

Trade-offs:

• ✅ DOM stays at O(viewport), ~20–50 nodes regardless of total item count.
• ✅ Memory grows only with cached pages, capped by maxPages.
• ❌ Scroll restoration is harder (no DOM nodes to anchor on — see Scroll restoration).
• ❌ Variable item heights add complexity; they require measurement and break find-in-page.

Path 3 — Hybrid with explicit “Load more”

Infinite scroll for the common case, with an explicit “Load more” button (and a user-preference toggle) for accessibility and footer access.

Show 5 hidden lines6function HybridFeed({ userPreference }: { userPreference: LoadMode }) {7  const [mode, setMode] = useState(userPreference)8  const { data, fetchNextPage, hasNextPage, isFetching } = useInfiniteQuery({9    /* ... */10  })1112  return (13    <div>14      <ModeToggle mode={mode} onChange={setMode} />15      <FeedList items={data?.pages.flatMap((p) => p.items) ?? []} />16      {hasNextPage && mode === "manual" && (17        <button onClick={() => fetchNextPage()} disabled={isFetching}>18          Load more19        </button>20      )}21      {hasNextPage && mode === "auto" && (22        <IntersectionSentinel onVisible={() => fetchNextPage()} />23      )}24    </div>25  )26}

Trade-offs:

• ✅ Footer remains reachable.
• ✅ Lower cognitive load on long sessions.
• ❌ One extra interaction per page.
• ❌ Two code paths to maintain.

Decision matrix

Cursor-based pagination

Compound cursors

A single-field cursor (timestamp only) is broken the moment two rows share that field — the next request either skips both or returns one of them twice. Use a compound key with a unique tiebreaker, almost always the row ID. PostgreSQL’s row-wise comparison expresses this directly:

1SELECT id, created_at, content2FROM posts3WHERE (created_at, id) < ('2026-01-15T12:00:00Z', 'abc123')4ORDER BY created_at DESC, id DESC5LIMIT 20;

The tuple comparison (created_at, id) < (cursor_ts, cursor_id) gives deterministic ordering and uses a composite index on (created_at, id) directly. (PostgreSQL: Row-Wise Comparison)

Cursor encoding

Two questions: opaque vs transparent, and signed vs unsigned.

Opaque (Base64 of the payload) is the safer default. Clients can’t depend on the structure, so you can change the underlying schema without breaking them.

1function encodeCursor(createdAt: Date, id: string): string {2  return Buffer.from(JSON.stringify({ createdAt: createdAt.toISOString(), id })).toString("base64")3}45function decodeCursor(cursor: string): { createdAt: Date; id: string } {6  const { createdAt, id } = JSON.parse(Buffer.from(cursor, "base64").toString())7  return { createdAt: new Date(createdAt), id }8}

Signed cursors stop clients from forging cursors that point at rows the API would otherwise filter (e.g. peeking at content scheduled for the future). Sign with HMAC-SHA-256 and verify in constant time:

Show 3 hidden lines45function signCursor(payload: object): string {6  const data = JSON.stringify(payload)7  const signature = crypto.createHmac("sha256", SECRET).update(data).digest("hex")8  return Buffer.from(`${data}|${signature}`).toString("base64url")9}1011function verifyCursor(cursor: string): object | null {12  const decoded = Buffer.from(cursor, "base64url").toString()13  const sep = decoded.lastIndexOf("|")14  if (sep < 0) return null15  const data = decoded.slice(0, sep)16  const signature = decoded.slice(sep + 1)17  const expected = crypto.createHmac("sha256", SECRET).update(data).digest("hex")18  const a = Buffer.from(signature, "hex")19  const b = Buffer.from(expected, "hex")20  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) return null21  return JSON.parse(data)22}

API response shape

1interface PaginatedResponse<T> {2  items: T[]3  nextCursor: string | null4  prevCursor?: string | null5  hasMore?: boolean6  totalCount?: number7}

nextCursor: null is sufficient to signal end-of-stream; the explicit hasMore flag is redundant but useful for clients that prefer to branch on a boolean. totalCount is expensive — SELECT COUNT(*) on a large table can be the slowest part of the request — so emit it only when consumers actually need it.

A standards-aligned alternative — useful for public APIs and hypermedia clients — is to ship pagination links in the HTTP Link header per RFC 8288 (Web Linking). The body stays as { items }, and the response carries:

1Link: <https://api.example.com/feed?cursor=eyJ0Ijo...>; rel="next",2      <https://api.example.com/feed>; rel="first"

This is the shape GitHub’s REST API uses (GitHub: pagination). The trade-off: clients must parse the Link header (the IANA-registered relation types next, prev, first, last are well covered by libraries like parse-link-header) and you lose the JSON-shaped nextCursor ergonomics. Pick one and stick to it.

Bidirectional pagination

Required for chat (“scroll up for history”), feeds with “new items above”, and deep-linked content in the middle of a list. TanStack Query v5 supports it natively:

1const { data, fetchNextPage, fetchPreviousPage, hasNextPage, hasPreviousPage } = useInfiniteQuery({2  queryKey: ["feed"],3  queryFn: ({ pageParam }) => fetchPage(pageParam),4  initialPageParam: null as string | null,5  getNextPageParam: (lastPage) => lastPage.nextCursor,6  getPreviousPageParam: (firstPage) => firstPage.prevCursor,7  maxPages: 10,8})

The v5 docs make one important rule explicit: if maxPages > 0, both getNextPageParam and getPreviousPageParam must return real cursors (not undefined) so the cache can refill in either direction after eviction. (TanStack Query v5 — Infinite Queries)

Scroll detection

IntersectionObserver configuration

1const observer = new IntersectionObserver(callback, {2  root: null,3  rootMargin: "0px 0px 200px 0px",4  threshold: 0,5})

Per the W3C IntersectionObserver spec and MDN’s rootMargin reference:

• rootMargin accepts pixel or percentage values (1–4 components, CSS-margin shorthand). Positive values expand the root box (you trigger early), negative values shrink it (you trigger inside the viewport).
• threshold is the visible fraction at which the callback runs: 0 for “any pixel intersects”, 1.0 for “entirely visible”. Pass an array [0, 0.5, 1] to fire at multiple points.
• The callback is asynchronous and batched across observed targets, so a fast scroll yields one callback invocation per frame, not one per intersection event.

For bidirectional loading, observe a top sentinel and a bottom sentinel from the same observer:

Show 2 hidden lines34function createBidirectionalObserver(onLoad: LoadHandler) {5  return new IntersectionObserver(6    (entries) => {7      for (const entry of entries) {8        if (!entry.isIntersecting) continue9        const direction = entry.target.id === "top-sentinel" ? "backward" : "forward"10        onLoad(direction)11      }12    },13    { rootMargin: "200px" },14  )15}

Adaptive trigger distance

A fixed 200px rootMargin is fine for typical conditions. You can do better when you know the scroll velocity and the average fetch latency: trigger when the user is roughly two fetch-latencies away from the end.

Show 4 hidden lines56function calculateRootMargin({ avgFetchTimeMs, scrollVelocityPxPerSec }: AdaptiveConfig): string {7  const pixelsNeeded = scrollVelocityPxPerSec * (avgFetchTimeMs / 1000) * 28  const margin = Math.max(200, Math.min(800, pixelsNeeded))9  return `0px 0px ${margin}px 0px`10}

Preventing duplicate requests

Fast scrolling can fire the callback multiple times before the first request settles. Coalesce on a single in-flight token and cancel stale requests with AbortController:

Show 3 hidden lines4async function fetchNextPageSafe(cursor: string) {5  if (isLoading) return6  currentController?.abort()7  currentController = new AbortController()8  isLoading = true910  try {11    const response = await fetch(`/api/feed?cursor=${encodeURIComponent(cursor)}`, {12      signal: currentController.signal,13    })14    return await response.json()15  } catch (error) {16    if (error instanceof DOMException && error.name === "AbortError") return null17    throw error18  } finally {19    isLoading = false20  }21}

TanStack Query handles this for you via the query key — concurrent fetchNextPage() calls are deduplicated, and the previous request is aborted when a new one starts.

Virtualization

Fixed-height

When every item has the same height, position math is O(1):

1const startIndex = Math.floor(scrollTop / itemHeight)2const visibleCount = Math.ceil(viewportHeight / itemHeight)3const endIndex = Math.min(startIndex + visibleCount + overscan, totalItems)4const offsetY = startIndex * itemHeight

react-window’s FixedSizeList is the smallest, simplest implementation:

Show 4 hidden lines5function FeedList({ items }: { items: ItemData["items"] }) {6  return (7    <FixedSizeList8      height={600}9      itemCount={items.length}10      itemSize={80}11      width="100%"12      itemData={{ items }}13    >14      {({ index, style, data }) => (15        <div style={style}>16          <FeedItem item={data.items[index]} />17        </div>18      )}19    </FixedSizeList>20  )21}

Best fit: log viewers, simple message lists, dense uniform tables.

Variable-height

Real feeds have heterogeneous content — images, embeds, different text lengths. Three problems compound:

1. Heights are unknown until the item renders.
2. When estimates are corrected, scroll position can jump.
3. Bidirectional scrolling makes the layout shift problem worse.

react-virtuoso handles these end-to-end with a measurement step on first render and an anchor-based layout:

Show 3 hidden lines45function VariableFeed({ items }: { items: FeedItem[] }) {6  return (7    <Virtuoso8      data={items}9      itemContent={(_, item) => <FeedItem item={item} />}10      endReached={() => fetchNextPage()}11      increaseViewportBy={{ top: 200, bottom: 200 }}12    />13  )14}

To keep variable-height feeds calm:

• Increase overscan above the viewport so re-measurements don’t push current items off-screen.
• Use a defaultItemHeight close to the median content type.
• Maintain a stable anchor item across layout shifts.

Browser-native content-visibility: auto with contain-intrinsic-size is a complementary tactic for less interactive lists — it keeps DOM nodes alive but skips painting and most layout for off-screen content. (web.dev: content-visibility)

Library comparison

react-window has the smallest footprint and the simplest mental model. Pair with react-window-infinite-loader for pagination.

react-virtuoso is the pragmatic default for variable-height feeds. The extra bytes pay for measurement, scroll-to accuracy, and good defaults.

@tanstack/react-virtual is headless. You wire the rendering loop yourself, but you keep full control over markup and styling.

State management

Normalized vs denormalized

Denormalized (raw page envelopes):

1{2  pages: [3    { items: [{ id: "1", author: { id: "a", name: "Alice" } }] },4    { items: [{ id: "2", author: { id: "a", name: "Alice" } }] },5  ]6}

Normalized (entities by id, references by id):

1{2  items: {3    byId: {4      "1": { id: "1", authorId: "a" },5      "2": { id: "2", authorId: "a" },6    },7    allIds: ["1", "2"],8  },9  authors: {10    byId: { a: { id: "a", name: "Alice" } },11  },12  feed: { itemIds: ["1", "2"], nextCursor: "xyz" },13}

Normalize when entities recur (authors, tags, replied-to posts) or update independently. The wins are well-trodden: no duplicate data, O(1) lookups by id, single source of truth for mutations, shallow equality for memoization. (Redux: Normalizing State Shape)

Memory bounding

Long feed sessions accumulate. There are three practical bounds, in increasing order of complexity.

Cap pages in cache — TanStack Query’s maxPages evicts the oldest page once the limit is reached, refetching on demand if the user scrolls back:

1useInfiniteQuery({2  queryKey: ["feed"],3  queryFn: fetchPage,4  initialPageParam: null as string | null,5  maxPages: 5,6  getNextPageParam: (last) => last.nextCursor,7  getPreviousPageParam: (first) => first.prevCursor,8})

Tombstone heavy fields — keep the item placeholder for layout, drop the heavy parts (images, embeds, parsed bodies) when the item is far off-screen:

1type Tombstone = { id: string; tombstoned: true }23function maybeEvictItem(item: FeedItem, isVisible: boolean): FeedItem | Tombstone {4  if (!isVisible && item.mediaUrls?.length) return { id: item.id, tombstoned: true }5  return item6}

Offload to IndexedDB — for sessions that can run for hours (chat, email), persist old pages to IndexedDB and re-hydrate on scroll-back. The trade-off is more code and more failure modes (quota errors, schema migrations).

Feed refresh

New item indicators

Auto-prepending new items moves the user’s reading position without consent. Use a banner instead, and let the user choose when to scroll:

Show 5 hidden lines6function Feed() {7  const [newItemIds, setNewItemIds] = useState<string[]>([])89  useEffect(() => {10    const interval = setInterval(async () => {11      const latestId = items[0]?.id12      const newItems = await checkForNewItems(latestId)13      if (newItems.length) {14        setNewItemIds((prev) => [...newItems.map((i) => i.id), ...prev])15      }16    }, 30_000)17    return () => clearInterval(interval)18  }, [items])1920  const showNewItems = useCallback(() => {21    prependItems(newItemIds)22    scrollToTop()23    setNewItemIds([])24  }, [newItemIds])2526  return (27    <>28      {newItemIds.length > 0 && (29        <button className="new-items-banner" onClick={showNewItems}>30          {newItemIds.length} new posts31        </button>32      )}33      <FeedList items={items} />34    </>35  )36}

Chat is a deliberate exception: in a thread the user expects new messages to appear at the bottom. Implement it with an anchor element so the scroll position stays glued to the visible message, not to a pixel offset.

For UIs that must insert above the user’s reading position (live ops dashboards, comment threads with replies above), lean on the browser’s scroll anchoring instead of computing offsets by hand. The browser picks an anchor inside the viewport and adjusts scrollTop in the same frame as the layout change, so the user’s eye never tracks a jump:

1.feed {2  overflow-anchor: auto;3}

overflow-anchor is on by default in Chromium and Firefox; setting auto is just the explicit form. Safari ships it only in Technology Preview as of April 2026 (caniuse), so on iOS you still need an explicit anchor — capture scrollHeight before insert, set scrollTop += scrollHeight_after - scrollHeight_before. Set overflow-anchor: none selectively on elements (banners, sticky headers) you do not want chosen as anchors.

Pull-to-refresh

The web has no native pull-to-refresh API. To build one, you need to detect a touch start at scroll position 0, track the pull distance, and prevent the browser’s own gesture from interfering:

Show 4 hidden lines5function usePullToRefresh(onRefresh: () => Promise<void>) {6  const [state, setState] = useState<PullState>("idle")7  const [pullDistance, setPullDistance] = useState(0)8  const startY = useRef(0)910  const handleTouchStart = (e: TouchEvent) => {11    if (window.scrollY === 0) {12      startY.current = e.touches[0].pageY13      setState("pulling")14    }15  }1617  const handleTouchMove = (e: TouchEvent) => {18    if (state !== "pulling") return19    const distance = e.touches[0].pageY - startY.current20    setPullDistance(Math.max(0, Math.min(distance, 150)))21  }2223  const handleTouchEnd = async () => {24    if (pullDistance > 100) {25      setState("refreshing")26      await onRefresh()27    }28    setState("idle")29    setPullDistance(0)30  }3132  return { state, pullDistance, handleTouchStart, handleTouchMove, handleTouchEnd }33}

Disable the browser’s own pull-to-refresh and overscroll chaining:

1html,2body {3  overscroll-behavior-y: contain;4}

contain blocks scroll chaining and (on Chrome Android) suppresses the native pull-to-refresh while keeping the overscroll glow; none additionally suppresses the glow. Apply on both html and body to get consistent behavior across engines. (Chrome for Developers: take control of your scroll, MDN: overscroll-behavior)

Gap detection

The user paused at page 5. New items arrived while they were idle. Pages 2–4 now have unknown rows between them — gaps. Detect by comparing each page’s endCursor to the next page’s startCursor:

1function detectGap(pages: Page[]): { gapAfterPage: number; cursor: string } | null {2  for (let i = 1; i < pages.length; i++) {3    const prevEnd = pages[i - 1].endCursor4    const currStart = pages[i].startCursor5    if (prevEnd !== currStart) {6      return { gapAfterPage: i - 1, cursor: prevEnd }7    }8  }9  return null10}

Three viable strategies, in increasing complexity:

• Lazy fill — wait until the user scrolls into the gap, then fetch with the gap cursor.
• Background fill — fetch on requestIdleCallback (or a setTimeout(0) fallback in browsers that don’t ship it).
• Invalidate — drop the cache and refetch from the top. Simplest, but loses the user’s place.

Error handling

Retry with exponential backoff and jitter

1function calculateDelay(attempt: number): number {2  const baseDelay = 1003  const maxDelay = 30_0004  const exponential = baseDelay * Math.pow(2, attempt)5  const jitter = Math.random() * 10006  return Math.min(exponential + jitter, maxDelay)7}

Jitter is non-negotiable: without it, every client retries at the same instant after a transient outage and re-DDoSes the recovering service. (AWS Architecture Blog: exponential backoff and jitter)

What to retry, by status:

Inline recovery

Don’t unmount the feed on a fetch failure — the user has been scrolling for a while and losing position is worse than seeing an inline error. Surface the error next to the affected page boundary, and let the user retry without reloading:

Show 5 hidden lines6function FeedWithErrorBoundary() {7  const { data, error, refetch, isError, failureCount } = useInfiniteQuery({8    queryKey: ["feed"],9    queryFn: fetchPage,10    initialPageParam: null as string | null,11    retry: 3,12    retryDelay: (attempt) => calculateDelay(attempt),13  })1415  if (isError) {16    return (17      <div role="alert">18        <p>Failed to load feed: {error.message}</p>19        <button onClick={() => refetch()}>20          Retry ({failureCount}/3 attempts)21        </button>22      </div>23    )24  }2526  return <FeedList pages={data?.pages ?? []} />27}

Stale-while-revalidate

Show cached content immediately, fetch fresh in the background, and swap once the new data arrives. The pattern is standardized as an HTTP cache-control extension in RFC 5861 and explained for the client side on web.dev:

1const { data, isStale, isFetching } = useInfiniteQuery({2  queryKey: ["feed"],3  queryFn: fetchPage,4  initialPageParam: null as string | null,5  staleTime: 60 * 1000,6  gcTime: 5 * 60 * 1000,7  refetchOnWindowFocus: true,8  refetchOnReconnect: true,9})

Scroll position restoration

History scroll restoration

Per the HTML Living Standard, history.scrollRestoration lets a SPA opt out of the browser’s automatic (and often wrong-for-SPAs) scroll restore:

1if ("scrollRestoration" in history) {2  history.scrollRestoration = "manual"3}

The browsers don’t agree on the order of popstate and the auto-restore: Chrome restores after popstate, Firefox before. Once you opt into manual mode, this stops mattering — you do the restore yourself.

Framework routers wire most of this for you, but the defaults vary and they all leave the cache-rehydrate step to you:

• Next.js (App Router) restores scroll on back/forward by default for client transitions; full reloads use the browser’s native restore. The router sets history.scrollRestoration = "manual" itself, so do not flip it back. (Next.js docs)
• TanStack Router ships an opt-in ScrollRestoration component that persists position by route key and integrates with virtualization (useElementScrollRestoration). (TanStack Router scroll restoration)
• React Router v6+ ships <ScrollRestoration />. It restores by location key by default and accepts a getKey callback to share scroll across query-string variations.

Session storage

Store enough to rebuild the view: the page count, the scroll position, and an anchor item ID so re-fetching a page that arrived in different positions still lands the user on the same item:

Show 5 hidden lines6}78function saveScrollState(key: string, state: ScrollState) {9  sessionStorage.setItem(key, JSON.stringify(state))10}1112function restoreScrollState(key: string): ScrollState | null {13  const saved = sessionStorage.getItem(key)14  if (!saved) return null15  const state: ScrollState = JSON.parse(saved)16  if (Date.now() - state.timestamp > 300_000) {17    sessionStorage.removeItem(key)18    return null19  }20  return state21}2223function useScrollRestoration(feedKey: string, setSize: (size: number) => void) {24  useEffect(() => {25    const state = restoreScrollState(feedKey)26    if (!state) return27    setSize(state.pageCount)28    requestAnimationFrame(() => {29      window.scrollTo(0, state.scrollY)30      sessionStorage.removeItem(feedKey)31    })32  }, [feedKey, setSize])33}

Virtualization complications

Virtualized lists don’t keep a DOM node per item, so pixel-based restoration is fragile — when re-measurement corrects an estimate, your saved scrollY is suddenly wrong. Three strategies, from simplest to most accurate:

1. Index-based. Store the index of the first visible item and call scrollToIndex on restore. Works when items are roughly the same height.
2. Anchor-based. Store the item ID, scrollToIndex after restore, then nudge by the measured anchor offset. Accurate even with variable heights.
3. Time-limited. Only restore for navigations within ~30 seconds; fall back to “top of feed” otherwise. Avoids restoring to a stale anchor that has since been evicted.

1const virtualizer = useVirtualizer({2  count: items.length,3  getScrollElement: () => parentRef.current,4  estimateSize: () => 100,5})67useEffect(() => {8  const savedIndex = sessionStorage.getItem("lastVisibleIndex")9  if (savedIndex) {10    virtualizer.scrollToIndex(parseInt(savedIndex, 10), { align: "start", behavior: "auto" })11  }12}, [])

Accessibility

ARIA feed pattern

The W3C ARIA Authoring Practices Guide — Feed Pattern and the matching MDN feed role reference define an interoperability contract between the feed and assistive technologies.

1<div role="feed" aria-busy="false" aria-label="News feed">2  <article3    role="article"4    aria-labelledby="post-1-title"5    aria-posinset="1"6    aria-setsize="-1"7    tabindex="0"8  >9    <h2 id="post-1-title">Post Title</h2>10    <p>Post content...</p>11  </article>12  <!-- More articles -->13</div>

Required attributes per APG:

• aria-busy="true" on the feed during DOM updates; "false" when the update completes.
• aria-posinset on each article (1-indexed position).
• aria-setsize on each article — -1 when the total is unknown or unbounded (the typical infinite-feed case).
• aria-labelledby on each article, pointing at a label inside the article.
• Each article must be focusable (tabindex="0" or -1), and the application must scroll an article into view when it or one of its descendants takes focus.

Keyboard navigation

The APG specifies arrow keys for moving between articles, plus Home/End for jumping to the first or last loaded article. The j/k shortcuts are conventional in many feed apps but not part of the spec:

1function handleFeedKeyDown(event: KeyboardEvent) {2  const current = (document.activeElement as HTMLElement | null)?.closest('[role="article"]')3  if (!current) return45  switch (event.key) {6    case "ArrowDown":7    case "j":8      focusNextArticle(current)9      event.preventDefault()10      break11    case "ArrowUp":12    case "k":13      focusPreviousArticle(current)14      event.preventDefault()15      break16    case "Home":17      focusFirstArticle()18      event.preventDefault()19      break20    case "End":21      focusLastArticle()22      event.preventDefault()23      break24  }25}

Accessibility limitations

Infinite scroll is hostile to several user populations regardless of how cleanly you implement the ARIA contract:

• Keyboard users can’t reach the footer without tabbing through every loaded article.
• Screen-reader users find dynamic content insertion disorienting, especially when items appear above the current focus.
• Users with motor disabilities experience scroll fatigue on long sessions.
• Browser find-in-page only sees rendered DOM. With virtualization, items outside the viewport are invisible to Cmd/Ctrl+F.

Practical mitigations, in priority order:

• A skip link to the footer (<a href="#footer" class="skip-link">Skip to footer</a>) at the top of the page, plus scroll-margin-top on the footer landmark so the link target isn’t covered by a sticky header.
• A “Load more” alternative or a user-preference toggle (Path 3). Nielsen Norman Group’s Infinite Scrolling: When to Use It, When to Avoid It treats this as a baseline a11y requirement, not a nicety.
• A page-chunking alternative: load N items per “page”, show a numbered or “Load page 4 of 12” affordance, and make each page a heading (<h2>Page 4</h2> with a stable anchor) so screen-reader rotor users can jump between chunks. This is the most accessible of the three patterns when item count is bounded and known.
• A live region announcing loading state (<div role="status" aria-live="polite">Loading more posts…</div>).
• A visible “End of feed” marker — silence is ambiguous.

Browser performance

Avoid layout thrashing in scroll handlers

Even if you use IntersectionObserver for pagination, you may still have scroll handlers (analytics, sticky headers). The classic footgun is interleaved reads and writes that force the browser to recompute layout twice:

1element.style.width = "100px"2const height = element.offsetHeight34const cachedHeight = element.offsetHeight5element.style.width = "100px"

Always opt scroll-relevant listeners into passive mode so the browser can scroll without waiting for the JS callback to finish. Modern browsers default touchstart, touchmove, and wheel to passive: true on document-level targets, but it’s safer to be explicit:

1element.addEventListener("scroll", handler, { passive: true })

Background work with requestIdleCallback

requestIdleCallback lets you push non-critical work — analytics, image pre-decoding, prefetching — into the gaps between frames:

1function processInBackground(items: Item[]) {2  let index = 034  function processChunk(deadline: IdleDeadline) {5    while (deadline.timeRemaining() > 0 && index < items.length) {6      processItem(items[index++])7    }8    if (index < items.length) requestIdleCallback(processChunk)9  }1011  requestIdleCallback(processChunk, { timeout: 2000 })12}

1const ric: typeof window.requestIdleCallback =2  window.requestIdleCallback?.bind(window) ??3  ((cb) => setTimeout(() => cb({ didTimeout: false, timeRemaining: () => 0 }), 1))

Memory monitoring

Direct heap visibility from JavaScript is non-standard and Chromium-only. The legacy performance.memory is non-standard, deprecated, and reports only the JS heap. The proposed standard replacement is performance.measureUserAgentSpecificMemory(), which reports a more complete picture but only works in cross-origin-isolated pages and is also Chromium-only at present.

1type LegacyPerf = Performance & {2  memory?: { usedJSHeapSize: number; jsHeapSizeLimit: number }3}45function checkMemoryPressure(): boolean {6  const perf = performance as LegacyPerf7  if (!perf.memory) return false8  const { usedJSHeapSize, jsHeapSizeLimit } = perf.memory9  return usedJSHeapSize / jsHeapSizeLimit > 0.810}1112if (checkMemoryPressure()) trimOldPages()

Treat any reading from these APIs as advisory. Make memory bounding (page caps, tombstoning) the default — don’t rely on knowing when memory is “tight”.

Real-world implementations

The detail here is sketchy on purpose. Public posts from these companies are years apart and they each rewrite their feed stack continuously; treat the named systems as illustrative architecture rather than current production reality.

Twitter / X. Cursor-based pagination over the timeline, with opaque tokens encoding position. The product surfaces “Show N new posts” rather than auto-prepending, and shows “Show N posts” inline to fill gaps detected on return-from-background. Numbers like “Twitter renders ~140 DOM nodes regardless of scroll depth” circulate in the community but are not confirmed by primary engineering posts; the right take-away is “production feeds use aggressive virtualization and aim for an O(viewport) DOM”.

Instagram. Multi-tier caching — in-memory LRU for the immediate window, on-device storage (SQLite/IndexedDB) for offline scroll, network on miss. Items outside the viewport are unmounted, not just hidden, to keep DOM size flat.

LinkedIn. The 2016 FollowFeed post documents the two-pass ranking model: a cheap First-Pass Ranker reduces a large candidate pool to a small short-list, and a more expensive Second-Pass Ranker scores the short-list to produce final order. The architecture has continued to evolve — recent posts describe transformer-based sequential recommenders (Feed SR) replacing earlier DCNv2 rankers — but the two-pass shape (candidate generation → re-ranking under a strict latency budget) is still the operating pattern.

Conclusion

Three layers, three defaults, four leverage points.

The defaults: keyset cursors with compound (timestamp, id) for pagination, IntersectionObserver on a sentinel for detection, virtualization above ~1,000 items for rendering. For most product feeds, TanStack Query’s useInfiniteQuery plus react-virtuoso covers all three, and you should reach for that combination before building anything custom.

The four leverage points where most production bugs hide:

1. Cursor design. Compound, opaque, signed. Verify the row-tuple comparison actually uses your composite index — especially on MySQL.
2. Memory bounding. Decide your maxPages (or equivalent) before you ship; long sessions will find your bug if you don’t.
3. New-item handling. Banner pattern by default; never auto-scroll a reading user.
4. Accessibility fallback. A user-preference toggle and a “Load more” path are not optional. Without them you’ve shipped a feed that some of your users can’t navigate.

Appendix

Prerequisites

• IntersectionObserver, AbortController, requestIdleCallback (with fallback).
• Component model with effect / lifecycle hooks (React, Vue 3, Svelte 5, etc.).
• HTTP caching basics, including stale-while-revalidate.
• The ARIA feed pattern and the broader cost of dynamic content for assistive tech.

Terminology

• Cursor — opaque token encoding a position in a paginated dataset.
• Keyset pagination — cursor implementation that uses row-value comparisons against an indexed key.
• Sentinel — a DOM element observed to trigger pagination (or any other “you’ve scrolled here” event).
• Virtualization — rendering only viewport-adjacent items while preserving total scroll height.
• Overscan — extra items rendered above and below the viewport for smooth scrolling.
• Tombstone — placeholder that preserves layout but drops heavy fields of an evicted item.
• SWR — stale-while-revalidate, a caching pattern (RFC 5861) and a popular React library that implements it.

Summary

• Keyset (cursor) pagination is stable under writes and runs in time independent of the offset; OFFSET pagination is neither.
• IntersectionObserver detects scroll-edge crossings without blocking the main thread; pair with AbortController to cancel stale fetches.
• Virtualization keeps DOM nodes bounded at O(viewport); react-virtuoso is the pragmatic default for variable-height feeds.
• Memory bounding (page caps, tombstoning, IndexedDB offload) is mandatory for long sessions.
• Banner-on-new-content respects user attention; reserve auto-scroll for chat-style anchored layouts.
• Scroll restoration in a SPA needs history.scrollRestoration = "manual" plus an anchor item, not just a pixel offset.
• The ARIA feed pattern is a contract, not a hint — aria-busy, aria-setsize, aria-posinset, focusable articles. Always provide a non-infinite alternative.

References

• W3C — IntersectionObserver
• W3C — ARIA Authoring Practices: Feed Pattern
• WHATWG — HTML Living Standard: history.scrollRestoration
• IETF — RFC 5861: HTTP Cache-Control extensions for stale content
• PostgreSQL — Row-wise comparison
• MySQL — Row Constructor Expression Optimization (8.4 Manual §10.2.1.22)
• MDN — IntersectionObserver, feed role, overscroll-behavior, Performance.memory
• web.dev — Avoid an excessive DOM size, Stale-while-revalidate, content-visibility
• Chrome for Developers — Take control of your scroll, Lighthouse: passive listeners
• TanStack Query — Infinite Queries (v5)
• Markus Winand — We need tool support for keyset pagination
• LinkedIn Engineering — FollowFeed (2016), Community-focused Feed optimization
• Redux — Normalizing State Shape
• AWS Architecture Blog — Exponential backoff and jitter
• caniuse — requestIdleCallback