教學課程目標
本教學課程會說明如何使用 Chrome 開發人員工具,找出加快網站載入速度的方法。
請繼續閱讀或觀看本教學課程的影片版本:
必備條件
您應具備基本的網路開發經驗,類似這個網頁開發課程簡介中的課程。
您不需要瞭解載入效能的任何資訊。
引言
我是 Tony。東尼在貓社會中相當知名他建立了網站,方便粉絲瞭解他最喜歡的食物。他的粉絲很喜歡這個網站,但 Tony 不斷聽到網站載入緩慢的客訴。阿尼要求你協助他們加快網站運作速度。
步驟 1:稽核網站
決定改善網站的載入效能時,請務必從稽核開始著手。稽核程序有兩個重要功能:
- 這會建立基準,供您評估後續變更。
- 並針對每個變更項目提供具體可行的秘訣,協助你瞭解哪些變更最能發揮影響力。
設定
首先,您必須為 Tony 的網站設定新的工作環境,以便日後變更:
在 Glitch 上重混該網站的專案。新專案隨即會在新分頁中開啟。 這個分頁將稱為「編輯器」分頁。
專案名稱會從 tony 變更為某個隨機產生的名稱。您現在可以編輯自己的程式碼副本。稍後您將修改這個程式碼。
在編輯器分頁底部,依序按一下「預覽」>「在新視窗中開啟」。示範模式會在新分頁中開啟。這個分頁稱為「示範」分頁。網站可能需要一段時間才能載入完成。
跟著示範開啟開發人員工具。
建立基準
基準是網站成效改善記錄,有助您瞭解網站改善成效。
開啟「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())
。等待 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
函式上。
接著,看看使用實際工作環境模式和減少 JavaScript 活動是否會加快頁面載入速度。從實際工作環境模式開始:
- 在編輯器分頁中,開啟
webpack.config.js
。 - 將
"mode":"development"
變更為"mode":"production"
。 - 等待新的版本部署完畢。
再次稽核頁面。
移除對 mineBitcoin
的呼叫,藉此減少 JavaScript 活動:
- 在編輯器分頁中,開啟
src/App.jsx
。 - 對
constructor
中的this.mineBitcoin(1500)
呼叫執行註解排除。 - 等待新的版本部署完畢。
- 再次稽核頁面。
一如既往,仍有需要採取的行動,例如減少「最大內容繪製」和「累計版面配置位移」指標。
在現實生活中減少主執行緒的工作
一般來說,「效能」面板是瞭解網站載入時最常進行的活動,以及移除不必要的活動的方法。
如果您偏好更像 console.log()
的方法,可以使用 User Timing API 隨意標記應用程式生命週期的特定階段,追蹤每個階段的所需時間。
摘要
- 準備最佳化網站的載入效能時,請務必從稽核開始著手。稽核結果會建立基準,並提供改善建議。
- 每次做出一項變更,並在每次變更後稽核頁面,瞭解隔離的變更對效能有何影響。
後續步驟
在自家網站上執行稽核!如果您在解讀報表時需要協助,或需要改善負載成效的方法,請查看 DevTools 社群尋求協助的所有方法:
- 在 developer.chrome.com 存放區中,提交這份文件的錯誤資訊。
- 歡迎前往 Chromium 錯誤,透過開發人員工具回報錯誤。
- 在郵寄清單中討論功能和異動。請勿使用郵寄清單詢問支援問題。請改用 Stack Overflow。
- 前往 Stack Overflow 查看開發人員工具的一般說明。如要回報錯誤,請一律使用 Chromium 錯誤功能。
- 在 Twitter 上標記 @ChromeDevTools。