教學課程目標
本教學課程將介紹如何使用 Chrome 開發人員工具,找出加快網站載入速度的方法。
請繼續閱讀,或觀看本教學課程的影片版本:
先備知識
您應具備基本的網頁開發體驗,類似這個「網頁開發簡介」課程中的內容。
您無需瞭解載入效能。
簡介
我是 Tony,東尼在貓社會中非常有名。他架設了一個網站,讓粉絲知道自己最愛的食物。他的粉絲喜歡這個網站,但 Tony 一直向我們表示網站載入速度緩慢的抱怨。Tony 請你協助他加快網站速度。
步驟 1:稽核網站
每次著手改善網站的載入效能時,請務必從稽核著手。這項稽核有兩個重要功能:
- 會建立基準來協助您評估後續的變化。
- 並提供實用訣竅,協助您瞭解哪些變更最能產生影響。
設定
首先,您需要為 Tony 網站設定新的工作環境,以便日後進行變更:
在 Glitch 上重混網站的專案。系統會在新分頁中開啟新專案。這個分頁將稱為「編輯器」分頁。
專案名稱會從 tony 變更為隨機產生的名稱。您已取得自己的程式碼可編輯副本。稍後,您會變更此程式碼。
在編輯器分頁底部,依序點選「預覽」 >「在新視窗中開啟」。示範內容會在新分頁中開啟。這個分頁將稱為「示範」分頁。網站可能需要一段時間才會載入。
在示範旁邊開啟開發人員工具。
建立基準
基準是指網站在提升效能之前的成效。
開啟「Lighthouse」面板。可能位於
更多面板後方。請將 Lighthouse 報表的配置設定與螢幕截圖中的設定相符。以下是不同選項的說明:
- check_box 清除儲存空間。勾選這個核取方塊即可在每次稽核前,清除與該頁面相關的所有儲存空間。如要稽核新訪客的網站訪客體驗,請將這項設定保持開啟。如想保留回訪體驗,請停用這項設定。
- check_box 啟用 JS 取樣。這個選項預設為關閉。開啟這項功能後,效能追蹤就會加入詳細的 JavaScript 呼叫堆疊,但報表產生速度可能會變慢。產生「Lighthouse」報表後,more_vert您可以依序前往「Tools」選單 >「View Unthrotled Trace」查看追蹤記錄。
- 模擬節流 (預設) 。這個選項會模擬在行動裝置上瀏覽網頁的情況。之所以稱為「模擬」,因為 Lighthouse 於稽核期間並未真的節流。而是會推測網頁在行動裝置環境下載入網頁所需的時間。另一方面,「開發人員工具節流 (進階)」設定實際上會節流您的 CPU 和網路,需要較長的稽核程序才能有所取捨。
- 模式 > 三種模式。 導航 (預設)。這個模式會分析單個網頁載入,這就是本教學課程所需的資訊。詳情請參閱
- 「裝置」 > 「行動裝置」。行動選項會變更使用者代理程式字串,並模擬行動裝置可視區域。桌機選項基本上只會停用行動版變更功能。
- 類別 > check_box 成效。啟用單一類別可讓 Lighthouse 只根據相應的稽核組合產生報告。如果想查看這些類別提供的最佳化建議類型,請保持啟用。停用不相關的類別可稍微加快稽核程序。
按一下「分析網頁載入」。10 到 30 秒後,「Lighthouse」面板會顯示網站成效的報告。
處理報表錯誤
如果 Lighthouse 報表未顯示錯誤,請嘗試在沒有其他開啟的分頁的情況下,透過無痕式視窗執行示範分頁。這可確保您執行 Chrome 時使用的是乾淨狀態。Chrome 擴充功能可能會幹擾稽核程序。
瞭解報表資訊
報表上方的數字是網站的整體成效分數,之後當您變更程式碼時,應該會看到這個數字有所上升。分數越高表示成效越佳。
指標
向下捲動至「指標」部分,然後按一下「展開檢視畫面」。如要閱讀指標的說明文件,請按一下「瞭解詳情...」。
本節提供網站效能的量化評估資料。 每項指標都能讓您深入瞭解成效不同面向。例如,First Contentful Paint 會告訴您內容首次繪製到畫面中的時間,這是使用者對頁面載入感知的重要里程碑,而「互動所需時間」則是用來標示頁面顯示時間,足以處理使用者互動。
螢幕截圖
接著是一系列螢幕截圖,顯示網頁載入後的樣貌。
商機
接下來的 Opportunity 部分會提供具體訣竅,協助您改善這個頁面的載入效能。
點按商機即可瞭解詳情。
按一下「瞭解詳情...」即可查看說明文件,瞭解商機的重要性,以及建議的修正方法。
診斷
「診斷」專區會提供更多影響網頁載入時間的因素相關資訊。
通過稽核
「通過的稽核」部分會顯示網站運作情形。按一下即可展開該部分。
步驟 2:實驗
Lighthouse 報表的「商機」部分會針對如何改善頁面效能提供提示。在本節中,您將對程式碼集實作建議變更,並在每次變更後稽核網站,以評估對網站速度的影響。
啟用文字壓縮
您的報告指出啟用文字壓縮是改善網頁效能的絕佳機會。
文字壓縮是指透過網路傳送文字前,先縮減 (或壓縮) 文字檔案大小。傳送資料夾以縮減資料夾大小之前,您可以對資料夾進行壓縮。
啟用壓縮功能之前,可以按照下列幾種方式手動檢查文字資源是否已壓縮。
開啟「網路」面板,並勾選 「使用大型要求列」。
「設定」 >每個「大小」儲存格都會顯示兩個值。最上層的值是已下載資源的大小。底部值是未壓縮資源的大小。如果兩個值相同,表示透過網路傳送資源時,資源不會壓縮。在這個範例中,bundle.js
的頂端和底部值為 1.4 MB
。
您也可以檢查資源的 HTTP 標頭,以檢查是否有壓縮:
按一下「bundle.js」bundle.js並開啟「Headers」bundle.js分頁。
在「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」面板,然後在頂端的動作列中按一下 「Perform an audit...」。
沿用先前的設定,然後按一下「分析網頁載入」。
了不起!看起來像是進度。您的整體效能分數應該會提高,表示網站的速度變快了。
現實生活中的文字壓縮
大多數伺服器其實都做著類似的簡單的修正來啟用壓縮!請直接搜尋 如何設定要用來壓縮文字的伺服器
調整圖片大小
你的新報告指出,適當調整圖片大小是另一個絕佳機會。
調整圖片尺寸可縮減圖片的檔案大小,進而加快載入時間。如果使用者是在 500 像素寬的行動裝置螢幕上查看圖片,那麼傳送 1500 像素寬圖片其實並非必要。最好是傳送 500 像素寬的圖片。
在報表中按一下「使用適當大小的圖片」,即可查看應調整哪些圖片大小。但這 4 張圖片似乎比必要尺寸多。
返回編輯器分頁,開啟
src/model.js
。以
const dir = 'small'
取代const dir = 'big'
。 這個目錄包含已調整大小的圖片相同副本。再次稽核網頁,瞭解這項變更對載入效能的影響。
這項變更似乎只影響整體成效分數,不過,分數並不清楚地顯示,您節省了使用者的網路資料量。舊相片的總大小約為 6.1 MB,現在約只有 633 KB。您可以在「網路」面板底部的狀態列中查看這項資訊。
在真實環境中調整圖片大小
如果是小型應用程式,只要按照以下方式執行一次大小調整,應該就足夠了。但對於大型應用程式而言,這顯然是無法擴充的。以下是管理大型應用程式中圖片的一些策略:
- 在建構過程中調整圖片大小。
- 在建構過程中建立每個圖片的多種尺寸,然後在程式碼中使用
srcset
。瀏覽器會在執行階段選擇最適合執行裝置的尺寸。請參閱相對大小圖片。 - 使用 Image CDN,讓圖片能在提出要求時動態調整大小。
- 請至少將每張圖片最佳化。這通常可為您省下大筆開銷。最佳化是指透過特殊程式執行圖片並縮減圖片檔大小。如需更多提示,請參閱「基本圖片最佳化」一文。
排除會妨礙顯示的資源
最新一份報告指出,淘汰禁止轉譯資源是大好機會,
會禁止轉譯的資源是外部 JavaScript 或 CSS 檔案,瀏覽器必須先下載、剖析和執行,才能顯示網頁。目標是只執行正常顯示頁面所需的核心 CSS 和 JavaScript 程式碼。
第一項工作是找出不需在網頁載入時執行的程式碼。
按一下「消去禁止轉譯資源」,即可查看封鎖的資源:
lodash.js
和jquery.js
。根據您的作業系統,按下下列指令來開啟指令選單:
- Mac:Command + Shift + P 鍵
- 在 Windows、Linux 或 ChromeOS 中,按下 Control + Shift + P 鍵
開始輸入
Coverage
,然後選取「顯示涵蓋範圍」。系統會在「導覽匣」中開啟「涵蓋範圍」分頁。
按一下「Reload」圖示 。「涵蓋率」分頁概略說明
bundle.js
、jquery.js
和lodash.js
中在網頁載入時會執行多少程式碼。這張螢幕截圖顯示大約 74% 和 30% 的 jQuery 和 Lodash 檔案不會分別使用。
按一下 jquery.js 資料列。開發人員工具會在「Sources」面板中開啟檔案。如果程式碼行的旁邊有綠色長條,表示系統執行了該行程式碼。程式碼行旁邊顯示紅色列代表程式碼未執行,而且網頁載入時絕對不需要。
稍微捲動 jQuery 程式碼。有些取得「執行」的行實際上只是註解,如要縮減這個檔案的大小,透過能夠移除註解的壓縮器執行此程式碼,是另一種縮減檔案大小的方式。
簡而言之,當您使用自己的程式碼時,「Coverage」分頁可協助您分析程式碼、逐行分析,並僅傳送載入網頁所需的程式碼。
是否還需要 jquery.js
和 lodash.js
檔案才能載入頁面?「Request Blocking」(要求封鎖) 分頁會顯示無法使用資源時會發生的情況。
- 按一下「網路」分頁標籤,然後再次開啟「指令選單」。
開始輸入
blocking
,然後選取「Show Request Blocking」。「要求封鎖」分頁隨即開啟。按一下「新增模式」圖示 ,在文字方塊中輸入
/libs/*
,然後按下 Enter 鍵確認操作。重新載入網頁。jQuery 和 Lodash 要求會以紅色顯示,表示已封鎖。這個頁面仍會載入且具互動性,因此看起來不需要這些資源!
按一下 「移除所有模式」以刪除
/libs/*
的封鎖模式。
一般而言,「Request Blocking」(要求封鎖) 分頁可用來模擬頁面在沒有可用的資源時的行為。
現在,請從程式碼中移除這些檔案的參照,然後重新稽核頁面:
- 返回編輯器分頁,開啟
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」(效能) 面板分析主執行緒在網頁載入期間正在執行的工作,並設法延後或移除不必要的工作。
依序開啟「Performance」 >「Capture Settings」,然後將「Network」設為「Slow 3G」,並將「CPU」設為「6 倍減速」。
行動裝置的硬體限制通常比筆電或桌機還要高,因此這些設定可讓你在載入網頁時,就像使用效能較差的裝置一樣。
按一下「Reload」圖示 。開發人員工具會重新載入頁面,然後以視覺化方式呈現載入頁面需要完成的所有操作。這個視覺化圖表稱為「追蹤記錄」trace。
這項追蹤記錄會按照時間順序,由左至右顯示活動。頂端的 FPS、CPU 和 NET 圖表可讓您概略瞭解每秒影格、CPU 活動和網路活動。
「Overview」(總覽) 部分顯示的黃色牆表示 CPU 正忙於編寫指令碼活動。這樣一來,您或許就能減少 JavaScript 工作量,進而加快網頁載入速度。
調查追蹤記錄,找出減少 JavaScript 工作的方法:
按一下「時機」部分將其展開。
React 的「User Timing」有許多測量指標,似乎是 Tony 的應用程式正在使用 React 的開發模式。切換到 React 的生產模式應該能輕鬆享有一些簡單的效能。
再按一下「時機」即可收合該部分。
瀏覽「主要」部分。這個部分由左至右按時間順序顯示主要執行緒活動的記錄。Y 軸 (由上至下) 顯示事件發生的原因。
在本例中,
Evaluate Script
事件導致(anonymous)
函式正在執行,導致執行__webpack__require__
,進而執行./src/index.jsx
,以此類推。向下捲動至「Main」(主要) 部分底部。使用架構時,大多數的上層活動是由架構所造成,而架構通常是無法控制的。您應用程式造成的活動通常會顯示在底部。
在這個應用程式中,名為
App
的函式似乎造成大量呼叫mineBitcoin
函式。聽起來阿尼可能使用粉絲的裝置來採集加密貨幣...開啟底部的「Bottom-Up」分頁。這個分頁會分析耗時最長的活動,如果「Bottom-Up」部分沒有顯示任何資料,請按一下「Main-Up」部分的標籤。
「Bottom-Up」部分只會顯示您目前選取的任何活動或活動群組的資訊。舉例來說,如果您點選了其中一個
mineBitcoin
活動,則「Bottom-Up」部分只會顯示該活動的資訊。「自我時間」欄會顯示直接在每個活動中花費的時間。在此案例中,大約 82% 的主執行緒時間花在
mineBitcoin
函式上。
現在就確認使用實際執行模式及減少 JavaScript 活動,能否加快網頁載入速度。從正式環境模式開始:
- 在「編輯器」分頁中開啟
webpack.config.js
。 - 將
"mode":"development"
變更為"mode":"production"
。 - 等待新的建構作業部署完畢。
再次稽核網頁。
移除對 mineBitcoin
的呼叫,減少 JavaScript 活動:
- 在「編輯器」分頁中開啟
src/App.jsx
。 - 對
constructor
中對this.mineBitcoin(1500)
的呼叫執行註解排除。 - 等待新的建構作業部署完畢。
- 再次稽核網頁。
一如往常,還需要減少「Largest Contentful Paint」和「Cumulative Layout Shift」指標。
減少主執行緒的實際運作情況
一般來說,如要瞭解網站在載入時執行哪些活動,並尋找方法移除不必要的活動,最常見的方式就是「Performance」面板。
如果您偏好使用類似 console.log()
的方法,User Timing API 可讓您任意標記應用程式生命週期的特定階段,以追蹤這些階段所需的時間。
摘要
- 每次著手改善網站的載入效能時,請一律先從稽核作業著手。稽核作業會建立一個基準,並向您提供改善建議。
- 請一次進行一項變更,並在每次變更後稽核頁面,以便瞭解這項獨立變更對效能的影響。
後續步驟
在自己的網站上執行稽核!如果在解讀報表時需要協助,或想尋找改善載入效能的方法,請查看開發人員工具社群尋求協助的所有方法:
- 請前往 developer.chrome.com 存放區回報這份文件的錯誤。
- 如要提交開發人員工具的錯誤報告,請前往 Chromium 錯誤。
- 前往郵寄清單討論功能和異動內容,請勿使用郵寄清單發問。請改用 Stack Overflow。
- 前往 Stack Overflow 網站查看開發人員工具的一般使用說明。如要回報錯誤,請一律使用 Chromium 錯誤。
- 請透過 @ChromeDevTools 透過推文與我們聯絡。