Virtual Scrolling for Large Lists

An audit console renders 100,000 log rows and the page hangs for three seconds before first paint; every keystroke in the filter field then locks the main thread for another 200 ms. Nothing in the row markup is heavy — it is the sheer count: 100,000 rows at roughly eight DOM nodes each is 800,000 nodes for the browser to lay out, paint, and keep in memory, for a viewport that can only ever display about twenty of them.

Virtual scrolling changes the question from "how do I render 100,000 rows faster" to "why am I rendering rows nobody can see?" The mechanism has three parts: a viewport element with a fixed height and overflow: auto, an inner spacer whose height equals the full dataset so the scrollbar behaves honestly, and a window of rows — the slice inside the viewport plus a small buffer — positioned at their true offsets.

For fixed row heights the math is pure arithmetic:

const OVERSCAN = 5
const start = Math.max(0, Math.floor(scrollTop / rowHeight) - OVERSCAN)
const end = Math.min(items.length,
  Math.ceil((scrollTop + viewportHeight) / rowHeight) + OVERSCAN)
const totalHeight = items.length * rowHeight

A minimal Vue implementation is about forty lines:

<script setup>
import { ref, computed } from 'vue'
const props = defineProps({ items: { type: Array, required: true },
                            rowHeight: { type: Number, default: 36 } })
const scrollTop = ref(0), viewportH = ref(600), el = ref(null)
const start = computed(() =>
  Math.max(0, Math.floor(scrollTop.value / props.rowHeight) - 5))
const end = computed(() =>
  Math.min(props.items.length,
    Math.ceil((scrollTop.value + viewportH.value) / props.rowHeight) + 5))
const visible = computed(() =>
  props.items.slice(start.value, end.value)
    .map((item, i) => ({ item, offset: (start.value + i) * props.rowHeight })))
</script>

<template>
  <div ref="el" class="viewport" @scroll="scrollTop = $event.currentTarget.scrollTop">
    <div :style="{ height: items.length * rowHeight + 'px', position: 'relative' }">
      <div v-for="{ item, offset } in visible" :key="item.id"
           :style="{ position: 'absolute', top: offset + 'px', height: rowHeight + 'px' }">
        {{ item.label }}
      </div>
    </div>
  </div>
</template>

The effect on the numbers is not incremental:

Two numbers deserve attention. First, 3.6 million pixels of spacer is legal — Chrome clamps elements somewhere around 33.5 million px, so fixed 40 px rows stay safe up to roughly 800,000 items; past that you must cap the reported height and accept a non-linear scrollbar (real libraries expose this as maxScrollOffset behavior). Second, overscan is a latency buffer, not a rendering strategy: scroll events fire between frames, and the window you compute at event time is what gets painted on the next frame. Five to ten rows of cushion hides fast flings; set it to 100 and you have quietly rebuilt the original problem.

The scroll handler must stay trivially cheap — read scrollTop, nothing else. No deep watchers over the source array, no DOM measurement per event; the slice and offset math above are O(1) arithmetic, which is exactly why fixed heights are the default answer when you get "derive virtual scrolling on a whiteboard" in an interview. Note the server too: during SSR there is no viewport and scrollTop is always 0, so the first server-rendered slice should assume a sensible default height and let onMounted correct it. Server-rendered markup for the whole list is the opposite of what you want — the next topic, Server-Side Rendering and Hydration, covers why that mismatch matters.

Chat messages, audit rows with expanding details, feed items with images — real lists do not have uniform heights. A message is 48 px; an attachment preview is 320 px. The moment heights vary, offset = index × rowHeight stops being true, and every guarantee built on it (total height, which row is visible, where to scroll) has to be re-derived from measurements you do not have yet.

The strategy that works in practice has three moving parts: estimate, measure, anchor.

Estimate first. Render every row at a plausible average — say 64 px — so the spacer is n × 64 and the scrollbar exists immediately. For 10,000 rows that is a 640,000 px track: rough, but usable. As rows enter the viewport you measure their real height with ResizeObserver (not offsetTop reads on every frame — that forces synchronous layout) and store it in a measured[] array.

Compute offsets as prefix sums. Row i's offset is the sum of every height before it. With fixed heights that sum is multiplication; with measured heights you keep a prefix-sum structure, and the two implementation choices are a plain offsets array recomputed lazily or a Fenwick tree (binary indexed tree) when you need O(log n) updates instead of O(n) recompaction. Finding the first row at scrollTop is then a binary search over the offsets array:

function indexAt(offsets: number[], y: number): number {
  let lo = 0, hi = offsets.length - 1
  while (lo < hi) {
    const mid = (lo + hi) >> 1
    if (offsets[mid + 1] <= y) lo = mid + 1
    else hi = mid
  }
  return lo
}

Anchor so measurement does not jump the page. This is the failure everyone hits second: while the user reads row 500, a lazy image finishes loading in row 490, its height grows from 64 to 240 px, and every row below shifts down 176 px — mid-scroll, visibly. The fix is scroll anchoring: keep the offset of the row at the top of the viewport as your anchor, and when a measurement above it changes, compensate:

const delta = newOffsetBeforeAnchor - oldOffsetBeforeAnchor
if (delta !== 0 && anchorRowOffset <= viewport.scrollTop) {
  viewport.scrollTop += delta   // same content stays put
}

Measurements below the viewport need no correction at all — nothing the user can see depends on them yet, so you can defer those rows' observation until they scroll into range.

Two practical refinements. Estimate per category rather than globally (a message with an attachment starts at 320 px, plain text at 48 px) and the spacer converges to the truth almost immediately, which keeps the scrollbar from visibly growing under the user. And expose scrollToIndex(i) as scrollTop = offset(i) - viewportHeight + height(i) — for chat, "jump to the newest message" is that one line, provided your offsets are current.

The reason interviewers probe this area: it tests whether you can separate what you know (the data) from what you must measure (the layout) and design a data structure — prefix sums plus binary search — that keeps an interactive operation inside a frame budget. A linear scan per scroll event is O(n) work at 60 Hz, and 10,000 rows × 60 scans is how a virtual list becomes slower than the naive one it replaced.

Your windowed list mounts about 27 rows per frame, but a scroll gesture generates sixty updates a second. Whether those updates cost 0.2 ms or 8 ms comes down to two decisions: how rows are keyed, and how much of each row Vue is allowed to skip.

Keys decide what gets reused. As the window slides from rows 10–36 to 11–37, keyed by item.id Vue's diff sees twenty-six keys it already has: it unmounts row 10, mounts row 37, and touches nothing else — two vnode operations per frame instead of twenty-seven. Keyed by array index the key set looks identical across frames, so Vue patches all twenty-seven rows in place, rewriting every binding because the underlying item changed. Worse, the DOM node that held row 10's content is recycled to display row 11: an <input> the user focused scrolls with the window and now edits a different record, an in-flight image request paints onto the wrong cell, and the text the user typed appears one row off. Stable, content-derived keys are what let recycled DOM nodes keep their identity — :key="item.id", never :key="index" and never a random value regenerated per render (random keys make every frame a full unmount/remount).

v-memo decides how much of a surviving row re-renders. Even with correct keys, Vue still re-runs the render function for rows that survive the diff. v-memo caches a sub-tree keyed on an array of dependencies and replays the cached vnode when none of them changed:

<div v-for="item in visible" :key="item.id"
     v-memo="[item.id, expandedId === item.id, selectedId === item.id]">
  <RowHeader :item="item" />
  <RowBody v-if="expandedId === item.id" :item="item" />
</div>

For a scrolled-stable row where nothing in the memo array moved, rendering is skipped entirely — that is the "caches static sub-trees across iterations" property the Vue docs demonstrate with exactly this virtual-list example. The discipline it demands: every dynamic value inside the memoized element must appear in the array. Add a new reactive field to RowHeader and forget to add it to v-memo, and you get stale pixels that only a window resize fixes. Memoize rows whose bindings are mostly static; skip it for rows with rich per-frame state.

The rest of the frame budget is engineering hygiene:

• Keep the scroll listener cheap and passive — read scrollTop, update a ref, never measure DOM inside it.
• Position rows with transform: translateY(offset) rather than top: transforms run on the compositor, top re-triggers style recalculation on every frame.
• Do not put the source array under a deep watcher; a computed slice() over an immutable array is O(window), a deep probe is O(n).
• Numbers to hold yourself to: windowed scrolling should patch under 1 ms per frame; if profiling shows long tasks, the usual culprits are index keys (full re-patch), heavy child components without v-memo, or layout-thrashing reads in the scroll path.

One thing virtualization silently breaks is accessibility: a screen reader sees only the mounted rows and announces "row 3 of 32" instead of "row 3 of 100,000". Supply aria-setsize="100000" and aria-posinset="item.position" on each row so assistive tech reports the true population.

Finally, know when not to use this. Under ~200 rows, windowing buys nothing and costs you keyboard navigation edge cases, scrollTo behavior, and print layout. And before writing your own, check what you are reimplementing: vue-virtual-scroller's RecycleScroller and @tanstack/vue-virtual already solve fixed and variable heights, scrollToIndex, and the anchoring math above. Once the list is solved, the data layer around it becomes the limiting factor — which is where Nuxt for Full-Stack Vue Apps picks up the story of fetching and serving that 100,000-row dataset sensibly.