如果你喜歡我的文章，希望點贊👍 收藏 📁 評論 💬 三連支持一下，謝謝你，這對我真的很重要！

吐槽時間

不知道從什麼時候開始，前端開始卷一些 “高端知識”，動不動就瀏覽器底層原理，V8 是如何運行的，倒不是説這些沒啥用，只是來勢洶洶好像不懂這些就不能糊頁面一樣。

我工作中和內核團隊與虛擬機團隊也合作過並諮詢過他們這些相關問題，大家的態度也很明確，面對這種千萬行代碼的大型工程項目，他們作為專業人士也不是啥都懂，萬一遇到個真的啥都懂的，人家必然也不會去做前端，這就顯得一些面試官和求職者的八股攻防戰可笑了起來。

那麼如果真的遇到一些場景需要學習相關知識，或者就是單純的個人感興趣想了解一下原理和細節，最好的辦法是什麼呢？很簡單，直接看相關團隊的 Blog 或核心開發人員的 Blog & 演講，這都是除去源碼的第一手消息，水平比那些二道販子不知道高到哪裏去了。

The Cost Of JavaScript

今天的標題是 The Cost Of JavaScript，是作者 Addy Osmani 的系列 Blog 主標題，到今年為止一共寫了 4 篇，從 開發者/內核/框架 等角度探索如何優化 JS 執行成本。

Addy Osmani 何許人也？Google 工作 11 年，Chrome Developer Experience organization（Chrome DX 部門）的技術主管，這個 Title 很夠分量了。

I am the engineering lead for Google Chrome's Developer Experience organization. Our projects include Chrome DevTools, Lighthouse, PageSpeed Insights and Chrome User Experience Report, Aurora and WordPress Performance. We recently shipped User Flows for DevTools and Lighthouse!

— https://addyosmani.com/

不多説了，下面我直接介紹他的這個 Blog 系列大概講了些啥。

2017

Blog 鏈接：https://medium.com/dev-channel/the-cost-of-javascript-84009f5...

這篇文章是 The Cost Of JavaScript 系列的第一篇文章，主要是拋出了一個概念，揭露 JavaScript 在瀏覽器上的 parse + compile + evaluate 成本還是很高的（這部分對於前端開發者來説最直觀的就是 long task），開發者需要關心並優化這個耗時。

這篇 Blog 有個案例非常有意思，就是對比同體積的 JS Script 和 Img 的解析時間。因為體積相同，所以對 network 來説耗時是一樣的，但是一張 jpg 的解析和光柵化時間加起來不到 0.1s，對人眼來説基本上是沒有感知的；但是 JS 代碼的 Parse + Compile + evaluate 時間加起來是 3.5s，幾十倍的差距，對比非常的明顯。

縮小 JS 解析運行成本的方式也很簡單，就是 preload/tree shaking/minify/code split。站在 2023 這個節點看，這些方案現如今都有比較成熟的解決方案了，各個新興或老牌框架也在這些能力上做了相關的探索，我就不展開説了。

2018

Blog 鏈接：https://medium.com/@addyosmani/the-cost-of-javascript-in-2018...

本篇文章可是説是完全面向前端開發者的 JS 優化指南，前半部分都是各種列數據説 JS 多了有多影響用户體驗，後半部分就是介紹了一些 JS 優化手段，在我看來都是被國內抄爛了的一些優化：

• minify/compression/cache
• tree shaking/code split/lazy load/code coverage
• preload/web worker/serive worker
• ......

具體細節看原文吧，不展開説了。

2019

Blog 鏈接：https://v8.dev/blog/cost-of-javascript-2019

這篇文章相對來説會深入一些，從 Blog 發佈網站就能看出，這個是從 內核/V8 的角度做的優化，對前端工程師來説可操作性會小一些，但是對理解原理（比如説看懂各種性能火焰圖）還是有些幫助的，下面我們就走馬觀花的看一下他們做的工作。

1.Script Streaming

第一個優化是 Script Streaming，從功能上翻譯（非直譯）應該叫 “流式加載編譯”。

首先來些前置知識。出於 UI 系統的特性，UI 更新的邏輯都必須在 main thread（UI thread）上執行，也就是 script evaluate，但是前置的 parse + compile 可以多線程並行執行的。所以瀏覽器很早就有一種優化：對於標識了 defer or async 的 script 文件，瀏覽器都可以開啓多線程編譯能力，優化 UI thread 被阻塞的時間。

Chrome 基於這個優化背景，又做了一些優化，那就是流式編譯。最終的效果就是 network streaming 直接對接 streaming parser，效率大大增加。

這個怎麼理解呢，這個就有些像要從屋裏把水接到院裏：

• 一開始就是在屋裏接滿一桶水，然後運到院裏，而且你只有一個桶運水（JS 代碼的 parse + compile + evaluate 都在 UI thread 執行）
• 後來多買了幾個桶，可以一次並行運水（基於多線程能力做 parse + compile，最後統一給 UI thread 消費）
• 一桶一桶的接水，還要搬來搬去，太麻煩了，直接買了幾根長水管，接好直接把水傳到院子裏（Chrome 做的優化，network streaming 直接對接 streaming parser，充分利用 CPU 時間）

最後的實際效果就如下圖，讓後台編譯線程等待時間大大降低，增強性能：

2.JSON Parse

JSON 解析要比 object 快（這個是顯然易見的，JSON 語法要比 object 簡單多了，解析成本要低很多），Google 建議大於 10KB 的 JSON 可以嘗試這種優化：

const data = { foo: 42, bar: 1337 }; // 🐌

const data = JSON.parse('{"foo":42,"bar":1337}'); // 🚀

其實從 Google 建議也可以看出，大部分情況下都沒必要摳搜這部分性能。node 後端場景可能會遇到，前端較大的數據管理庫可能會遇到（比如説很大的一個 redux 狀態對象），其餘場景沒必要因為這點兒性能降低代碼維護性。

3.Code Caching

這部分內容説的是 Chrome 的 Code Caching。它本質上也是 cache 的一種，比如説我們最常接觸到的緩存就是基於 HTTP Cache Head 的網絡資源緩存，即 memory cache 和 disk cache，這兩個緩存的主要是 http response，命中後可以節約網絡請求的耗時。

code caching 從大類上分其實是 disk caching 的一種，但是它緩存的不是 http response，而是 javascript 文件 parse + compile 後的 bytecode，所以如果命中 code caching，network + parse + compile 的時間就全省了，直接 evaluate 就行。

不過 code caching 的命中條件會相對苛刻一些，同一個資源需要前 72h 命中兩次，之後第 3 次請求才會命中 code caching，這部分更詳細的知識建議直接看 V8 對 code caching 的系列 Blog。

2023

YouTube 鏈接：https://www.youtube.com/watch?v=ZKH3DLT4BKw&t=0s

可能因為疫情原因，這個系列的演講中斷了 3 年，不過今年又續上了。

演講前段説的還是一些數據統計，中段説的通用優化，和 2018 的內容差不多。後段介紹了一些這兩年較火的框架和新技術，來我給你報一下菜名：

• Astro/Qwik
• Route & Component Based Code Spliting/Import On Visibility
• Islands Architecture
• Partial Hydration/Progressive Hydration/Resumabilty Hydration/Selective Hydration
• React Server Components
• Streaming Server Rendering

我就問你怕不怕 doge)。這些技術內容總體上都是化整為零，減少瀏覽器端 JS 的 long task。例如最原始的 Hydration 就是全量執行，導致 TTI 高居不下，所以框架層這兩年搞了一堆 Hydration 方案來優化。

這些內容在原視頻裏也就介紹了 10 分鐘，但是想搞懂每個東西的含義，不讀十幾篇相關 Blog 是搞不懂的，大家感興趣的話還是需要自己收集資料瞭解。

Summary

通體看下來，這 4 篇 Blog 料還是挺足的，以這個系列為引進行發散，其實可以收集到不少好東西，對現實開發和眼界提升都是很好的內容。

Web 因為 JavaScript 提升了天花板，但開發者又需提升 UX 去減少 JavaScript 的執行，這一來一回，工作不就來了嘛，所以謝謝 JavaScript 賞飯吃 🙏。

Blog 推薦

本篇文章主要推薦的就是 Addy Osmani 的個人網站 addyosmani.com，有意思的內容很多，大家可以挖掘一下；另一個有意思的內容就是 V8 的 Blog：v8.dev/blog，別看國內那些被嚼了好幾遍的性能優化文章了，直接看一手信息多好。

如果你喜歡我的文章，希望點贊👍 收藏 📁 評論 💬 三連支持一下，謝謝你，這對我真的很重要！