效能優化故事

最近踩到一個很有趣的坑，值得分享一下。

多數業務場景多半都是遇到 JavaScript 的效能瓶頸比較多，所以多數面試都是考框架效能的優化。但真實讓你遇上很邊緣的問題時，整個尋找問題的流程變得很不容易。

事情是這樣的，工作上有某個 Issue 是這樣說：「當某個頁面打開 devtool 時，畫面會非常卡頓，甚至卡死。」

剛開始我往 debug 功能相關問題尋找，但我怎麼找都找不到相關的問題。甚至無法重現這個問題，我只好先模仿那個生產環境去實現，並且採用「降低 CPU 運算」的方式去測試。

後來我意外發現跟 devtool 一點關係都沒有，只要出發任何 browser resize 都會加重這件事的顯現，只是剛好打開 devtool 觸發了 resize 導致這件事。

但只是 resize 都不夠證明效能瓶頸的原因，這時候只能使用 performance recoding 去錄製效能分析。結果是發現大部分的瓶頸都卡在 Render 這個環節，反而是 JavaScript 部分根本沒什麼瓶頸。

這就怪了，通常會在這塊出現瓶頸都是 DOM 過多，或是渲染計算過於複雜。但我一看，DOM 總數大概在 1500 左右，而經驗上要遇上瓶頸少說也要5000 甚至 10000 以上的 Node 才會有體感。

當然，回到用最老套的方法，「註解大法」。

我一步步縮小這個範圍，結果元兇竟然是⋯⋯

「Textarea」

我真的想不到，Textarea 當渲染過多的「value」時，也會造成巨大的瓶頸。當然，知道問題後，後面就開始一系列的解決方案討論，但真再次刷新我的三觀⋯⋯⋯