在 Google I/O 2018 大會上，我們介紹了一系列工具、程式庫和最佳化技術，可讓您更輕鬆地提升網頁效能。我們將使用 The Oodles Theater 應用程式來說明這些概念，並討論預測載入和全新 Guess.js 計畫的實驗。
過去一年來，我們一直忙著研究如何加快網路速度並提升效能。因此，我們開發了新的工具、方法和程式庫，並希望在本文中與您分享。在第一部分，我們將介紹開發 Oodles Theater 應用程式時實際使用的最佳化技術。在第二部分，我們將討論預測載入和新 Guess.js 計畫的實驗。
效能需求
網際網路的負載量逐年增加。如果查看網路狀態，會發現行動裝置上的中位數網頁大小約為 1.5 MB，其中大部分是 JavaScript 和圖片。
網站規模日益擴大，加上網路延遲、CPU 限制、轉譯阻斷模式或多餘的第三方程式碼等其他因素，導致效能問題變得更加複雜。
大多數使用者認為，速度是使用者體驗中最重要的一環。這並不令人意外，因為在網頁載入完成前，您無法執行太多操作。你無法從頁面中獲得價值，也無法欣賞其美感。
我們知道效能對使用者來說很重要，但要找出從何處著手最佳化，可能就像是個秘密。幸好，有許多工具可以幫上忙。
Lighthouse - 效能工作流程的基礎
Lighthouse 是 Chrome 開發人員工具的一部分，可讓您稽核網站，並提供改善網站的提示。
我們最近推出了一系列新的效能稽核，在日常開發工作流程中非常實用。
我們來看看如何透過實際範例運用這些功能：Oodles Theater 應用程式。這是一個示範網頁應用程式，您可以在其中試用一些我們最愛的互動式 Google Doodle，甚至玩一兩款遊戲。
在建構應用程式時，我們希望確保應用程式能發揮最佳效能。最佳化作業的起點是 Lighthouse 報表。
Lighthouse 報表顯示，應用程式的初始效能相當糟糕。在 3G 網路上，使用者必須等待 15 秒，才能看到畫面首次有效顯示所需時間，或與應用程式互動。Lighthouse 標出了網站的大量問題，整體效能分數 23 也反映了這一點。
網頁權重約為 3.4 MB，我們迫切需要精簡。
這開啟了我們的第一個效能挑戰：找出可以輕鬆移除，且不會影響整體體驗的項目。
成效最佳化商機
移除不必要的資源
有些明顯可以安全移除的項目：空白字元和註解。
Lighthouse 會在未縮減 CSS 和 JavaScript 稽核中醒目顯示這個改善機會。我們使用 webpack 進行建構程序，因此只要使用 Uglify JS 外掛程式即可壓縮。
壓縮是常見的工作，因此無論您使用哪種建構程序，都應該能找到現成的解決方案。
另一個實用的稽核項目是「啟用文字壓縮」。沒有理由傳送未壓縮的檔案，而且大多數 CDN 現在都支援這項功能。
我們使用 Firebase 託管來託管程式碼，而 Firebase 預設會啟用 gzip，因此只要將程式碼託管在合理的 CDN 上，就能免費享有這項功能。
雖然 gzip 是非常熱門的壓縮方式，但 Zopfli 和 Brotli 等其他機制也越來越受歡迎。Brotli 支援大多數瀏覽器，您可以使用二進位檔預先壓縮素材資源，再傳送至伺服器。
使用高效率的快取政策
接下來，我們必須確保不會在不必要的情況下重複傳送資源。
Lighthouse 的「快取政策效率不彰」稽核功能，讓我們注意到可以最佳化快取策略，以達到這個目標。在伺服器中設定 max-age 到期標頭，確保使用者再次造訪時，可以重複使用先前下載的資源。
理想情況下，您應盡可能安全地快取最多資源，並盡可能延長快取時間，同時提供驗證符記，以便有效率地重新驗證已更新的資源。
移除用不到的程式碼
到目前為止，我們已移除不必要下載內容中顯而易見的部分，但較不明顯的部分呢？例如未使用的程式碼。
有時我們會在應用程式中加入不必要的程式碼。如果應用程式開發時間較長，團隊或依附元件有所變更，有時就會留下孤立程式庫。這正是我們遇到的情況。
一開始，我們使用 Material Components 程式庫快速製作應用程式原型。 後來，我們改用更自訂的外觀和風格，完全忘記了那個程式庫。 幸好，程式碼涵蓋率檢查功能協助我們在套件中重新找到這項功能。
您可以在開發人員工具中查看程式碼涵蓋率統計資料，包括應用程式的執行階段和載入時間。您可以在下方螢幕截圖中看到兩條紅色大條紋 - 我們有超過 95% 的 CSS 未使用，以及大量 JavaScript。
Lighthouse 也在未使用的 CSS 規則稽核中發現這個問題。結果顯示，這項操作可能省下超過 400 KB。因此，我們回到程式碼，移除了該程式庫的 JavaScript 和 CSS 部分。
這讓我們的 CSS 套件縮減了 20 倍，對於只有兩行長的微小修訂版本來說，效果相當不錯。
當然，這也提升了效能分數，Time to Interactive 也大幅改善。
不過，面對這類異動，光是查看指標和分數還不夠。 移除實際程式碼一律有風險，因此請務必留意潛在迴歸。
我們的程式碼有 95% 未使用，但仍有 5% 存在於某處。顯然，我們其中一個元件仍在使用該程式庫的樣式，也就是 Doodle 滑桿中的小箭頭。不過，由於這個專案很小，我們可以直接手動將這些樣式重新加入按鈕。
因此，如果您要移除程式碼，請務必建立適當的測試工作流程，防範潛在的視覺迴歸。
避免龐大的網路酬載
我們知道大型資源會降低網頁載入速度。這可能會讓使用者花費金錢，並對他們的數據方案造成重大影響，因此請務必留意這一點。
Lighthouse 透過龐大的網路酬載稽核，偵測到部分網路酬載有問題。
我們發現傳送的程式碼超過 3 MB，這相當多，尤其是在行動裝置上。
在清單最上方，Lighthouse 醒目顯示我們有一個 JavaScript 供應商套件，其中包含 2 MB 的未壓縮程式碼。webpack 也強調了這個問題。
俗話說，最快的請求就是不發出請求。
理想情況下，您應該評估提供給使用者的每項素材資源的價值、評估這些素材資源的成效，並決定是否值得在初始體驗中實際提供。因為有時這些素材資源可以延遲或延遲載入，或在閒置時間處理。
在我們的案例中，由於要處理大量 JavaScript 組合，我們很幸運，因為 JavaScript 社群有豐富的 JavaScript 組合稽核工具。
我們一開始使用 webpack bundle analyzer，發現我們包含了一個名為 unicode 的依附元件，其中包含 1.6 MB 的剖析 JavaScript，數量相當多。
接著，我們前往編輯器，並使用 Visual Code 的 Import Cost 外掛程式，以視覺化方式呈現匯入的每個模組成本。這樣一來，我們就能找出哪個元件包含參照這個模組的程式碼。
接著，我們改用另一項工具 BundlePhobia。這項工具可讓您輸入任何 NPM 套件的名稱，並實際查看其壓縮和 gzip 壓縮後的大小預估值。我們找到一個不錯的替代方案，可以取代我們使用的 slug 模組，而且只有 2.2 KB，因此我們改用這個模組。
這對我們的成效有很大的影響。除了這項變更，我們也發現其他縮減 JavaScript 套件大小的機會，因此節省了 2.1 MB 的程式碼。
如果考量到這些套件經過 gzip 壓縮和縮減的大小，整體成效提升了 65%。我們發現，這項程序確實值得執行。
因此，一般來說，請盡量避免在網站和應用程式中進行不必要的下載。列出素材資源清單並評估其成效影響，可以帶來很大的差異，因此請務必定期稽核素材資源。
透過程式碼分割縮短 JavaScript 啟動時間
雖然大型網路酬載對應用程式有很大的影響，但還有另一個因素會造成很大的影響，那就是 JavaScript。
JavaScript 是最昂貴的資源。在行動裝置上，如果傳送大型 JavaScript 組合，可能會延遲使用者與使用者介面元件互動的時間。這表示他們可能會輕觸 UI，但實際上不會發生任何有意義的事情。因此，我們必須瞭解 JavaScript 成本高昂的原因。
瀏覽器就是這樣處理 JavaScript。
首先，我們必須下載該指令碼，然後 JavaScript 引擎需要剖析該程式碼，並進行編譯和執行。
在桌上型電腦、筆電或高階手機等高階裝置上，這些階段不會花費太多時間。但在中階手機上，這項程序可能需要五到十倍的時間。這會延遲互動性，因此我們必須盡量縮短這段時間。
為協助您找出應用程式的這類問題，我們在 Lighthouse 中推出了新的 JavaScript 啟動時間稽核。
以 Oodle 應用程式為例，我們發現 JavaScript 啟動時間為 1.8 秒。這是因為我們將所有路徑和元件，靜態匯入至單一 JavaScript 組合。
其中一種解決方法是使用程式碼分割。
程式碼分割的概念是，與其一次提供使用者一整份 JavaScript，不如在他們需要時，一次只提供一小部分。
程式碼分割可套用至路徑層級或元件層級。可與 React 和 React Loadable、Vue.js、Angular、Polymer、Preact 和多個其他程式庫搭配使用。
我們在應用程式中加入程式碼分割功能，從靜態匯入切換為動態匯入，以便視需要以非同步方式延遲載入程式碼。
這項做法不僅縮減了套件大小，也縮短了 JavaScript 啟動時間。縮短至 0.78 秒，應用程式速度提升 56%。
一般來說，如果您要建構大量使用 JavaScript 的體驗，請務必只將使用者需要的程式碼傳送給他們。
善用程式碼分割等概念、探索 tree shaking (移除沒用到的程式碼) 等想法，並查看 webpack-libs-optimizations 存放區，瞭解如何在使用 webpack 時縮減程式庫大小。
最佳化圖片
在 Oodle 應用程式中，我們使用大量圖片。可惜的是，Lighthouse 對這項功能的熱情遠不如我們。事實上，我們在所有三項與圖片相關的稽核中都失敗了。
我們忘了最佳化圖片，沒有正確調整圖片大小，而且使用其他圖片格式也能帶來一些好處。
我們首先著手最佳化圖片。
如要進行一次性最佳化，可以使用 ImageOptim 或 XNConvert 等視覺工具。
更自動化的方法是在建構程序中加入圖片最佳化步驟，並使用 imagemin 等程式庫。
這樣一來，日後新增的圖片就會自動最佳化。 部分 CDN (例如 Akamai) 或第三方解決方案 (例如 Cloudinary、Fastly 或 Uploadcare) 提供全方位的圖片最佳化解決方案，因此您也可以直接在這些服務上託管圖片。
如果因為成本或延遲問題而不想這麼做，Thumbor 或 Imageflow 等專案提供自行託管的替代方案。
我們的背景 PNG 在 webpack 中被標記為大型，這很合理。在將其正確調整為可視區域大小並透過 ImageOptim 執行後，我們將其縮小到 100kb，這是可以接受的。
我們對網站上的多張圖片重複執行這項操作，大幅降低了整體網頁權重。
為動畫內容選用合適的格式
GIF 的費用可能非常高。令人驚訝的是，GIF 格式最初並非用於動畫平台。因此，改用更合適的影片格式可大幅縮減檔案大小。
在 Oodle 應用程式中，我們在首頁使用 GIF 做為簡介序列。根據 Lighthouse 的資料，改用更有效率的影片格式，可節省超過 7 MB。我們的短片約 7.3 MB，對任何合理的網站來說都太大了，因此我們將其轉換為具有兩個來源檔案的影片元素 - mp4 和 WebM，以支援更廣泛的瀏覽器。
我們使用 FFmpeg 工具將 GIF 動畫轉換為 mp4 檔案。WebM 格式可節省更多空間，ImageOptim API 可為您執行這類轉換。
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
這項轉換讓我們成功減少了 80% 以上的整體重量。這讓大小降到約 1 MB。
不過，1 MB 的資源仍相當龐大，尤其是在頻寬受限的情況下。幸好，我們可以使用 Effective Type API 偵測到他們使用的是低頻寬網路，並改為提供更小的 JPEG。
這個介面會使用有效的封包往返時間和下載值，估算使用者使用的網路類型。它只會傳回字串、慢速 2G、2G、3G 或 4G。因此，如果使用者使用的網路低於 4G，我們就可以根據這個值，將影片元素替換成圖片。
if (navigator.connection.effectiveType) { ... }
雖然這會稍微影響體驗，但至少網站在連線速度緩慢時仍可使用。
延遲載入畫面外的圖片
輪轉介面、滑桿或超長網頁通常會載入圖片，即使使用者無法立即在網頁上看到這些圖片。
Lighthouse 會在螢幕外圖片稽核中標記這項行為，您也可以在開發人員工具的網路面板中自行查看。如果發現有大量圖片傳入，但網頁上只顯示少數幾張，建議考慮改用延遲載入。
瀏覽器尚未原生支援延遲載入，因此我們必須使用 JavaScript 新增這項功能。我們使用 Lazysizes 程式庫，為 Oodle 封面新增延遲載入行為。
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
Lazysizes 相當聰明，不僅會追蹤元素的可見度變化，還會主動預先擷取接近檢視畫面的元素，提供最佳使用者體驗。此外，您也可以選擇整合 IntersectionObserver，以便有效率地查詢可見度。
這項異動生效後，系統會隨選擷取圖片。如要深入瞭解這個主題，請參閱 images.guide，這是一項非常實用且全面的資源。
協助瀏覽器提早提供重要資源
並非所有傳送至瀏覽器的位元組都具有相同的重要性，瀏覽器也知道這一點。許多瀏覽器都有啟發式演算法，可決定應先擷取哪些內容。因此有時會先擷取 CSS，再擷取圖片或指令碼。
我們身為網頁作者，可以告知瀏覽器哪些內容對我們來說真正重要，這會很有幫助。幸好，過去幾年來，瀏覽器供應商已新增多項功能來協助我們，例如 link rel=preconnect、preload 或 prefetch 等資源提示。
這些功能導入網路平台後，可協助瀏覽器在適當時間擷取正確內容，而且比使用指令碼執行的部分自訂載入、邏輯式方法更有效率。
接著來看看 Lighthouse 如何引導我們有效使用其中幾項功能。
Lighthouse 建議的第一件事，是避免多次往返任何來源，以免耗費大量資源。
以 Oodle 應用程式為例，我們大量使用 Google Fonts。每當您將 Google Fonts 樣式表放入網頁時，系統會連結最多兩個子網域。Lighthouse 告訴我們，如果能預先連線，初始連線時間最多可縮短 300 毫秒。
利用 link rel preconnect，我們就能有效掩蓋連線延遲。
尤其是像 Google Fonts 這樣，字體 CSS 託管在 googleapis.com，字型資源託管在 Gstatic，這可能會產生很大的影響。因此，我們套用這項最佳化設定，並縮短了幾百毫秒。
Lighthouse 建議的下一個做法是預先載入重要要求。
<link rel=preload> 非常強大，可通知瀏覽器目前導覽需要資源，並嘗試讓瀏覽器盡快擷取資源。
Lighthouse 建議我們預先載入重要的網頁字型資源，因為我們載入了兩種網頁字型。
預先載入網頁字型時，您需要指定 rel=preload，並傳入 as 和字型類型，然後指定要載入的字型類型，例如 woff2。
這對網頁的影響相當明顯。
一般來說，如果不使用 link rel preload，且網頁字型對網頁至關重要，瀏覽器就必須先擷取 HTML、剖析 CSS，然後在稍後的某個時間點擷取網頁字型。
使用 link rel preload，瀏覽器剖析 HTML 後，就能提早開始擷取這些網頁字型。以我們的應用程式為例，這項做法可將使用網頁字型轉譯文字的時間縮短一秒。
不過，如果想使用 Google Fonts 預先載入字型，就沒那麼簡單了，
我們在樣式表中的字型臉上指定的 Google Fonts 網址，剛好是字型團隊相當定期更新的內容。這些網址可能會過期或定期更新，因此，如果您想完全掌控字型載入體驗，建議您自行託管網頁字型。這項功能非常實用，可讓您存取 link rel preload 等項目。
在我們的案例中，我們發現 Google Web Fonts Helper 工具非常實用，可協助我們離線處理部分網頁字型，並在本機設定這些字型，因此請查看該工具。
無論是使用網頁字型做為重要資源，還是使用 JavaScript，請盡可能協助瀏覽器盡快提供重要資源。
實驗功能：優先順序提示
今天我們要與你分享一項特別消息。除了資源提示和預先載入等功能外，我們也正在開發一項全新的實驗性瀏覽器功能，稱為「優先順序提示」。
這項新功能可讓您向瀏覽器提示資源的重要性。它會公開新的屬性 - importance - 具有低、高或自動的值。
這樣一來，我們就能降低較不重要資源的優先順序，例如非關鍵樣式、圖片或擷取 API 呼叫，以減少爭用。我們也可以提高重要內容的優先順序，例如主頁橫幅。
以 Oodle 應用程式為例，這實際上讓我們找到一個可以最佳化的實際位置。
在我們為圖片加入延遲載入功能之前，瀏覽器會先擷取圖片輪轉介面中的所有塗鴉，並在輪轉介面一開始就以高優先順序擷取所有圖片。可惜的是，對使用者來說，輪轉介面中間的圖片最重要。因此，我們將這些背景圖片的重要性設為極低，前景圖片設為極高，這樣一來，在慢速 3G 網路下，我們擷取及算繪這些圖片的速度就能提升兩秒。因此，這是一次良好的體驗。
我們希望在幾週內將這項功能導入 Canary，敬請密切關注。
制定網頁字型載入策略
字體排版是良好設計的基礎，如果使用網頁字型，最好不要封鎖文字算繪，也絕對不要顯示隱藏文字。
我們現在會在 Lighthouse 中醒目顯示這項資訊，並提供避免在載入網頁字型時顯示隱形文字稽核。
如果使用字型樣式區塊載入網頁字型，瀏覽器會自行決定在擷取網頁字型耗時過長時該如何處理。部分瀏覽器最多會等待三秒，然後才改用系統字型，並在下載完成後切換至該字型。
我們希望避免這種隱藏文字，因此在這種情況下，如果網頁字型載入時間過長，我們就無法看到本週的經典塗鴉。幸好，有了名為 font-display 的新功能，您就能進一步控管這項程序。
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
字型顯示可協助您根據網頁字型切換所需的時間，決定網頁字型的轉譯或備用方式。
在本例中，我們使用字型顯示交換。Swap 會將字型樣式的封鎖期設為零秒，並將交換期設為無限。這表示如果字型需要一段時間才能載入，瀏覽器會立即使用備用字型繪製文字。並在字型可用時進行替換。
以我們的應用程式來說，這項功能的好處在於，我們可以在很早的階段就顯示一些有意義的文字，並在網頁字型準備就緒後，轉換為網頁字型。
一般來說，如果您剛好使用網頁字型 (就像大部分的網頁一樣)，請採用良好的網頁字型載入策略。
您可以使用許多網路平台功能，最佳化字型載入體驗，但也可以查看 Zach Leatherman 的網路字型食譜存放區，因為這真的很棒。
減少會阻礙轉譯的指令碼
我們也可以將應用程式的其他部分提前到下載鏈中，以便提早提供至少一些基本的使用者體驗。
在 Lighthouse 時間軸上，您可以看到在載入所有資源的前幾秒，使用者實際上看不到任何內容。
下載及處理外部樣式表會阻礙轉譯程序，導致無法繼續進行。
我們可以提早提供部分樣式，嘗試最佳化重要轉譯路徑。
如果我們擷取負責初始轉譯的樣式，並將其內嵌在 HTML 中，瀏覽器就能立即轉譯，不必等待外部樣式表。
在我們的案例中，我們使用名為 Critical 的 NPM 模組，在建構步驟中將重要內容內嵌至 index.html。
雖然這個模組為我們完成了大部分的繁重工作，但要讓這個模組在不同路徑上順利運作，還是有點棘手。
如果沒有一開始就規劃應用程式命令介面架構，那麼在不夠謹慎或網站結構非常複雜的情況下，可能很難導入這類模式。
因此，在初期就考量效能非常重要。如果一開始未考量效能，日後很可能會遇到問題。
最後，我們的冒險獲得了回報，成功讓應用程式更早提供內容，大幅縮短畫面首次有效顯示所需時間。
結果
我們對網站進行了許多效能最佳化調整。來看看結果。以下是應用程式在最佳化前後，於中型行動裝置上透過 3G 網路載入的情況。
Lighthouse 效能分數從 23 分提高到 91 分。就速度而言，這項進展相當不錯。我們持續查看並遵循 Lighthouse 報表，因此進行了所有變更。如要瞭解我們如何透過技術實作所有改善項目，歡迎查看我們的存放區，尤其是其中包含的 PR。
預測成效 - 資料導向的使用者體驗
我們相信，機器學習在許多領域都代表著令人期待的未來商機。我們希望未來能激發更多實驗，其中一個想法是，真實資料確實能引導我們打造使用者體驗。
目前，我們對使用者可能想要或需要的內容，以及值得預先擷取、預先載入或預先快取的內容，做出許多任意決定。如果我們猜對了，就能優先處理少量資源，但要擴大到整個網站，難度非常高。
我們現在有資料可供參考，能更有效地進行最佳化。使用 Google Analytics Reporting API，我們可以查看網站上任何網址的下一個熱門網頁和離開百分比，進而判斷應優先處理哪些資源。
如果我們將這項功能與良好的機率模型結合，就能避免過度預先擷取內容，浪費使用者的數據。我們可以利用 Google Analytics 資料，並使用機器學習和馬可夫鏈或類神經網路等模型，來實作這類模型。
為了協助進行這類實驗，我們很高興宣布推出一項名為 Guess.js 的新計畫。
Guess.js 是一項專案，著重於以資料為依據的網路使用者體驗。希望這能激發大家探索如何運用資料提升網頁效能，甚至更進一步。這些都是開放原始碼，目前已在 GitHub 上提供。這項工具是由 Minko Gechev、Gatsby 的 Kyle Matthews、Katie Hempenius 和其他多位人士與開放原始碼社群合作開發。
歡迎試用 Guess.js，並分享你的想法。
摘要
分數和指標有助於提升網頁速度，但這些只是手段，
我們都曾有過在行動裝置上載入網頁緩慢的經驗，但現在我們有機會為使用者提供更愉快的體驗，讓網頁載入速度更快。
提升成效需要時間，許多小改變可以帶來大收穫。只要使用合適的最佳化工具，並持續關注 Lighthouse 報表，就能為使用者提供更優質、更全面的體驗。
特別感謝：Ward Peeters、Minko Gechev、Kyle Mathews、Katie Hempenius、Dom Farolino、Yoav Weiss、Susie Lu、Yusuke Utsunomiya、Tom Ankers、Lighthouse 和 Google Doodles。