從 Framework Cost 到 Rendering Architecture，重新看 Vue 的成本邊界

前面的 D09、D14、D19、D25，分別驗證 Reactive Chain、Component Storm、Composable Chaos 與 VDOM Stress。

到了 Day 29，問題需要收斂成兩個：

1. Vue 3.6 Traditional Runtime 是否真的降低 Framework Cost？
2. 如果 Rendering Architecture 改成 Vapor，成本結構又會怎麼變？

這次將 Final Validation Freeze 在 Vue 3.6.0-rc.9，並重新以相同 Scenario、相同 benchmark、Chrome 153 執行兩次獨立 run，Scenario 與量測 pipeline 均未修改。

先看 Traditional：沒有確認可重現的改善

四個 Scenario 最終證據可以收斂成：

因此目前的結論很明確：

Vue 3.5.40
      ↓
Vue 3.6 Traditional
      ↓
本 Lab 未確認可重現的 Framework Runtime Cost 下降

這裡的關鍵是 reproduced，rc.9 與 rc.4 Traditional 比較，以及 3.5.40 與 rc.9 Traditional 比較，在兩次獨立 run 中都沒有任何 reproduced cell。

單次出現的 Consistent 差異，下一次並未重現或方向相反，所以不能把單次 benchmark 的下降直接寫成 Vue 3.6 的 Framework improvement。

Vapor：差異出現在 Framework / Scripting Cost

切換成 Vapor 在如果主要變因是 Rendering Architecture 的條件下，Framework Cost Structure 會發生什麼變化？

Vue 3.6 Traditional
        │
        │ 相同 Scenario
        │ 相同 Node Count
        │ 相同 Benchmark
        ↓
Vue 3.6 Vapor

VDOM-Stress Scenario 原始碼沒有修改，量測 pipeline 也沿用既有實作；Vapor 只透過 app infrastructure 啟用，完整 session 共執行 640 個 trial，這讓比較的主要變數可以收斂到 Rendering Architecture。

vue({
  features: {
    vapor: true
  }
})

app.use(vaporInteropPlugin)

Mount N=5000

rc.9 兩次 run 都看到相同方向：

• Scripting：−42% / −31%
• Vue Runtime CPU：−67% / −64%
• Rendering：+13% / +14% 等級的變化並未出現於 Mount N=5000
• Render Duration：−27% / −33%

其中 Scripting 是較可靠的主證據；Vue Runtime CPU 屬 attribution bucket，報告本身標示為 low confidence，只適合描述方向。

Update：N=5000 才看到穩定的 Scripting 差異

rc.9 Update 的 Application Timing（Render Duration，ms，中位數，run2 / run3）：

其中 N=1000 的 Render Duration 出現跨 run 的 regression；N=5000 則沒有確認 wall-clock improvement，但 N=5000 的 Scripting Cost 兩次都下降：

Scripting 下降跨兩次 run 重現；Rendering 則約 +13%，且仍屬 Unstable。

這裡真正值得看的，是 Cost Structure

N=5000 Update 數據中可看到兩次獨立跑測試的結果 Scripting Share 都下降，所以可以說 Traditional → Vapor 的架構差異與 Scripting Cost 下降具有穩定關聯。

Scripting 絕對成本下降後，Rendering 與 Painting 在總成本中的比例自然提高，但是這不代表 Browser Rendering 變貴，因為真正發生的是：

Traditional
Framework / Scripting Cost
          ↓
Browser Rendering / Painting

Vapor
較少 Framework / Scripting Cost
          ↓
Browser Rendering / Painting
          ↓
成為更明顯的成本邊界

rc.9 N=5000 Update 的 Scripting + Rendering + Painting，中位數總和兩次分別下降 27.5% 與 19.0%。

Vapor 真正改變的是哪一層？

這次實驗最值得留下的，不是某一個 −30% 或 −40% 的數字，而是 Cost Structure 發生了改變。

在 Traditional Runtime 下，大量 Node 的處理會產生較高的 JavaScript / Framework work。

Vapor 將其中一部分 Framework work 移除後，Browser Rendering、Layout、Painting 仍然存在。

Traditional

Vue / Framework
      │
      ▼
大量 Scripting
      │
      ▼
Browser Rendering
      │
      ▼
Painting

Vapor

Vue / Framework
      │
      ▼
較少 Scripting
      │
      ▼
Browser Rendering
      │
      ▼
Painting

因此 N=5000 Update 的 Scripting Share 從約 66~67% 降到 53~58%，但是 Browser-side Cost 並沒有消失，只是在 Framework Cost 降低後，變成更明顯的成本來源。

Framework Cost 降低，不代表所有時間都會同步下降

這次結果也保留了一個很重要的反例。

rc.9 N=500 Update 的 Render Duration，在兩次 run 中都沒有得到 Vapor 的改善；N=1000 甚至出現跨 run 可重現的上升，同時，N=5000 Update 的 Scripting 卻穩定下降：

這說明效能驗證不能只看 Framework Runtime 指標，即使 Vue Runtime 的工作量下降，最後的 wall-clock time 仍然受到 Browser Rendering、Layout、Painting 以及其他 pipeline cost 影響，所以這次可以確認的是：

Vapor
  ↓
Framework / Scripting Cost ↓
  ↓
Browser Cost 仍存在
  ↓
總時間是否下降？
→ 必須另外測量

這也是為什麼本次報告沒有把所有 Runtime CPU 的下降直接等同於使用者體感時間改善。

把 Vue 3.6 的驗證收乾淨

經過四個 Scenario，以及最後的 rc.9 Final Validation，可以留下三個層次：

• Traditional Runtime

  3.5.40 → 3.6 Traditional ，Lab 沒有確認可重現、可歸因於 Framework Runtime 的改善。

• Vapor

  Traditional → Vapor 在相同 Scenario 下，重跑也可以看到 Scripting Cost 下降；N=5000 Update 的下降約 31~42%。Mount 也呈現一致方向。

• Browser

  Rendering、Layout、Painting 仍然是獨立成本，Framework Cost 降低後，Browser-side work 反而更容易成為下一個需要觀察的成本邊界。

這就是這次 Vue 3.6 Final Validation 最重要的結果：

Vapor 的價值不只是讓某個 benchmark 變快，而是重新分配了 Rendering Pipeline 中 Framework 與 Browser 的成本比例。

至於這個成本結構在實際應用中的收益，仍然取決於 Scenario 本身的 Rendering Work，以及最終瓶頸落在哪一層。

GitHub Repo.

• Day 29 — Final Validation：Vue 3.6.0-rc.9 Traditional vs Vapor（vdom-stress）

參考資料

• 3.6.0-rc.9 (2026-09-18)