Virtualizing a long conversation

Your trace said presentation delay. The callbacks finished, and the frame still could not paint. On a chat surface that verdict has a boring, physical cause more often than a clever one: the transcript is enormous, and the browser is doing style recalculation and layout across every node in it before it can present anything.

The fix for DOM size is windowing — render only the messages in and near the viewport, and give the scroll container the height it would have had. It is a well-worn technique with a well-worn set of libraries. And a conversation is close to the worst list you could apply it to.

Three properties, and each one breaks something

TanStack Virtual now ships a guide dedicated to this case, which is itself the finding. Its announcement post (25 May 2026) states the problem in almost the terms a profile would:

• It grows from the wrong end. “New output appears at the end. Older history loads by prepending items at the start.” A normal list is anchored at the top and grows down. This one is anchored at the bottom and grows at both ends.
• An item changes size after it is rendered. “The last message can grow token by token while the model is streaming.” Not a size you did not know yet — a size that is different one frame later.
• Scroll position is a stated intention. “If someone scrolls up to read history, incoming messages shouldn’t yank them back to the bottom, and if they’re already there, the UI should stay pinned.” Whether to follow depends on what the user did last, not on what arrived.

Hold the vendor position while you read those. TanStack wrote that post to introduce TanStack Virtual’s chat support, so it is a company describing a problem it is about to sell you the answer to. The reason it is still worth citing is the second-order signal: a virtualization library that has existed for years added APIs specifically for this, which is the maintainers stating that the general-purpose setup did not cover it.

Why the naive setup makes the streaming message jump

The mechanism is the second property. A windowing library has to know how tall each item is to place the ones it is not rendering, so it asks you. web.dev’s react-window article gives the two shapes of that question: use FixedSizeList “if you have a long, one-dimensional list of equally sized items,” and VariableSizeList “to render a list of items that have different sizes,” where the list “expects a function for the itemSize prop instead of a specific value.”

A function of index. Asked once, cached, and used to compute the offset of everything after it. That is a perfectly good model for a list whose items differ from each other but not from themselves. A message that gains a paragraph while it is on screen breaks it: the cached height is now wrong, every offset below it is wrong by the same amount, and the library will not find out until something tells it to discard the measurement. The visible symptom is the jump — content settling into a position that does not match where it was drawn a frame ago.

What a chat-aware virtualizer adds

TanStack Virtual’s chat guide names two options that exist for exactly the two properties above:

const virtualizer = useVirtualizer({
  count: messages.length,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 72,
  getItemKey: (index) => messages[index]!.id,
  anchorTo: 'end',
  followOnAppend: true,
  scrollEndThreshold: 80,
  overscan: 6
})

anchorTo: ‘end’ is described there as being for “prepend stability and streaming bottom growth” — the first and second properties, the list that grows at both ends and the last item that changes size under you. followOnAppend is the third: it will “keep the viewport pinned to the end when a new message arrives and the user was already at the end,” and “if the user has scrolled up to read history, appended messages do not pull them away.”

Note getItemKey in that snippet as well. Identity by index is what makes a prepend look like every message changing at once, which is both a correctness problem and a rendering one.

What virtualization costs you

Removing nodes from the DOM removes them from everything that reads the DOM. Browser find-in-page cannot match text that is not rendered. Anything that walks the document, including assistive technology, sees only the window. Anchor links into an old message stop resolving. Copying the whole transcript by selecting it stops working.

None of that is a reason not to virtualize a transcript that has grown past what the browser can lay out in a frame. It is a reason to know what you traded and to say so out loud, because these are the complaints that arrive weeks later and get reported as unrelated bugs. Measure first: on a transcript short enough that presentation delay is fine, virtualization is a large amount of complexity bought with nothing.

What this does not cover

Windowing reduces how many nodes exist. It does nothing about how much work you do per node, per chunk — and re-parsing markdown and re-highlighting a code block on every token is work that windowing happily keeps doing for the handful of messages still on screen. That is the cost-of-parsing-every-token lesson, which closes this module.

It also does not touch render frequency. If your profile named input delay rather than presentation delay, the cause is the length of the render queue in front of the click, and the fix lives in the React module — the keeping-the-stream-out-of-state lesson for the mechanism, the external-store lesson for doing it without fighting React’s model.

And the transcript as a thing with a lifecycle — loading older history, restoring a conversation after a refresh, what a message even is on the wire — is the Streaming interfaces course. Prepending history appears in this lesson only as a property that constrains the scroll math, never as a feature to build here.