那既然 Framework Improvement 沒有被確認，目前真正存在的成本結構是什麼？

Day 19 比較了 Vue 3.5.40 與 Vue 3.6.0-rc.2，這一輪沒有找到符合驗證標準、可以確認的 Framework-level Improvement。

這個結果留下了一個更實際的問題：如果升級 Vue 並沒有確認降低這個 Scenario 的主要成本，那這些時間到底花在哪裡？

所以今天先不看版本差異，回到同一份實驗資料，拆開 Mount 與 Update 的 Cost Structure。

先看 Mount：Node 越多，Browser Rendering 的比例越高

Vue 3.5.40 的 Mount 資料可以看到一個很明顯的變化，隨著 Node Count 從 100 增加到 5000：

• Scripting 大致維持在 28–33%
• Rendering 從 50.2% 增加到 67.9%
• Painting 的相對比例則逐漸下降

再往 Rendering 裡面拆，Layout 一直佔主要比例。

因此 Mount 的成本結構可以簡化成：

Node Count 增加 → DOM 規模增加 → Browser 需要處理更多 Layout 工作

這也和前一天 Baseline 觀察到的結果一致。

Mount 的主要問題並不是單純「Vue 執行更多 JavaScript」，而是 UI 規模增加後，瀏覽器本身需要處理的 Rendering 工作也跟著增加。

Update 的結構完全不同

同一份資料放到 Update，就會看到另一種形狀。

這裡最值得注意的是 Scripting 在 N=100 時，Scripting 約佔 43%；到了 N=5000，已經上升到 80.9%。

相反地，Painting 從小規模時的 30–38%，逐漸下降到 N=5000 的 7.3%。

這代表 Update 隨著 Node Count 增加，成本結構逐漸從 Browser Painting 佔有一定比重

轉向 JavaScript Scripting 成為主要成本

在這個 Scenario 中，Update 每次都會重新建立資料並觸發更新，因此當 Node Count 很大時，JavaScript 端需要處理的工作成長速度開始超過 Browser Rendering。

Mount 與 Update，其實是兩種不同的成本問題

把兩組資料放在一起，就會看到很清楚的差異：

所以「大量 UI 很慢」其實沒有單一答案，同樣是增加 Node：

• Mount 更容易把成本推向 Browser Rendering / Layout
• Update 則逐漸把成本推向 JavaScript / Scripting

這也是為什麼只看一個 Render Duration 數字，很難知道真正的瓶頸在哪裡，所以需要把一次 UI 操作拆成不同 Cost：

Render Duration
       │
       ├── Scripting
       │
       ├── Recalculate Style
       │
       ├── Layout
       │
       ├── Painting
       │
       └── Paint

這次實驗的價值就在這裡：我們可以看到「慢」發生在哪個階段，而不是只知道最後花了多少毫秒。

那 Vue 3.6 呢？

Day 19 已經完成版本比較，這一輪沒有任何 Cell 同時符合：

• IQR 不重疊
• ≥9/10 paired trials 同方向
• 沒有已知 measurement artifact 可以解釋

因此沒有足夠證據確認 Vue 3.6 在這個 Scenario 中穩定降低了某一層的成本，這個結果和今天的 Cost Structure 並不衝突，因為一個 UI 操作的成本本來就跨越多個層次：

Vue / JavaScript
       │
       ▼
DOM changes
       │
       ▼
Browser Rendering
       │
       ├── Style
       ├── Layout
       └── Paint

Framework 即使降低其中一段工作的成本，也不代表整個 UI 操作就一定會出現同等幅度的改善，而這次實驗裡，我們甚至沒有找到足以通過驗證門檻的 Framework-level Improvement，因此目前能確定的事情，反而是 Cost Structure 本身。

這次實驗真正量到的是什麼？

可以把目前的結果可以整理成在這個 VDOM Stress Test 中：

• Mount

  Node Count 增加後，Rendering 佔比上升，Layout 成為主要成本。

• Update

  Node Count 增加後，Scripting 佔比快速上升，最終成為主要成本。

而 Vue 3.5.40 與 Vue 3.6.0-rc.2 的比較，目前沒有確認 Framework 升級能改變這個結構。

小結

這次 VDOM Stress Test 沒有證明 Vue 3.6 在這個 Scenario 中有可重現的 Framework-level Improvement，但它讓成本結構變得更清楚：

Mount 的大規模成本逐漸由 Rendering / Layout 主導；

Update 則逐漸由 Scripting 主導。

因此「大量 UI Rendering 很慢」不能只用一個 Runtime Cost 解釋，真正需要先確認的是：目前正在做哪些工作，以及這些工作有多少其實可以避免。

這也會成為下一個問題的起點：

如果 AI Coding 參與了 UI 的產生，它會不會把原本可以避免的 Rendering 工作也一起寫進去？