Why Virtual List Is Fast

Under the Hood: Why Virtual List Stays Fast

A browser pays for every element: memory, style matching, layout and paint. The virtual list keeps that bill independent of the data size. With a fixed height, it makes the inner ul as tall as all items together (800 copies × 62 px = 49,600 px), so the scrollbar is honest. On scroll it computes the first row directly, Math.floor(scrollTop / height) minus a buffer of two screens, renders the rows for four screens (two above, one visible, one below), and places each with style.top at index × height. It repaints only after the scroll has moved a whole screen, and keeps built li elements in domCache, so scrolling back reuses them.

A virtual list keeps a window of about four screens of rows in the DOM, positioned absolutely inside a full-height list

To see the difference, build all 5,000 rows as a plain list next to the virtual one, from the console on the inventory page:

Timing 5,000 plain rows against the virtual list, from the DevTools consoleJavaScript

const vl = document.querySelector('.page-current .inventory-list').f7VirtualList;
const { inventory } = await import('/js/api.js');
const count = (el) => el.querySelectorAll('*').length;
const host = document.createElement('div');
document.querySelector('.page-current .page-content').append(host);
let t = performance.now();
const rows = inventory.map((c) => vl.renderItem(c)).join('');
host.innerHTML = `<div class="list"><ul>${rows}</ul></div>`;
host.offsetHeight; // force style and layout now
console.log(`plain: ${count(host)} elements, ${Math.round(performance.now() - t)} ms`);
host.remove();
t = performance.now();
vl.replaceAllItems(inventory);
vl.el.offsetHeight;
console.log(`virtual: ${count(vl.el)} elements, ${Math.round(performance.now() - t)} ms`);

Timings vary from run to run (six runs on a fast desktop took 4.5 to 5.1 seconds for the plain list); one of them printed:

Output of 69

plain: 30002 elements, 4786 ms
virtual: 337 elements, 13 ms

Five seconds of frozen screen on a desktop means far longer on a phone, and the plain list then keeps 30,000 elements alive for every later style change. The limits: rows need a known height for the fast path, the list owns its DOM (render through renderItem or renderExternal, never patch rows yourself), and cols can lay items out in a grid of equal cells.

MENU

Why Virtual List Is Fast