如果換成 Vue 3.6，昨天看到的這些成本，真的會消失嗎？

昨天用 Vue 3.5.40 建立了 Component Storm 的 baseline，在 componentCount=500、updateScope=AllChildren 的條件下，一次 Update 需要處理 500 個 Child Component。

結果是：

如果只看這個數字，很直覺 Vue 3.6 變快了，但這個結論其實還少了一個關鍵問題：

少掉的這 28.7 ms，到底是 Vue Runtime 少做了工作，還是其他成本發生了變化？

所以今天不改 Component Storm Scenario，只換 Vue 3.5.40 → Vue 3.6.0-rc.2，然後把一次 Update 的成本往下拆。

先看昨天留下來的結果

三種 Update Scope 的原始測量如下：

其中最值得追的是 AllChildren，因為它一次 Update 的成本最高，也最容易看出 Component Storm 的影響，所以今天的 CDP Validation 只追這個 Scope：

componentCount = 500
updateScope    = AllChildren

ParentOnly 和 SingleChild 沒有再跑，避免為了擴充實驗矩陣去修改 Scenario Freeze Rule 所保護的設定。

但「總時間變少」還不能代表 Vue 變快

一次 UI Update 並不是只有 Vue Runtime，可以先把它簡化成：

Update
  │
  ├── Application JavaScript
  │
  ├── Vue Runtime
  │
  └── Browser
       ├── Rendering
       ├── Style
       ├── Layout
       └── Paint

因此 Update Duration ↓，只能說 這一次操作的總時間變少了，還不能直接說 Vue Runtime CPU ↓，這也是今天加入 CDP Attribution 的原因。

這次使用兩種 Trace：

• cost-trace：觀察 Scripting、Rendering、Painting、Layout 等成本
• runtime-attribution-trace：進一步把 CPU samples 分成 Vue Runtime、Application、DevTools Overlay、V8/native

兩種 Trace 分工不同，不能用同一份 Trace 同時完成兩種成本分析。

第一次 CDP Validation：結果反而變慢了

原本以為會重現一開始的紀錄表，187.4 → 158.7 ms 優化 -15.3%，但 CDP Validation 得到：

而且 Signal = Unstable，10 次測量中，只有 4 次配對結果由 Vue 3.6 勝出！

這時候有兩個容易走向的錯誤結論：

原本 -15.3%
        ↓
現在 +8.5%
        ↓
Vue 3.6 變慢了？

其實不能這樣判斷，因為這兩組數據根本不是同一個 measurement environment。

原來我們測量的是兩種不同的 Browser State

昨天的 187.405 → 158.669 ms，來自 claude-in-chrome，測試過程中，頁面一直處於 document.hidden === true ，也就是 Background / Hidden Tab。

而這次 CDP Matrix 使用的是：

獨立的 headless Chrome，測量頁面是唯一的 Tab。

因此它處於另一種 visibility condition！

兩套結果：

所以目前不能把這兩組數字放在同一條 Benchmark 線上比較。

那就只改一個變數：document.hidden

接下來做了一個獨立的 Visibility Diagnostic，Scenario 不改，只控制 document.hidden 後測量兩個條件：

Visible
document.hidden === false

vs.

Hidden
document.hidden === true

兩個 Vue 版本各測 10 次，結果非常有意思：

這裡就可以解釋為什麼原本的 −15.3% 看起來那麼漂亮。

Hidden 的結果，確實接近原始 -15.3%

原始測量：

連絕對時間量級與改善方向都相當接近。Report 因此將 document.hidden 判定為造成兩套 harness 差異的主要變數，但這裡還不能得到：

Vue 3.6 在 Background Tab 快 20.8%。

因為 Hidden 的結果本身仍然是 Unstable。

Vue 3.5.40 自己的 10 次測量就從 129.5 ms 一路波動到 406.3 ms，同一個 Vue 版本、同一個 Scenario，單次測量就可以出現超過 3 倍的差距。

所以這裡真正能確定的是：

Hidden Tab 會大幅改變這個 Scenario 的測量行為。

至於 Hidden condition 下 Vue 3.6 是否真的存在額外的改善，目前還需要更多樣本才能回答。

回到最重要的問題：Vue Runtime 有變快嗎？

這才是今天最直接的 Framework Attribution 問題，CDP Attribution 得到：

Vue Runtime CPU 70.1 ms → 73.4 ms，反而是 +4.7%，但這個結果同樣不能解讀成 Vue 3.6 變慢 4.7%。

因為：

• IQR 有重疊
• 只有 4/10 paired trials favor 3.6
• Signal = Unstable
• Attribution confidence = low

所以正確說法是：

目前沒有觀察到 Vue Runtime CPU 的可重現下降。

Report 也明確指出，sample attribution 可以結構上區分 Vue bundle 與 Application code，但目前的 leaf-frame attribution 仍是 low confidence，而且 profiler overhead 會污染 V8/native bucket。

這也是為什麼 V8/native +60.1% 不能直接解讀

完整表裡有一個很醒目的數字：

V8/native CPU

258.8 ms
    ↓
414.2 ms

+60.1%

而且 10/10 次都沒有由 Vue 3.6 勝出，但這一列的 Confidence 是 Unavailable，原因是它是一個高度異質的 catch-all bucket，同時包含 profiler overhead 與無法可靠 attribution 的 native calls。

所以 不能把 +60.1% 解讀成瀏覽器或 V8 真的退步 60.1%。

Report 已經把這個 bucket 明確排除在可解釋的 Framework regression 證據之外。

最後，所有 Cost 放在一起看

這張 CDP summary 最值得看的，其實不是哪個數字最大，而是：

有沒有任何一層形成穩定的改善訊號？

沒有任何一項成本或歸因指標達到「持續改善」的水平，唯一得到乾淨 Signal 的 Paint，結論也是：

Stable / No Meaningful Difference

而不是 Improvement。

所以，Vue 3.6 到底有沒有變快？

這次實驗最後得到的結論是 Insufficient Evidence，原因有三個：

1. 原始 −15.3% 沒有在相同 harness 下重現

   原始 Scenario 曾經得到 Update Time 187.405 → 158.669 ms，差異 -15.3%，但後續 Validation 發現，原始測試與 CDP Matrix 使用了不同的 Browser visibility condition。

2. Foreground 條件下兩個版本沒有形成可重現的版本差異

   在乾淨的 Visible / Foreground 條件下 Update Time 35.0 → 35.9 ms，差異 +2.4%，被判定為 Stable / No Meaningful Difference。

3. Vue Runtime CPU 沒有出現穩定下降，其他可以解釋總體差異的 Cost 也沒有形成 Consistent Improvement

   Vue3.5.40 的 70.1 ms 到 Vue 3.6.0-rc2 73.4 ms，差異 +4.7% 而且 Signal = Unstable。

因此這次 Validation 不能將 Component Storm 的改善歸因給 Vue 3.6 Framework Runtime。

GitHub Repo.

• Component Storm CDP record - Runtime Attribution（componentCount=500, updateScope=AllChildren）
• Component Storm record