以前遇到首頁載入慢，我的第一反應其實很單純，前端能做優化的都優化，像是圖片壓縮、改 .webp、減少資源……，做了一輪之後，速度確實有變好，可是沒有想像中那麼多。

這時候剛好看到 Vue 開始往 Compiler Optimization、Vapor Mode、Reactivity 等方向演進，因為數據太吸引，所以去年花了不少時間研究 VueConf 2025 尤雨溪分享的內容。

當時想的是等新版本出來，也許就能直接解決這些問題，只是等到後來沒有發布 Vue3.6 正式版，就會開始想很多，想著想著就開始問自己一個的問題：

Vue 新功能真的會改善我遇到的問題嗎？

開始對「Performance Improved」這句話產生疑問

Release Notes 裡看到：Performance Improved、Reactivity Enhancement、Compiler Optimization，關鍵字很吸睛，但是對老闆提出想法，他們真正想知道的其實不是這些，身為商人，真正想知道的是產品的畫面真的會變快嗎？提升多少體驗帶來多少商機？

這個問題在去年 9 月也確實被公司前輩提問，專案框架升級不是問題，問題是效益是什麼？去年嘗試看數據確實漂亮，也在想如果套在公司專案也會加快編譯提升效能嗎？一個 Vue 專案的瓶頸，會不會根本不在 Vue 框架？

這個問題的答案好多，可能是：

• 大量資料更新
• Component 層級過深
• Reactive Chain 太長
• 第三方套件
• Browser Layout / Paint
• API 或網路

所以 Framework 有改善 ≠ 我的專案一定有改善，這也是我今年想換一個角度看 Vue 的原因。

從「學 Vue」變成「驗證 Vue」

以前學 Framework，三不五時追一下最近新增了什麼 API？新版本有什麼功能？官方推薦什麼寫法？

每每看到新東西都會想這個技術能不能解決畫面一直 Render？小改竟然會牽動這麼多 Component？好想升級版本，但是升了就可以一勞永逸？

好想解決這些問題，但是只靠 Release Notes 沒辦法說服我的前端夥伴們，讓我升級！所以今年，我想做的事情其實很簡單：不要先相信結論，先建立可以驗證的情境。

從真實開發痛點開始：

Pain Point → Scenario → Measurement → Compare → Conclusion

再拿 Vue 3.5 與 Vue 3.6 做比較。

今年不只是看「Vue 做了什麼」

這次的實驗，跟 AI 討論後刻意把問題拆成兩層。

1. Framework 到底改善了什麼？

例如：

Reactive → Component → Rendering → Compiler → Runtime

先確認 Vue 本身是否真的產生可重現的改善。

2. 那我的專案為什麼還是慢？

如果 Vue 沒有改善，問題可能就在 Architecture。

例如：

State → Composable → Component → DOM → Browser

如果結果出來不是單純「換版本」就能高枕無憂，那就要思考「換設計」，所以才會想要做到分清楚：哪些問題是 Framework 可以解決的，哪些問題其實應該由工程架構解決。

Vibe Coding 時代這個問題變得更重要

以前一個工程師一天可能寫幾個 Component，現在 AI 可以很快幫我們生成 10 個、20 個，甚至更多。

速度變快了，但另一個問題也出現了，如果 AI 不斷生成：

• 重複 Component
• 過度拆分的 Composable
• 不合理的 Reactive Chain
• 不必要的 Render
• 沒有邊界的 Design System

那麼 AI 提高的是 Code Generation 速度，卻不一定提高 Application 的品質。 所以這次研究到最後，不只想知道 Vue 3.6 有沒有比較快？ 我更想知道 AI 幫我們寫更多 Vue 之後，工程師到底還需要負責什麼？

所以這 30 天，我想做的不是「介紹 Vue 3.6」

而是一個小型的 Vue Runtime Research Lab，每個 Scenario 都從過去真實經歷開始：

這裡最重要的不是跑出一個漂亮的 Benchmark 就開始歡呼，也有可能結果出乎意料之外，所以這次換追到底是哪一層變快了？

這也是今年想重新理解 Vue 的方式

去年，我花很多時間理解 Vue 為什麼這樣設計？

今年，我想繼續往下一步 Vue 的演進，真的改善了什麼？ 甚至最後還要再問一次 這個改善，對我的專案有沒有意義？

所以接下來 30 天，我們會從 Reactive、Component、Rendering、Composable，一路走到 Vapor 與 AI Coding。

過程中不預設答案，也不要因為 Release Notes 寫了 Performance Improved，就直接相信它，所有結果都 讓 Scenario、Measurement 和 Evidence 自己說話。

一直以來我很相信專業，所以 Vue 變快甚至效能改善都可預期，但是改善歸改善，萬一專案升級後發現效能不如預期，再來質疑當初的決定，這種邏輯很怪！

所以 30 天之後，我們一起看我的痛點驗證新版本改善的是哪一層？我的瓶頸剛好在這一層嗎？如果不是，我真正該改的是什麼？

這才是我今年真正想研究的：

不是 Vue 多了什麼能力，而是我們能不能更準確地知道，什麼問題應該交給 Vue，什麼問題應該由自己解決。