本頁面由 Cloud Translation API 翻譯而成。

Lighthouse：提升網站速度

Kayce Basques

Twitter GitHub Glitch

Sofia Emelianova

GitHub

教學課程目標

本教學課程會說明如何使用 Chrome 開發人員工具，找出加快網站載入速度的方法。

請繼續閱讀或觀看本教學課程的影片版本：

必備條件

您應具備基本的網路開發經驗，類似這個網頁開發課程簡介中的課程。

您不需要瞭解載入效能的任何資訊。

引言

我是 Tony。東尼在貓社會中相當知名他建立了網站，方便粉絲瞭解他最喜歡的食物。他的粉絲很喜歡這個網站，但 Tony 不斷聽到網站載入緩慢的客訴。阿尼要求你協助他們加快網站運作速度。

步驟 1：稽核網站

決定改善網站的載入效能時，請務必從稽核開始著手。稽核程序有兩個重要功能：

這會建立基準，供您評估後續變更。
並針對每個變更項目提供具體可行的秘訣，協助你瞭解哪些變更最能發揮影響力。

設定

首先，您必須為 Tony 的網站設定新的工作環境，以便日後變更：

在 Glitch 上重混該網站的專案。新專案隨即會在新分頁中開啟。這個分頁將稱為「編輯器」分頁。

專案名稱會從 tony 變更為某個隨機產生的名稱。您現在可以編輯自己的程式碼副本。稍後您將修改這個程式碼。
在編輯器分頁底部，依序按一下「預覽」>「在新視窗中開啟」。示範模式會在新分頁中開啟。這個分頁稱為「示範」分頁。網站可能需要一段時間才能載入完成。
跟著示範開啟開發人員工具。

建立基準

基準是網站成效改善記錄，有助您瞭解網站改善成效。

開啟「Lighthouse」面板。可能會隱藏在「」更多面板後方。

注意：這個面板採用同名的自動化工具 Lighthouse，可提升網頁應用程式的品質。
將 Lighthouse 報表配置設定與螢幕截圖上的設定配對。以下為不同選項的說明：
- 清除儲存空間。勾選這個方塊後，系統就會在每次稽核前清除與頁面相關聯的所有儲存空間。如果您想稽核網站訪客的首次瀏覽體驗，請將這項設定保持開啟。如要設為重複造訪體驗，請停用這項設定。
- 模擬節流 (預設) 。這個選項會模擬一般在行動裝置上瀏覽的情況。由於 Lighthouse 在稽核過程中實際上不會調節溫度，因此稱為「模擬」。而是推估網頁在行動裝置條件下載入所需的時間。另一方面，開發人員工具節流 (進階) 設定實際上會調節 CPU 和網路，但會犧牲較長的稽核程序。
- 模式 > 導航 (預設)這個模式會分析單一網頁載入分析，這是本教學課程所需的內容。詳情請參閱三種模式。
- 「裝置」 > 「行動裝置」。行動裝置選項會變更使用者代理程式字串，並模擬行動裝置可視區域。在電腦上，大部分選項都停用了行動版變更。
- 「類別」 > 「成效」。啟用單一類別後，Lighthouse 只會根據相應的稽核項目產生報表。如果您想查看其他類別提供的最佳化建議類型，可以保持啟用。停用不相關的類別可以加快稽核程序。
按一下「分析網頁載入」。10 到 30 秒後，「Lighthouse」面板會顯示網站成效報表。

處理報表錯誤

如果 Lighthouse 報告顯示錯誤，請嘗試透過未開啟其他分頁的無痕式視窗執行示範分頁。這可確保您以乾淨的狀態執行 Chrome。Chrome 擴充功能，特別容易乾擾稽核程序。

回報錯誤的報告。

瞭解報表

報表上方數字代表網站的整體成效分數。之後當您對程式碼進行變更時，這個數字應該會隨之增加。分數越高，成效越佳。

整體效能分數。

指標

向下捲動至「指標」部分，然後按一下「展開檢視畫面」。如要閱讀指標的說明文件，請按一下「瞭解詳情...」。

「指標」區段。

這個部分會提供網站效能的量化評估。每項指標都會提供成效不同面向的深入分析。舉例來說，「First Contentful Paint」指標會在內容首次繪製到畫面時通知您，這是使用者感知網頁載入的重要里程碑，而「互動時間」則代表頁面顯示到足以處理使用者互動的時間點。

螢幕截圖

接下來是螢幕截圖集合，會顯示網頁在載入時的外觀。

頁面載入時頁面的螢幕截圖。

商機

接下來的「Opportunity」部分會提供如何改善某個頁面載入效能的具體提示。

「商機」區段。

點選商機即可瞭解詳情。

$進一步瞭解文字壓縮機會。$

按一下「Learn more...」，查看商機為何重要的說明文件，以及建議的修正建議。

診斷

「診斷」專區會進一步瞭解影響網頁載入時間的因素。

「診斷」專區。

通過稽核

「通過稽核」部分會顯示網站是否正常運作。按一下即可展開這個部分。

「通過的稽核」專區。

步驟 2：實驗

Lighthouse 報表的「商機」部分提供改善網頁效能的提示。在本節中，您將對程式碼集實作建議的變更，並在每次變更後稽核網站，評估網站速度對網站速度的影響。

啟用文字壓縮

您的報告指出，啟用文字壓縮是改善網頁效能的主要機會之一。

文字壓縮是指先縮減或壓縮文字檔案大小，然後再透過網路傳送文字檔案。在傳送電子郵件前，您可以先對資料夾進行壓縮，藉此縮減資料夾大小。

啟用壓縮前，可以透過幾種方式手動檢查文字資源是否經過壓縮。

開啟「網路」面板，然後依序勾選「設定」 >「使用大型要求列」。

「網路」面板中的「大小」欄，顯示大型要求列。

每個「Size」儲存格會顯示兩個值。頂部的值是已下載資源的大小。底部值是未壓縮資源的大小。如果兩個值相同，則資源透過網路傳送時，不會壓縮。在這個範例中，bundle.js 的頂部和底部值皆為 1.4 MB。

您也可以檢查資源的 HTTP 標頭來檢查壓縮：

按一下 bundle.js，然後開啟「Headers」分頁。
在「Response Headers」部分搜尋 content-encoding 標頭。您應該不會看見一個，這表示 bundle.js 並未壓縮。資源「已壓縮」時，這個標頭通常會設為 gzip、deflate 或 br。如需這些值的說明，請參閱指令。

但是上面的說明夠了，請立即進行變更！新增幾行程式碼即可啟用文字壓縮：

在編輯器分頁中開啟 server.js，然後新增下列兩行 (醒目顯示的項目)：

...
const fs = require('fs');
const compression = require('compression');

app.use(compression());
app.use(express.static('build'));
...

請務必在 app.use(express.static('build')) 前加上 app.use(compression())。

注意：您通常必須透過 npm i -S compression 這類項目安裝 compression 套件，但系統已為您完成這項操作。
等待 Glitch 部署新版網站。如果表情符號顯示在左下角，代表部署成功。

使用您先前學習的工作流程，手動檢查壓縮作業是否正常運作：

返回示範分頁，重新載入頁面。

「Size」欄現在應針對文字資源 (例如 bundle.js) 顯示兩個不同的值。bundle.js 的 269 KB 最大值是透過網路傳送的檔案大小，而 1.4 MB 的值則是未壓縮的檔案大小。
bundle.js 的「Response Headers」區段現在應包含 content-encoding: gzip 標頭。

再次在頁面上執行 Lighthouse 報表，評估文字壓縮對頁面載入效能的影響：

開啟「Lighthouse」面板，然後點選頂端動作列的「執行稽核...」。
保留原本的設定，然後按一下「分析網頁載入」。

了不起！看起來像進度。您的整體效能分數應該會提高，表示網站速度變快。

現實世界中的文字壓縮

多數伺服器實際上都會執行這類簡單的修正方法，以便啟用壓縮功能！然後搜尋如何設定用來壓縮文字的伺服器即可。

調整圖片大小

新的報表顯示，適當調整圖片大小是另一個大好機會。

調整圖片大小有助於縮減圖片大小，從而縮短載入時間。如果使用者是在寬 500 像素的行動裝置螢幕上查看圖片，實際上並不會傳送 1500 像素寬的影像。在理想情況下，您最多需要傳送 500 像素寬的圖片。

在報表中按一下「適當大小的圖片」，瞭解應調整哪些圖片大小。看起來所有 4 張圖片似乎都超過所需大小。
返回編輯器分頁，開啟 src/model.js。
以 const dir = 'small' 取代 const dir = 'big'。這個目錄包含相同圖片的副本，但已經過調整大小。
再次稽核頁面，瞭解這項變更對載入效能的影響。

這項變更似乎只對整體成效分數有輕微影響。但是，分數中未指明的一件事就是您儲存使用者的網路資料量。舊相片的總大小約為 6.1 MB，但目前大約只有 633 KB。您可以在「網路」面板底部的狀態列中查看這項狀態。

調整圖片大小之前與之後傳輸的資料量。

調整實際圖像大小

對於小型應用程式，進行這類的一次性調整大小就足夠了。但對大型應用程式來說這明顯無法擴充以下是管理大型應用程式中圖片的一些策略：

在建構過程中調整圖片大小。
在建構過程中，為每個圖像建立多種尺寸，然後在程式碼中使用 srcset。在執行階段，瀏覽器會依照執行的裝置選擇最適合的大小。請參閱「相對大小的圖片」。
使用圖片 CDN，即可在要求圖片時動態調整大小。
至少將每張圖片最佳化。這麼做通常可以省下大筆費用。最佳化是指透過特殊程式執行圖片，可縮減圖片檔尺寸。如需更多提示，請參閱「重要圖片最佳化」一節。

排除會妨礙顯示的資源

最新的報告指出，消除禁止轉譯資源是最大的商機。

禁止轉譯資源是外部 JavaScript 或 CSS 檔案，瀏覽器必須先下載、剖析及執行該資源，才能顯示頁面。我們的目標是只執行正確顯示網頁所需的核心 CSS 和 JavaScript 程式碼。

接著，第一個工作是找出不必在載入網頁時執行的程式碼。

按一下「消除禁止轉譯資源」，查看封鎖的資源：lodash.js 和 jquery.js。
視作業系統而定，按下下列按鍵即可開啟指令選單：
- 在 Mac 上，Command + Shift + P 鍵
- 在 Windows、Linux 或 ChromeOS 中，按下 Control + Shift + P 鍵
輸入 Coverage，然後選取「顯示涵蓋率」。

「導覽匣」分頁會在導覽匣中開啟。
按一下「重新載入」圖示。「涵蓋率」分頁可讓你概略瞭解載入網頁時，執行 bundle.js、jquery.js 和 lodash.js 中程式碼的數量。

這個螢幕截圖顯示，jQuery 和 Lodash 檔案的 74% 和 30% 不會分別使用。
按一下 jquery.js 列。開發人員工具會在「Sources」面板中開啟檔案。已執行一行程式碼，如果旁邊顯示綠色長條。一行程式碼旁邊顯示紅色列代表未執行該程式碼，因此在載入網頁時並不需要。
稍微捲動 jQuery 程式碼。「executed」的部分實際上只是註解。透過移除註解的壓縮器執行此程式碼，是縮減這個檔案大小的另一種方式。

簡單來說，處理自己的程式碼時，「涵蓋率」分頁有助於分析程式碼、逐行列出，而且只傳送載入網頁所需的程式碼。

是否需要 jquery.js 和 lodash.js 檔案才能載入網頁？「Request Blocking」(要求封鎖) 分頁會顯示資源無法使用時會發生的狀況。

按一下「網路」分頁標籤，然後再次開啟「指令」選單。
開始輸入 blocking，然後選取「顯示要求封鎖」。「請求封鎖」分頁隨即開啟。
按一下「新增模式」，在文字方塊中輸入 /libs/*，然後按下 Enter 鍵進行確認。
請重新載入頁面。jQuery 和 Lodash 要求是以紅色顯示，表示這些要求已遭封鎖。頁面仍會載入且是互動性質，因此看起來不需要這些資源！
按一下「移除所有模式」刪除 /libs/* 封鎖模式。

一般來說，「要求封鎖」分頁可用來模擬頁面在無法使用任何特定資源時的行為。

接著，請從程式碼中移除這些檔案的參照，然後再次稽核頁面：

返回編輯器分頁，開啟 template.html。

刪除對應的 <script> 標記：

<head>
    ...
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="/libs/lodash.js"></script>
    <script src="/libs/jquery.js"></script>
    <title>Tony's Favorite Foods</title>
</head>

等待網站重新建構並重新部署。
透過「Lighthouse」面板再次稽核頁面。您的整體分數應該會有明顯改善。

在現實生活中最佳化關鍵算繪路徑

「關鍵算繪路徑」是指需要載入網頁的程式碼。一般來說，您可以在網頁載入期間只運送重要程式碼，再延遲載入其他內容，藉此加快頁面載入速度。

您不太可能找到可以直接移除的指令碼，但通常來說，在網頁載入期間，不需要請求許多指令碼，可以改為以非同步方式要求。請參閱使用非同步或延遲。
如果您使用架構，請確認架構是否具備正式環境模式。這個模式可能會使用樹木搖晃等功能，移除會封鎖重要轉譯的不必要的程式碼。

減少主執行緒的工作

最新報表的「Opportunity」部分會顯示些微的節省量，但如果您向下捲動到「診斷」部分，其中最大的瓶頸似乎是主執行緒活動太多。

瀏覽器在顯示網頁時需要執行大部分的必要作業，例如剖析並執行 HTML、CSS 和 JavaScript。

目標是使用「Performance」面板分析主要執行緒在網頁載入期間執行的工作，並尋找延後或移除不必要的工作。

依序開啟「效能」 > 「擷取設定」，然後將「網路」設為「慢 3G」，並將「CPU」設為「速度變慢 6 倍」。

行動裝置的硬體限制通常比筆電或桌機更多，因此透過這些設定，您可以像使用效能較低的裝置時一樣地載入網頁。
按一下「Reload」(重新載入)。開發人員工具會重新載入頁面，並產生視覺化內容，呈現載入頁面所需的一切行動。這個視覺化圖表稱為「追蹤記錄」trace。

這個追蹤記錄會依時間順序從左到右顯示活動。頂端的 FPS、CPU 和 NET 圖表可讓您概略瞭解每秒影格數、CPU 活動和網路活動。

追蹤記錄的「總覽」區段。

您在「Overview」部分看到黃色牆壁，表示 CPU 正忙著編寫指令碼活動。這個線索或許可以減少 JavaScript 工作，藉此加快頁面載入速度。

請調查追蹤記錄，找出簡化 JavaScript 作業的執行方法：

按一下「時間」展開這個部分。

React 有多項「使用者載入時間」措施，看來阿尼的應用程式似乎使用了 React 的開發模式。切換至 React 的製作模式可能有助於輕鬆提高成效。
再按一下「時間」，即可收合該部分。
瀏覽「Main」(主要) 部分。此區段依時間順序從左到右顯示主要執行緒活動的記錄。Y 軸 (由上到下) 顯示事件發生的原因。

在此範例中，Evaluate Script 事件會執行 (anonymous) 函式，進而導致執行 __webpack__require__，進而導致 ./src/index.jsx 執行等。
向下捲動至「Main」(主要) 部分底部。使用架構時，大多數上層活動都是由架構引起，而該架構通常並非由您控管。應用程式引發的活動通常位於底部。

在這個應用程式中，看起來像是 App 函式導致許多 mineBitcoin 函式呼叫了。阿尼可能會利用粉絲的裝置挖掘加密貨幣...

注意：雖然架構發出的呼叫通常出自於您之外，但有時候您可能會藉由建構應用程式結構的方式，導致架構執行效率低落。透過重整應用程式有效使用架構，可以減少主執行緒工作量的方法。為此，您必須深入瞭解架構的運作方式，以及如何在自己的程式碼中進行哪類變更，才能更有效率地使用架構。
開啟底部的「由下而上」分頁標籤。這個分頁會分析最常執行的活動。如果「Bottom-Up」部分沒有顯示任何項目，請按一下「Main」部分的標籤。

「Bottom-Up」部分只會顯示您目前選取的活動或活動群組資訊。例如，如果您點選其中一個 mineBitcoin 活動，「Bottom-Up」部分就只會顯示該活動的資訊。

「自行時間」欄會顯示直接在每個活動中花費的時間。在本例中，主要執行緒時間約有 82% 花在 mineBitcoin 函式上。