導讀《打造高速網站，從網站指標開始！全方位提升使用者體驗與流量的關鍵》逐字稿@新竹敏捷
27 Dec 2021
導讀《打造高速網站，從網站指標開始！全方位提升使用者體驗與流量的關鍵》逐字稿@新竹敏捷。
不知道逐字稿在幹嘛？歡迎對照
3
一開始，我們先來聊聊，什麼是速度快的網站？
在工程師眼裡所謂效能好的網頁，跟實際上使用者感知到的好用的網頁很可能是有很大的差距的。而這樣的差距，往往讓效能優化這件事霧裡看花、好像改了卻沒感受到應有的效果。
4
我們先來看一些例子。
第一個情境是這樣的，假設有兩個頁面…
第一個頁面是漸進的載入內容，也就是說，隨著時間過去，使用者幾乎可以定期地看到載入的內容增加；下方的百分比是模擬載入的進度和經過的時間，時間是從開始載入 0 秒到載入完成 4 秒為止。
第二個頁面是讓使用者一直看到 loading icon，然後在最後一刻一下子把全部內容都載入完成。對使用者來說，雖然第一個頁面和第二個頁面所花的載入內容的時間是相同的，但是感覺上第一個頁面比較快。
關於這個問題呢，我們等等會看到關於載入速度的 FCP 和 LCP 指標，可以來幫助我們測量與改善。
5
第二個情境是，雖然頁面內容很快載入、使用者很快的看到完整的畫面，但是過了很久之後使用者才能與網頁互動，像是打字之類的，對使用者來說也是很慢的。
關於這個問題呢，我們等等會看到關於載入互動的 FID、TBT 和 TTI 指標，可以來幫助我們測量與改善。
6
第三個情境是，頁面各元素的不預期的移動，這樣的不預期的移動，並非使用者與頁面互動所產生的反應而做的位移。這對使用者來說由於不是預期的效果，因此很容易造成使用者的困擾，甚至是難以操作。在這個例子中，我們可以看到網頁一開始有三個圖文區塊，接著廣告從天而降，推移了圖文區塊，使用者本來可能想要點擊這個圖文區塊卻不小心點到了廣告，而打開了廣告頁。雖然這和傳統所謂的效能無關，但是體驗很差。
關於這個問題呢，我們等等會看到關於視覺穩定性和流暢性的 CLS 和 Speed Index 指標可以來幫助我們測量與改善。
7
「感知」很抽象，而 Google 提出的 RAIL 模型給我們一盞明燈。RAIL 是一個從使用者的角度來衡量效能的模型，這個模型將使用者體驗網頁的過程與網頁生命週期分為四種類型 —— Response (瀏覽器收到使用者與網頁互動後給予反應的時間不超過 100 ms)、Animation (動畫渲染頻率至少是 60 fps)、Idle (任務間讓瀏覽器主執行緒能有 50 ms 的空閒時間，或每個任務的執行時間不超過 50 ms) 和 Load (網頁載入所需時間並可與之互動須在 1 秒內完成)，使用者針對不同類型皆有不同的期待，因此對於改善效能的目標即是依據使用者對於這些類型所能接受的延遲時間來定義的。
簡單來說，使用者對於網頁是不是速度快的感知上的衡量，主要是這兩件事「是否持續得到回饋」與「是否能即時互動」，若一網頁無法即時互動和給予回饋，那麼對於使用者來說就是速度慢。
因此，在接下來的分享中，會設法經由更細膩的指標與工具來協助我們達成這些目標，也就是我們接下來想要來聊聊的主題「網站指標 Web Vitals」。
8
過去，我們在做網站的效能調校時，有很多很多的方法和目標。但是，我們可能都會遇到一些難題，像是
- 第一，對於使用者介面這一塊，沒有統一的準則來告訴我們，到底要優化什麼可以讓網站的效能更好。
- 第二，在我們工程師眼裡，所謂的效能好，可能是指很快地收到伺服器的回應；或是利用網頁的生命週期 API 來從 HTML 或外部資源載入完成的時間點來判斷快慢。但是這些在使用者看來可能都不能代表良好的體驗，甚至也無法反應用起來有多快、有多順暢，導致優化效能這件事霧裡看花、可能改了卻沒感受到任何效果。也就是說，這些所謂的效能好、速度快，包含了太多太多使用者的感受和想像，太複雜了。
所以，在這裡，我們可以根據使用者的期待來決定改善的目標，這個目標就是網站指標，就能讓我們有效地改善網站效能，進而以及改善使用者體驗。
9
Web Vitals 目前主要衡量三個面向，就是載入速度、載入互動性和視覺穩定性。為什麼要選這三個方向呢？因為，對使用者來說
- 載入速度是指，畫面載入完成代表終於可以開始瀏覽與操作網頁，這就是一切體驗的開始。
- 載入互動性是指，網頁在操作之後會給予回饋，這代表使用者的輸入是有反應的。
- 最後，視覺上的穩定與順暢代表能有舒適的體驗。
10
目前測量使用者對於效能感知的網站指標，
- 載入速度（load speed）的指標有 FCP 和 LCP。
- FCP 是指測量網頁載入時使用者可在螢幕上看到第一個可見元素所花的時間。
- LCP 是指測量網頁載入時使用者可在螢幕上看到最大面積元素所花的時間。
- 載入互動性的指標有 FID、TTI 和 TBT。
- FID 是指測量網頁載入後使用者第一次與網頁互動直到瀏覽器有空回應的時間。
- TTI 是指測量網頁載入、在長時間的任務結束後，使用者可與瀏覽器互動並給予回應的延遲時間。
- TBT 是指測量網頁載入後，主執行緒被長時間任務阻塞的總時間。
- 視覺穩定性與流暢性的指標有 CLS 和 SI。
- CLS 是指測量在網頁存活週期間，每個可見元素移動位置的分數的總和，用於衡量網頁元件出現不預期位移的頻率。
- SI 是用來衡量網頁載入期間，內容在視覺上有多快能呈現在使用者面前，簡言之即是視覺上的「流暢性」。
11
網站指標中最核心的部份稱為「核心網站指標（core web vitals，簡稱 CWV）」，核心網站指標有 LCP、FID 與 CLS，稱為「核心」的原因是這三個指標能被實際測量以具體反應真實體驗結果，並且具體代表使用者體驗的特定面向。
12
網站指標可以幫助我們了解網站的現況，與確認是否朝著正確的方向做改善，那麼，我們當然需要「工具」來協助我們做測量、給建議。那麼，到底有什麼工具能幫助我們測量指標與調整網站狀態呢？基本上，Google 目前當紅的產品都可以偵測這些指標。
13
這些工具包含 Lighthouse、Chrome DevTools、PageSpeed Insights、CrUX (cruks) 還有 Search Console。
這些工具，以及這些工具所蒐集得到的資料，分為兩種，就是模擬和實地。也就是說，對於這些指標的資料蒐集呢，我們分為兩種方式，模擬測量與實地測量 所以得到的資料也有兩種，就是模擬資料與實地資料。
- 模擬測量工具可以提供使用者可能怎麼使用這個網站與其體驗狀況，並提供可重現的結果來做除錯和修正後的驗證。像是 Lighthouse、Chrome DevTools 還有 PageSpeed Insights。
- 實地測量工具提供真實世界的使用者體驗此網站的觀察，能給予更多不同面向的解讀，像是…就算是經過精心優化的網站，若多數使用者是經由較差的網路設備或裝置瀏覽，那麼也會被評定為效能差的。因此，「速度快」與否不見得與網站優化程度有關，有時也和多數使用者所處狀況有關。或是，可在產品上線後檢視使用者實際操作的狀況而發掘效能問題，或是驗證已解決的問題。工具像是 CrUX、Search Console 還有 PageSpeed Insights 都可以提供這樣的測量和資訊。
稍後我們會在一些實際範例中看到怎麼用這些工具，還有怎麼跟工作流程結合。
14
第一個我們要來看的面向，是關於載入速度的指標。
15
我們來看一個實際的例子 Mixtini。
Mixtini 是一個推廣調酒與酒吧的線上服務網站。由於 Mixtini 的首頁以大圖並多圖的方式呈現，這個網站的首頁的 FCP 與 LCP 不論在桌機或是手機上其實都滿高的。首頁是使用者對此網站的第一印象，因此改善載入效能就成為當務之急。
16
影響 FCP 和 LCP 的原因是資源載入的速度，歸納起來是有三個原因：禁止轉譯的資源、伺服器回應速度過慢或資源載入過慢，這三個原因就成為我們優化載入速度的方向與目標
- 第一個，就「禁止轉譯的資源」來說，瀏覽器在完成渲染前，瀏覽器必須「等待」關鍵的 CSS 與 JavaScript 資源，這個「等待」就是「禁止轉譯」的意思，因此禁止轉譯的資源會影響 FCP 與 LCP。
- 第二個，就「伺服器回應速度過慢」來說，當瀏覽器發出資源請求，而伺服器回應速度過慢，則會導致瀏覽器較晚收到回應而延遲能讓使用者看到畫面的時間，進而影響 FCP 與 LCP。
- 第三個，就「資源載入速度過慢」來說，除了 CSS 與 JavaScript 資源會因為禁止轉譯的問題而延遲渲染，其他資源如圖檔也會影響載入的效能，進而影響 FCP 與 LCP。因此，資源的優化是很重要的，其他像是預先載入重要的資源、壓縮文字檔、可適性服務、減少用不到的程式碼，做這些調整都能有效改善 FCP 與 LCP。
17
因此，針對 Mixtini 的狀況，我們做了以下四件事情的調整
- 第一個是，實作響應式圖檔和提供 webp 格式的檔案。Mixtini 在優化前，桌機和行動裝置都是使用相同大尺寸的圖檔，因此圖檔的檔案體積大、下載時間長，這在多圖和行動裝置下的下載速度往往很難接受。因此在這裡我們改成針對不同尺寸的螢幕提供不同尺寸的圖檔，同時，我們也提供 webp 格式的檔案，在手機上就能大大減低檔案體積與下載時間。
- 第二個是，我們把圖檔放在 CDN 上，CDN 服務就能讓使用者就近下載檔案，節省網路傳輸時間。並且，現在有許多 CDN 也提供優秀的 image server 的服務，因此我們把圖檔放在這樣的 image server 或 CDN 上，就能自動提供不同尺寸與不同格式的圖檔，在這裡使用了 Cloudinary 的服務。
- 第三個是，由於 Mixtini 的圖檔主要存放在 Cloudinary，並且使用 Google Fonts，這些都存在第三方網域上，為了儘早建立網路連線，會希望讓瀏覽器針對外連的網域利用 dns-prefetch 預先做 DNS 解析、preconnect 儘早建立連線
- 最後是，預先載入重要資源，我們使用 preload 預先下載重要大圖。
18
在經過以上的調整後
- FCP 在行動裝置下降了 27%。
- LCP 在桌機下降了 58%，行動裝置下降了 68%。
19
在這裡比較特別的地方是，由於 CrUX 蒐集的資料是有流量門檻的，也就是說，小型的專案並不會被蒐集進去，那麽在 PageSpeed Insight 等這些由 CrUX 所提供資料的工具上就看不到這些網站的指標資料，在這邊有兩個選擇。
- 第一，自己用 web-vitals 之類的 js library 來實作 RUM 系統，也就是 real user monitoring system，或是
- 第二，使用 Firebase Performance 來幫我們紀錄和分析
在這裡 Mixtini 因為是小成本專案，所以就選擇了方便好用的 Firebase Performance 來幫我們蒐集指標資料。
20
第二個來看的實際例子是我現在所在的公司，趨勢科技的 DDD 產品，DDD 是我們家趨勢科技的產品，主要用於防禦網路攻擊。
21
在 DDD 專案中，在前端部份主要發現兩個問題
- 第一，在開發期間，更新程式碼後的編譯過程非常費時，工程師需等待較長一段時間才能驗證是否符合期待。
- 第二，在載入效能上，瀏覽器一次載入較大量的程式碼，渲染畫面的時間較長，因此使用者需要等待較長時間才能看到畫面、與元件互動。
因此，在本次改善上，希望能達到以下兩點目的
- 第一，對工程師來說，希望在開發階段能減少程式碼的編譯時間。
- 第二，對使用者來說，希望在畫面的渲染上，能減少載入程式碼的時間，即改善載入效能，就能改善 FCP 與 LCP。
22
針對載入效能不佳的狀況，經由 Lighthouse 檢測後，發現有很多很多問題，像是
- 網路傳輸的檔案很大
- 瀏覽器的主執行緒常常在執行一些會花費比較長時間的任務
等等問題。
在檢視這些問題後，我們發現核心的問題在於打包的檔案太大，導致網頁一次載入過多程式碼。也就是說，我們把網站裡面所有的程式碼基本上都打包成一大包
23
為了解決打包檔案的問題，我們使用的改善策略是，我們要做 Route-based Code Splitting。
這個解法是說，設定 Webpack 的設定檔來針對 route 切分為不同的 chunk 與共用的 chunk。在畫面載入時除了載入共用與目前所在的 route 所需要的 chunk 之外，其他部份的程式碼會依照使用者瀏覽不同頁面時再動態載入。
24
在做以上這些改善後，我們用利用 Webpack Bundle Analyzer 檢視打包後的檔案大小與成效。
- 改善前，打包的檔案包含各頁會用到的程式碼，也就是說各頁往往會載入當前用不到的程式碼。
- 改善後，當頁只會載入本身會用到的程式碼，就大大減少下載的程式碼的量。
25
我們實測專案首頁的狀況下，發現
- 打包檔案減少了 24%。
- FCP 減少了 35% 。
- LCP 減少了 24%。
在這裡，由於減少載入程式碼體積，因此瀏覽器下載、解析與執行程式碼的時間也減少許多，有效改善載入效能，進而改善 FCP 與 LCP；更由於編譯時間變短，開發體驗更好，就能鼓勵開發者投入更多成本來維護專案。
26
本專案除了改善 DDD 的效能之外，同時也實作 STM 系統 synthetic monitoring system 合成監控系統，將效能改善加入工作流程。我們的工作流程就變成
在打包專案程式碼之後，會用 Lighthouse CI 檢測效能。關於這部分，我們會檢測專案內，特定網頁的狀況，並且針對 Lighthouse 的建議做調整。之後在產品上線後，會蒐集資訊與驗證成效。由於產品並非公開網站，因此不會使用 CrUX 蒐集資訊，而是經由 onsite 測試來做驗證。我們將 Lighthouse CI 整合至 CI/CD 工具中，每週對專案中的特定頁面做效能檢測，並將報告發給相關工程師來改善，而且定期檢測就能找出潛在的效能問題，避免上線後才發現重大缺陷。
27
第二個面向，我們要來看的指標是關於載入互動性的指標。
28
載入互動性的問題，也就是反應不夠即時的問題，通常原因是瀏覽器的主執行緒過於忙碌，所以減少主執行緒任務的數量或時間都有幫助。
29
接下來，我們要來看一個「露天拍賣」的實際的例子。露天拍賣是台灣規模最大的 C2C 電商網站，這次主要來看「手機版商品頁的問與答」。
30
在前端部份我們發現在畫面載入後，使用者若想要使用問與答功能，按下「我要提問」按鈕後，再輸入文字的文字框出現的反應時間是有點慢的。
31
在這裡關於「互動不夠即時」的解法，我們做的改進主要針對兩個方向：「加快取得資源的速度」和「減少瀏覽器主執行的負擔、精簡程式碼」。具體來說，就是
- 第一，移除用不到的程式碼，在這裡移除多餘引用的函式庫與元件；移除較肥大、改用較輕量的的函式庫。
- 第二，優化體積較大的檔案，對這個檔案做 code splitting，在此頁只載入需要用到的部份，其餘的移到另一隻檔案以供其他頁面使用。
- 第三，延遲載入非關鍵資源，像是 GA 等這樣的第三方函式庫。
- 最後，使用 preconnect 預先建立網路連線，以期提早取得第三方資源；還有使用 preload 以強制要求瀏覽器預先載入關鍵資源
32
在經過以上的調整後，在行動裝置上
- TTI 下降了 11 %。
- TBT 下降了 48 %。
- FID 下降了 7 %。
33
最後第三個面向，我們要來看的指標是關於視覺穩定性的指標。
34
造成視覺不穩定的原因，大致上有幾種
- 第一個是沒有設定明確尺寸的圖檔、動態載入廣告、影片或其他內容。
- 第二個是動態載入元件但未預留足夠空間。
- 第三個是字體顯示策略的問題 FOIT 與 FOUT。
35
我們再次來看露天拍賣的例子。露天拍賣的手機版的問與答，我們還有發現另一個問題，就是此頁面的 CLS 偏高的。
利用 Lighthouse 與 ChromeDev Tools 的 Timeline 檢測，發現是 footer 在商品資訊和提問內容出現後不斷往下推移，而造成大量的位移。
36
露天拍賣的解法為
- 第一，我們為商品資訊 product-info 預留了所需的最小高度，以減少版位移動的距離。
- 第二，我們將 footer 移到可視範圍之外，只有當使用者往下滑動時才會看到 footer。
因此使用者在載入這個頁面時，便能看到商品資訊與提問內容是在固定的位置，而 footer 也不會一閃而過地不斷往下推移。
37
在經過以上的調整後，CLS 下降了 100 %，現在這個頁面是完全沒有任何不預期元素位移的。
38
以上看完了指標和工具，那麼，我們該怎麼將效能優化融合進每天的工作當中呢？
39
產品生命週期上，建議的工作流程是這樣的
- 第一步：利用 Search Console 的核心網站指標報告，蒐集與確認需要關注的議題。
- 第二步：利用 PSI 診斷該網頁實地與模擬的狀況，並將其提供的建議當成優化的方向。
- 第三步：進入開發或除錯階段，使用模擬工具 Lighthouse 與 Chrome DevTools 模擬特定的環境來實作與驗證是否達到改善的目的，這個階段通常需來回重覆多次。
- 第四步：利用 web.dev 取得更多參考資料或範例。
- 第五步：利用 Lighthouse CI 在每個 PR (pull request) 檢查指標的資訊，讓產品在部署到正式環境前，做好效能測試。
- 第六步：利用 CrUX 或其他 RUM 系統驗證在真實環境中問題是否解決，並觀察使用者實際操作的狀況而發掘是否有潛在的效能問題，以及了解網站長期走向與趨勢。
40
這樣就結束了嗎？那讓我們來看看關於 SEO 這個議題。
從 Search Console 的網頁體驗報告可知，所謂「曝光數」是指品質良好的網址被搜尋到的總次數，意即「流量來自於具有良好品質的網頁」，因此，若想讓網頁提高曝光率，依照網站指標來改善網頁品質、提升使用者體驗是絕對必要的。
但是，要做好搜尋引擎優化的工作，基本功不可少 —— 好的內容與關鍵字、良好的網頁結構、圖文並茂、對機器人好爬、對內與對外連結、網站效能、支援行動裝置等，綜合以上才會是做好搜尋引擎優化的工作，進而能讓網站排名提升。
41
最後，我們來看看結論…
42
覺得優化效能很困難嗎？
43
第一，從前面的實際例子，我們可以知道，只要抓對問題，小小的更動也是有很大的效果
第二，因為是針對使用者體驗，所以不再讓優化效能這件事霧裡看花、好像改了卻沒感受到任何效果
44
再來，專案時程很緊嗎？
45
那就試試看把效能優化的工作切小，然後讓工具幫幫忙，並且融入工作流程中，成為功能開發的一部份，這樣就能試著讓煩瑣龐大的工作變得能夠輕易完成
46
最後，團隊很難合作嗎？
47
相較於傳統效能的調整與測試，網站指標給予不同角色的人有「提升使用者體驗」的共同目標、凝聚大家的共識，較容易溝通，也因為共識而改變工作模式，凸顯效能調校的重要，而不是只做功能的開發。
48
以上是我的分享，非常感謝大家的參與。
若對於以上主題有興趣，歡迎讀讀我的書！
再次感謝大家！
