Subito's MultiSelect mounted 1,175 options in one commit to paint six rows

Divide the measurement by the work. A local INP of 1,256 ms across roughly 1,175 mounted Option instances is about 1.07 ms per option, measured at a 4x CPU slowdown ^[6][9][2]. That unit only holds if mounting cost scales linearly with the option count, and the 1,256 ms also contains input delay and presentation delay ^[8]. Take it as rough anyway: a dozen options comes out near 13 ms ^[3]. The condition and shipping filters run the same code as the brand filter at one percent of the volume, and Subito says they felt instant ^[2].

The cost sits in a single synchronous commit. react-select hands MenuList the whole options array, and opening the menu builds every Option, each one a label plus a custom Checkbox generating several DOM nodes ^[9]. The visible window had room for about six rows, so React built roughly 1,169 components nobody could see ^[9][5]. That work lands in INP's processing-duration phase, and the browser cannot paint the open menu until the commit finishes ^[8].

The replacement is about 90 lines and it turns on one number: the height of a single row, read from the DOM right after the menu mounts ^[11][12]. The useLayoutEffect that reads it has an empty dependency array, so the measurement happens once per mount, from the first element with role="option", through getBoundingClientRect ^[12]. Everything after that is division on that number: totalHeight = totalCount * itemHeight, and startIdx = Math.max(0, Math.floor(scrollTop / itemHeight) - OVERSCAN) ^[13]. With OVERSCAN set to 5 and about six visible rows, the mounted slice is roughly 16 components instead of 1,175 ^[11][4].

Every index in that calculation descends from one measured height, so the approach holds only while each row renders at exactly that height. A brand name long enough to wrap onto two lines puts the scroll offset and the rendered slice out of step. Subito names the other route, measuring each row one by one, and calls the equal-height assumption "by far the simpler of the two" ^[14].

Two things have to be true for the 96 ms to transfer to another list ^[16]. The window has to show a handful of rows out of a large catalog, and per-row DOM has to stay about as cheap as a label plus a checkbox, because virtualization removes instances, not the cost of each one ^[15]. The measurement condition matters as much: this was a local DevTools reading on a mobile viewport at a 4x CPU slowdown, which Subito describes as a standard way to approximate a mid-tier phone ^[5]. The comparison that makes the before-number legible is the field one, where 1,256 ms sat in the bottom 6% of real-user INP experiences ^[6]. Google's threshold for a good INP is 200 ms, so the reported 96 ms sits under half of it ^[7][6].