Fixed-header tables force one getBoundingClientRect per column on every mount (ResizeObserver-driven MeasureCell)

Body/MeasureCell.js と useResizeObserver.js:20 から始め、次に scroll.y を使う固定ヘッダーのテーブルを再現し、説明されているとおりその cold mount をプロファイルします。完了条件は、列ごとの読み取りが意図的なものかどうかを判断し、観測されたテーブルの動作を変更せずに、より低コストな測定経路を特定または実装することです。

Environment

• @rc-component/table: 1.10.4 (via antd 6.5.3)
• @rc-component/resize-observer: 1.1.2
• Chrome, production build, 4x CPU throttle (DevTools)

What we observed

Any table mounted with a fixed/scrollable header (scroll.y set, i.e. fixHeader true) renders a hidden "measure row" with one MeasureCell per column. Each MeasureCell wraps its cell in a ResizeObserver (Body/MeasureCell.js), and on the initial observe, onInternalResize (useResizeObserver.js:20) calls target.getBoundingClientRect() once per cell.

On a ~40-column table, we measured 86 getBoundingClientRect calls totaling ~547ms of forced-layout self-time on a single cold mount, instrumented by wrapping HTMLElement.prototype.getBoundingClientRect/offsetWidth and measuring with performance.now(). This is currently the dominant forced-layout cost on table mount in our app (a general-purpose ERP list view), well above what column count alone would suggest — the reads don't appear to be batched into a single reflow.

Question / ask

Is per-column ResizeObserver-driven measurement (as opposed to reading all column offsetWidths in one synchronous batch, which the browser can usually satisfy with a single layout pass) intentional, or is there a lower-cost path we're missing (e.g. skipping remeasurement when explicit pixel widths are already provided for every column)? Happy to share a minimal repro or profiling trace if useful.