Website: make switching selectors fast

[alexey-milovidov]

Switching selectors on the benchmark pages (main, hardware, versions) had a noticeable lag: every click rebuilt the whole "Detailed Comparison" table (20k–75k cells), and the browser spent most of the time laying it out.

Changes

• Virtualized details table. Column widths and row heights are measured once, on a table holding all header cells plus a single row of the widest cells. They are then fixed (table-layout: fixed + <colgroup>). Only the cells within a screen of the viewport are rendered, and the edges are updated incrementally while scrolling. Widths are measured again when web fonts finish loading.
• Deferred rebuild. The details table is rebuilt right after the summary is painted, so the click responds immediately. If the page is scrolled before that, it is rebuilt synchronously, so outdated data is never shown.
• No forced synchronous layouts. textContent replaces innerText in selector loops. --qn-left on the versions page is no longer rewritten (and the table no longer re-measured) on every render.
• Cheaper computations. Per-cell baseline computations are hoisted out of loops, and selectRun on the versions page is cheaper.

Measurements (headless Chromium, 1600×1000)

	Main	Hardware	Versions
Selector click (median), before → after	~510 → ~80–100 ms	~245 → ~55–75 ms	~1250 → ~100–165 ms
Click while viewing the table	453 → 123 ms	276 → 87 ms	1323 → 192 ms
Longest blocking task	509 → 107 ms	464 → 227 ms	1591 → 121 ms
Worst frame scrolling to the table	—	—	31–35 ms on all pages

Verification

• Screenshots of the old and new pages were compared across all three pages: metric switches, selector toggles, "nothing selected" and back, and many horizontal and vertical positions inside the table, reached both by jumping and by scrolling gradually. All 110 screenshots are pixel-identical.
• The summary after toggling query checkboxes inside the table is identical to the old version.
• No JS errors.

Trade-offs

• Off-screen cells are not in the DOM, so the browser's find-in-page does not find values in the details table until they are scrolled into view.
• The worst frame while scrolling fast inside the versions table went from 55 to 69 ms. The median went from 35 to 19 ms.

🤖 Generated with Claude Code

[alexey-milovidov]

Preview of the main benchmark page from this PR: index.html at ac177c8 with the current results embedded.

[alexey-milovidov]

Yes, it is faster.