一文了解 Google Chrome 的十年“加速”歷程

自十年前 Chrome 瀏覽器首次推出後，速度已經成為 Chrome 的四個 ofollow,noindex">核心原則 之一。我們一直都想讓 Web 開發者能夠向用戶提供快速的、優秀的上網體驗。在 Chrome 誕生十週年之際，我們認為回顧在這十年中為提高速度所付出的努力，以及我們接下來要進行的嘗試將會是一件非常有趣的事情。

致力於提速的多個瀏覽器元件

V8 是 Chrome 的一個 JavaScript 和 WebAssembly 引擎。隨著網頁使用 JavaScript 指令碼數量的快速增長，一個能夠處理這些 JavaScript 指令碼的高速引擎成為一個非常重要的基礎。這些年，我們為 V8 研發了一個 新的 JavaScript 執行管道(pipeline) ，啟用了 Ignition （一個新的直譯器）和 TurboFan（一個優化的編譯器）。這些舉措使得我們關於速度基準測試方面的效能提升了 5%-10%。 指令碼流(Script streaming) 使得我們在 JavaScript 指令碼開始下載的時候就在一個後臺執行緒中解析這些 JavaScript 指令碼，而這可以將頁面載入速度提高最多 10%。後來加入的 後臺編譯過程 將主執行緒的編譯時間減少了最多 20%。

我們在 Orinoco 專案上的工作啟用了併發的垃圾回收處理，釋放了主執行緒的同時也減少了 jank。久而久之，我們也轉而專注於 實際的 JavaScript 效能 ，此舉幫助我們將 React 的執行時效能 提升了一倍 ，同時也將 Vue，Preact 和 Angular 等庫的效能提高了最多 40%。自最初的 V8 提交上線後，並行的、併發的、增量的垃圾回收減少到了因 jank 引起的垃圾回收的百分之一。我們也實現了 WebAssembly ，允許 開發 者在 Web 上憑藉可以預測的效能來執行非 JavaScript 程式碼，同時啟用了 Liftoff 基線編譯器 來保證 WASM 應用的快速啟動時間。這些新元件都是 近十年 用來提升 V8 效能的最新成果，而由此帶來的效能提升超過了 20 倍。

上圖是近幾年 V8 平臺關於 Chrome 的一系列已發行版本的得分。V8 平臺是舊的 Octane 基準的前身，我們在這張圖表中使用 V8 平臺是因為不同於 Octane，V8 平臺可以執行在所有的 Chrome 版本中，包括最新的測試版本。

Chrome 在藉助 SPDY ,  HTTP/2 和  QUIC 協助發展更新網路協議和傳輸層中也扮演了一個關鍵角色。SPDY 被用來解決 HTTP/1.1 的限制並且成為了 HTTP/2 的基礎，而後者現在已經被所有的現代瀏覽器所支援。與此同時，團隊積極地在旨在更好的改善延遲和使用者體驗的 QUIC 上執行迭代，而在 QUIC 背後，有一個積極的工程任務組(ITEF)在努力。QUIC 的效果在像 YouTube 這樣的 視訊 網站 上是顯而易見的，在藉助 QUIC 觀看視訊時，使用者報告的重新快取率 降低了 30% 。

接下來是 Chrome 的 渲染管道 (rendering pipeline)。這個元件用來確保網頁對使用者的響應同時保證每秒 60 幀的展示。為了以 60fps 的速率展示內容，Chrome 必須 在 16 毫秒內渲染每一幀 。這其中包括了 JavaScript 指令碼的執行、樣式、層疊佈局、繪製和向用戶螢幕推送畫素。在這 16 毫秒內，Chrome 使用的越少，就會留給開發人員更多的時間為使用者帶來更好的體驗效果。我們渲染管道的實現涵蓋了 優化 如何確認頁面上需要重新繪製的元素以及更好地追蹤視覺上不重疊元素的集合。這個過程使得繪製新的幀影象到螢幕的時間縮短了最高 35%。

在 2015 年，Chrome 團隊提出了一種名為 RAIL  的以使用者為中心的效能模型。我們在近期對其 進行了更新 。

關於記憶體消耗，在 Chrome 的 63 到 66 版本之間，渲染器處理的記憶體使用率提升了大概 20% 到 30%。我們希望在站點隔離已經就緒的情況下繼續探索基於 RAIL 的構建途徑。Ignition 和 TurboFan 的使用 減少 了 V8 引擎的整體記憶體佔用，在 V8 支援的所有裝置和平臺上記憶體佔用降低了 5%-10%。今年，有一些調查發現網際網路上 7% 的站點因為記憶體洩漏受到了影響，而這些問題我們已經完全修復。用來提升 Chrome 瀏覽器速度的元件涵蓋了 DOM，CSS 和諸如 IndexedDB 的儲存系統。如果想學習更多的關於我們在效能提升方面的內容，可以持續關注 Chromium 部落格。

賦予 Web 開發者更多測量及優化網頁的能力

瞭解從哪裡開始改進你的網站可能是一個單調乏味的過程。為了提供幫助，我們探索了幾種工具，用於瞭解使用者感受到的 lab 訊號和 真實 體驗。多年來， Chrome DevTools 效能面板成為了一種視覺化的方式，可直觀地瞭解網頁在實驗室環境中如何展示的方法。為了繼續降低衝突以尋找網站的 效能改善的可能性 ，我們隨後致力於  Lighthouse —— 一個分析網站質量的工具，為你提供網站效能的明確度量標準以及改善使用者體驗的具體指南。Lighthouse 可以直接從 DevTools Audits 面板中訪問，從命令列執行，或與其他開發產品（如  WebPageTest ）整合。

執行在 Chrome DevTools Audits 面板中的 Lighthouse

為了補充 Lighthouse 提供的實驗資料，我們釋出了 Chrome 使用者體驗報告 來為開發者提供諸如 首次內容繪製 和 首次輸入延遲 等關於產品使用人群的真實使用者體驗的資料資訊。如今，開發者可以生成他們自己的個性化網站效能報告，同時可以通過  CrUX 儀表盤 關注數百萬來源的處理進度。

我們同時也引入了一些 Web 平臺功能來幫助開發者優化他們的站點載入效能。我們藉助資源提示符 (Resource Hints) 和 <link ref=preload> 可以讓開發者告知瀏覽器哪些關鍵資源是需要儘早載入的。Chrome 是最早實現了支援諸如 應用於壓縮方面的 Brotli 、 小號網頁字型的 WOFF2 和 圖片方面的 WebP 等位元組儲存方案(byte-saving)的瀏覽器之一。

我們很高興看到支援上述特徵的瀏覽器數量越來越多。Chrome 實現了 Service Workers ，棄用了離線快取和網路彈性以用於支援重複訪問網頁。我們也很高興看到該功能已經 被大多數的現代瀏覽器所支援 。

事實上，Google 搜尋已經將 Servier Worker 和導航預載入( navigation preload )應用在了重複搜尋方面的條件快取上。而這使得重複訪問的頁面載入耗時效能提升了兩倍。

放眼未來，我們也對關於原生的圖片和內嵌框架的延遲載入等新興標準、諸如 AV1 這樣的影象格式有助於高效地向用戶提供內容感到興奮。

在你的資料規劃中藉助 Chrome 更好的享受網路

在過去十年，網頁的數量發生了前所未有的增長，但很多使用者是第一次使用網路，上網流量對於他們來說可能花費巨大，或者上網速度非常慢。鑑於此，Chrome 在近些年推出了像 Data saver 這樣的具有資料意識的功能。Data saver 會智慧地優化網頁，節省了最多 92% 的上網流量消耗。

我們也在探索新的可以節省資料的新方法。對那些連線速度最慢的使用者來說，我們已經開發出了 Android 平臺上的 Chrome，可以讓智慧網頁優化器儘早展示必要的內容。這些頁面轉換載入相比於整個頁面載入而言非常快，除此之外，我們也在持續的提高我們的精確性、覆蓋範圍和效能。

我們也在嘗試為資料或者網路受限的使用者提供一些支援和協助。例如，我們向 Chrome 中加入了原生的延遲載入機制，以及為使用者提供在使用大量資料時停止來自頁面的其他請求的選項。

我們才剛剛開始

綜上，這些改變幫助開發者和企業可以儘快地向他們的使用者投放有用的內容。我們知道這仍需要有很多工作要做，在下一個十年我們也將會做出更多關於頁面載入效能的改進和提高。