打造高速網站，從網站指標開始！(Speed Up Your App with Web Vitals) MOPCON 2021 逐字稿
24 Oct 2021
打造高速網站，從網站指標開始！(Speed Up Your App with Web Vitals) MOPCON 2021 逐字稿。
不知道逐字稿在幹嘛？歡迎對照預錄影片或投影片
1
封面：打造高速網站，從網站指標開始！(Speed Up Your App with Web Vitals)。
2
自我介紹。
3
今天的分享就從一個故事開始，最近小明想要買隻「iPhone 13」來玩玩。
4
於是小明打開他最愛的購物網站。
5
一打開購物網站的首頁，左等右等都只能看到表示載入中的 loading icon，畫面遲遲顯示不出來。
6
等了好久終於看到首頁了，想在搜尋 bar 上輸入關鍵字 iphone13，可是當滑鼠點到搜尋 bar 時，卻點到突然下滑的廣告，然後就被瀏覽器帶到另開的廣告頁
7
小明只好無奈的關掉不小心點開的廣告頁，再度回到購物網站，終於可以在搜尋 bar 上輸入關鍵字 iphone13 了，可是等了好久搜尋框才能打字捏！
8
打好「iphone13」這幾個字之後，然後點了送出搜尋的按鈕，等待搜尋更新後，小明不停將畫面往下捲動，想要看看有沒有更便宜、更快到貨的商品選項，可是每次往下捲都要等很久才有新的資訊出現。
而且 loading icon 的出現和消失，以及新的商品區塊的顯示所造成的畫面的跳動，都讓小明覺得很受干擾和不耐煩。
9
這整個網站的瀏覽和互動的體驗過程真的很痛苦，為了買一個 iphone13 弄得心力交瘁，小明都要哭了。
10
雖然小明身為這個網站的愛用者，但真心認為這網站是應該要砍掉重練。
11
不過我們做人不要那麼消極，其實不砍掉重練，調整一下就可以了。
12
那麼，我們重新回顧一下那些讓小明不開心的片刻，是什麼地方讓小明覺得不好呢？
我們先來看一些例子。
第一個情境是這樣的，假設有兩個頁面…
-
第一個頁面是漸進的載入內容，也就是說，隨著時間過去，使用者幾乎可以定期地看到載入的內容增加；下方的百分比是模擬載入的進度和經過的時間，時間是從開始載入 0 秒到載入完成 4 秒為止。
-
第二個頁面是讓使用者一直看到 loading icon，然後在最後一刻一下子把全部內容都載入完成。
對使用者來說，雖然第一個頁面和第二個頁面所花的載入內容的時間是相同的，但是感覺上第一個頁面比較快。
所以，在剛剛的小明的最愛的電商網站的顯示過程中，畫面遲遲顯示不出來，一直都是 loading icon，就讓小明覺得等待了太久太久了，網站怎麼這麼慢。
關於這個問題呢，我們等等會看到關於載入速度的 FCP 和 LCP 指標，可以來幫助我們測量與改善。
13
第二個情境是，雖然頁面內容很快載入、使用者很快的看到完整的畫面，但是過了很久之後使用者才能與網頁互動，像是打字之類的，對使用者來說也是很慢的。
所以，在剛剛的小明最愛的電商網站的搜尋 iphone 13 的過程中，雖然看到畫面但是不能打字搜尋，對小明來說這網站依舊效能很差，速度很慢。
關於這個問題呢，我們等等會看到關於載入互動的 FID、TBT 和 TTI 指標，可以來幫助我們測量與改善。
14
第三個情境是，頁面各元素的不預期的移動，這樣的不預期的移動，並非使用者與頁面互動所產生的反應而做的位移。這對使用者來說由於不是預期的效果，因此很容易造成使用者的困擾，甚至是難以操作。
像是小明本來想要在搜尋框輸入關鍵字做搜尋，但是卻被突然下滑的廣告帶離網站。雖然這和效能無關，但是體驗很差。
關於這個問題呢，我們等等會看到關於視覺穩定性和流暢性的 CLS 和 Speed Index 指標可以來幫助我們測量與改善。
15
以上三個情境，總結了小明這樣的使用者瀏覽網站的不愉快的體驗，那麼，什麼是愉快的體驗呢？什麼會讓使用者覺得效能好呢？ Google 根據觀察使用者在與網頁互動過程中所得到的容忍程度而提出的 RAIL 模型。
RAIL 模型是一個以使用者的角度來檢視網頁效能的方式，讓我們能了解使用者的期待，來設定正確的優化網站的目標。
- R 是指要在 100 ms 以內回應使用者的輸入。
- A 是指動畫的每 frame 的渲染頻率是 60 FPS，雖然算起來可以有 16 ms 做渲染，但實際上，由於瀏覽器有很多工作要做，因此大約是 10 ~ 12 ms。
- I 是指讓瀏覽器主執行緒在每個任務之間能有 50 ms 的空閒時間，或說是每個任務最好切小在 50ms 內可以完成，這樣就不會長時間佔用主執行緒，就能快速回應使用者的互動，做出反應。
- L 是指網頁要在 1 秒內載入畫面並可以互動。
這個 RAIL 模型呢，讓我們了解使用者對於網頁整個體驗過程所抱持著期待，而這些期待就成為效能改善的目標。
因此，在接下來的分享中，會設法經由更細膩的指標與工具來協助我們達成這些目標，也就是我們接下來想要來聊聊的主題「網站指標 Web Vitals」。
16
過去，我們在做網站的效能調校時，有很多很多的方法和目標。
但是，我們可能都會遇到一些難題，像是
- 第一，對於使用者介面這一塊，沒有統一的準則來告訴我們，到底要優化什麼可以讓網站的效能更好。
- 第二，在我們工程師眼裡，所謂的效能好，可能是指很快地收到伺服器的回應；或是利用網頁的生命週期 API 來從 HTML 或外部資源載入完成的時間點來判斷快慢。但是這些在使用者看來可能都不能代表良好的體驗，甚至也無法反應用起來有多快、有多順暢，導致優化效能這件事霧裡看花、可能改了卻沒感受到任何效果。也就是說，這些所謂的效能好、速度快，包含了太多太多使用者的感受和想像，太複雜了。
所以，在這裡，我們可以根據使用者的期待來決定改善的目標，這個目標就是網站指標，就能讓我們有效地改善網站效能，進而以及改善使用者體驗。
17
Web Vitals 目前主要衡量三個面向，就是載入速度、載入互動性和視覺穩定性。
18
為什麼要選這三個方向呢？因為，對使用者來說
- 載入速度是指，畫面載入完成代表終於可以開始瀏覽與操作網頁，這就是一切體驗的開始。
- 載入互動性是指，網頁在操作之後會給予回饋，這代表使用者的輸入是有反應的。
- 最後，視覺上的穩定與順暢代表能有舒適的體驗。
從剛剛小明的例子來看，這三個方向基本上就代表了是否能帶給使用者良好體驗的關鍵。
19
網站指標可以幫助我們了解網站的現況，與確認是否朝著正確的方向做改善，那麼，我們當然需要「工具」來協助我們做測量、給建議。
那麼，到底有什麼工具能幫助我們測量指標與調整網站狀態呢？基本上，Google 目前當紅的產品都可以偵測這些指標。
20
這些工具包含 Lighthouse、Chrome DevTools、PageSpeed Insights、CrUX 還有 Search Console。
這些工具，以及這些工具所蒐集得到的資料，分為兩種，就是模擬和實地。也就是說，對於這些指標的資料蒐集呢，我們分為兩種方式，模擬測量與實地測量。所以得到的資料也有兩種，就是模擬資料與實地資料
- 模擬測量工具可以提供使用者可能怎麼使用這個網站與其體驗狀況，並提供可重現的結果來做除錯和修正後的驗證。像是 Lighthouse、Chrome DevTools 還有 PageSpeed Insights。
- 實地測量工具提供真實世界的使用者體驗此網站的觀察，能給予更多不同面向的解讀， 像是…就算是經過精心優化的網站，若多數使用者是經由較差的網路設備或裝置瀏覽，那麼也會被評定為效能差的。 因此，「速度快」與否不見得與網站優化程度有關，有時也和多數使用者所處狀況有關。 或是，可在產品上線後檢視使用者實際操作的狀況而發掘效能問題，或是驗證已解決的問題。 工具像是 CrUX、Search Console 還有 PageSpeed Insights 都可以提供這樣的測量和資訊。
稍後我們會在一些實際範例中看到怎麼用這些工具，還有怎麼跟工作流程結合。
21
第一個我們要來看的面向，是關於載入速度的指標。
22
第一個要來看的指標是 first contentful paint，簡稱 FCP，中文是「首次顯示內容」，它是指「載入第一個可見元素所花的時間」，在這裡可以看到第一個可見元素是 loading icon，快速的 FCP 可確保使用者不是空等。
而隨著網頁的資源載入，就能看到這個頁面最重要的內容，這叫做 largest contentfaul paint，簡稱 LCP，中文是「最大內容繪製」，它是指「載入最大面積元素所花的載入時間」，通常是指網頁大圖或是最大的文字區塊，快速的 LCP 能讓使用者儘快確認該頁的資訊對他們是否有用。
如這張投影片所看到的，這個頁面在一開始載入時畫面上是什麼都沒有的，然後出現了 loading icon 暗示使用者網站仍在持續載入資源，接著出現搜尋框，並接著載入圖文區塊，最後顯示完整的網頁內容。
因此…
- FCP 是指第一個可見元素出現所花的時間，此為 loading icon，是 400 ms。
- LCP 是指最大面積的元素出現所花的時間，此為圖文區塊，是 900 ms。
23
影響 FCP 和 LCP 的原因是資源載入的速度，歸納起來是有三個原因：禁止轉譯的資源、伺服器回應速度過慢或資源載入過慢，這三個原因就成為我們優化載入速度的方向與目標。
第一個，就「禁止轉譯的資源」來說
瀏覽器在完成渲染前，會解析 HTML 來建立 DOM tree，當遇到 CSS 或需要同步下載 JavaScript 的外連檔案時，HTML parser 便會暫停解析，進行檔案下載、解析與執行，直至完成再回到原先的工作，最後使用者才能看到畫面。在這一連串的過程中，瀏覽器必須「等待」關鍵的 CSS 與 JavaScript 資源，這個「等待」就是「禁止轉譯」的意思，因此禁止轉譯 (render-blocking) 的資源會影響 FCP 與 LCP。
第二個，就「伺服器回應速度過慢」來說
當瀏覽器發出資源請求，而伺服器回應速度過慢，則會導致瀏覽器較晚收到回應而延遲能讓使用者看到畫面的時間，進而影響 FCP 與 LCP。
第三個，就「資源載入速度過慢」來說
除了 CSS 與 JavaScript 資源會因為禁止轉譯 render-blocking 的問題而延遲渲染，其他資源如圖檔也會影響載入的效能，進而影響 FCP 與 LCP。因此，資源的優化是很重要的，其他像是預先載入重要的資源、壓縮文字檔、可適性服務、減少用不到的程式碼，做這些調整都能有效改善 FCP 與 LCP。
24
我們來看一個實際的例子 Mixtini。Mixtini 是一個專注於推廣調酒與酒吧的線上服務網站。
25
由於 Mixtini 的首頁以大圖並多圖的方式呈現，這個網站的首頁的 FCP 與 LCP 不論在桌機或是手機上其實都滿高的。那…首頁是使用者對此網站的第一印象，因此改善載入效能就成為當務之急。
26
針對 Mixtini 的狀況，我們做了以下四件事情的調整
- 第一個是，實作響應式圖檔和提供 webp 格式的檔案。Mixtini 在優化前，桌機和行動裝置都是使用相同大尺寸的圖檔，因此圖檔的檔案體積大、下載時間長，這在多圖和行動裝置下的下載速度往往很難接受。因此在這裡我們改成針對不同尺寸的螢幕提供不同尺寸的圖檔，同時，我們也提供 webp 格式的檔案，在手機上就能大大減低檔案體積與下載時間。
- 第二個是，我們把圖檔放在 CDN 上，CDN 服務就能讓使用者就近下載檔案，節省網路傳輸時間。並且，現在有許多 CDN 也提供優秀的 image server 的服務，因此我們把圖檔放在這樣的 image server 或 CDN 上，就能自動提供不同尺寸與不同格式的圖檔，在這裡使用了 Cloudinary 的服務。
- 第三個是，由於 Mixtini 的圖檔主要存放在 Cloudinary，並且使用 Google Fonts，這些都存在第三方網域上，為了儘早建立網路連線，會希望讓瀏覽器針對外連的網域利用 dns-prefetch 預先做 DNS 解析、preconnect 儘早建立連線。
- 最後是，預先載入重要資源，我們使用 preload 預先下載重要大圖。
27
在經過以上的調整後
- FCP 在行動裝置下降了 27%。
- LCP 在桌機下降了 58%，行動裝置下降了 68%。
28
在這裡比較特別的地方是，由於 CrUX 蒐集的資料是有流量門檻的，也就是說，小型的專案並不會被蒐集進去，那麽在 PageSpeed Insight 等這些由 CrUX 所提供資料的工具上就看不到這些網站的指標資料，在這邊有兩個選擇
- 第一，自己用 web-vitals 之類的 js library 來實作 RUM 系統，也就是 real user monitoring system，或是
- 第二，使用 Firebase Performance 來幫我們紀錄和分析
在這裡 Mixtini 因為是小成本專案，所以就選擇了方便好用的 Firebase Performance 來幫我們蒐集指標資料。
29
第二個來看的實際例子是我現在所在的公司，趨勢科技的 DDD 產品。DDD 是我們家趨勢科技的產品，主要用於防禦網路攻擊。
30
在 DDD 專案中，在前端部份主要發現兩個問題
- 第一，在開發期間，更新程式碼後的編譯過程非常費時，工程師需等待較長一段時間才能驗證是否符合期待。
- 第二，在載入效能上，瀏覽器一次載入較大量的程式碼，渲染畫面的時間較長，因此使用者需要等待較長時間才能看到畫面、與元件互動。
因此，在本次改善上，希望能達到以下兩點目的
- 第一，對工程師來說，希望在開發階段能減少程式碼的編譯時間。
- 第二，對使用者來說，希望在畫面的渲染上，能減少載入程式碼的時間，即改善載入效能，就能改善 FCP 與 LCP。
31
針對載入效能不佳的狀況，經由 Lighthouse 檢測後，發現有很多很多問題，像是網路傳輸的檔案很大、瀏覽器的主執行緒常常在執行一些會花費比較長時間的任務等等問題。
在檢視這些問題後，我們發現核心的問題在於打包的檔案太大，導致網頁一次載入過多程式碼。也就是說，我們把網站裡面所有的程式碼基本上都打包成一大包。
32
為了解決打包檔案的問題，我們使用的改善策略是，我們要做 Route-based Code Splitting。
這個解法是說，設定 Webpack 的設定檔來針對 route 切分為不同的 chunk 與共用的 chunk。在畫面載入時除了載入共用與目前所在的 route 所需要的 chunk 之外，其他部份的程式碼會依照使用者瀏覽不同頁面時再動態載入。
33
在做以上這些改善後，我們用利用 Webpack Bundle Analyzer 檢視打包後的檔案大小與成效。
- 改善前，打包的檔案包含各頁會用到的程式碼，也就是說各頁往往會載入當前用不到的程式碼。
- 改善後，當頁只會載入本身會用到的程式碼，就大大減少下載的程式碼的量。
34
我們實測專案首頁的狀況下，發現
- 打包檔案減少了 24%。
- FCP 減少了 35%。
- LCP 減少了 24%。
在這裡，由於減少載入程式碼體積，因此瀏覽器下載、解析與執行程式碼的時間也減少許多，有效改善載入效能，進而改善 FCP 與 LCP；更由於編譯時間變短，開發體驗更好，就能鼓勵開發者投入更多成本來維護專案。
35
本專案除了改善 DDD 的效能之外，同時也實作 STM 系統 synthetic monitoring system 合成監控系統，將效能改善加入工作流程。
我們的工作流程就變成
- 在打包專案程式碼之後，會用 Lighthouse CI 檢測效能。
- 關於這部分，我們會檢測專案內，特定網頁的狀況。
- 並且針對 Lighthouse 的建議做調整。
- 之後在產品上線後，會蒐集資訊與驗證成效。
- 由於產品並非公開網站，因此不會使用 CrUX 蒐集資訊，而是經由 onsite 測試來做驗證。
我們將 Lighthouse CI 整合至 CI/CD 工具中，每週對專案中的特定頁面做效能檢測，並將報告發給相關工程師來改善，而且定期檢測就能找出潛在的效能問題，避免上線後才發現重大缺陷。
36
第二個面向，我們要來看的指標是關於載入互動性的指標。
37
關於載入互動性的指標有三個，分別是 TTI、TBT 和 FID。
- 第一個是 TTI，全名是 time to interactive，中文是「互動準備時間」，它的定義是「FCP 與 quite window 之間，使用者可與網頁互動的時間點」。
- 第二個是 TBT，全名是 total blocking time，中文是「總阻塞時間」，它的定義是「在 FCP 和 TTI 之間，主執行緒被長時間任務阻塞的總時間」。在這個投影片當中，我們可以看到，所謂的長時間執行的任務的時間是指，在 FCP 和 TTI 之間，這個任務超過 50 ms 的部分，這裡有兩個任務，超過 50 ms 的部分標記為紅色斜線，分別有 10 ms 和 20 ms，所以 TBT 就是 30 ms。
- 第三個是 FID，全名是 first input delay，中文是「首次輸入延遲」，它的定義是「使用者第一次與網頁互動，直到瀏覽器能對此互動做出回應的時間差」。
由於 FID 是在實地環境中蒐集而得的真實的使用者的資訊，因此我們若想要在自己的開發環境上重現問題或改進效能，會用 TBT 或 TTI 作為 proxy metrics 來協助改善載入互動性。
38
載入互動性的問題，也就是反應不夠即時的問題，通常原因是瀏覽器的主執行緒過於忙碌，所以減少主執行緒任務的數量或時間都有幫助。
39
接下來，我們要來看一個「露天拍賣」的實際的例子。露天拍賣是台灣規模最大的 C2C 電商網站，這次主要來看「手機版商品頁的問與答」。
40
在前端部份我們發現在畫面載入後，使用者若想要使用問與答功能，按下「我要提問」按鈕後，再輸入文字的文字框出現的反應時間是有點慢的。
41
在這裡關於「互動不夠即時」的解法，我們做的改進主要針對兩個方向：「加快取得資源的速度」和「減少瀏覽器主執行的負擔、精簡程式碼」。
具體來說，就是
- 第一，移除用不到的程式碼，在這裡移除多餘引用的函式庫與元件；移除較肥大、改用較輕量的的函式庫
- 第二，優化體積較大的檔案，對這個檔案做 code splitting，在此頁只載入需要用到的部份，其餘的移到另一隻檔案以供其他頁面使用。
- 第三，延遲載入非關鍵資源，像是 GA 等這樣的第三方函式庫
- 最後，使用 preconnect 預先建立網路連線，以期提早取得第三方資源；還有使用 preload 以強制要求瀏覽器預先載入關鍵資源。
42
在經過以上的調整後，在行動裝置上
- TTI 下降了 11 %。
- TBT 下降了 48 %。
- FID 下降了 7 %。
43
最後第三個面向，我們要來看的指標是關於視覺穩定性的指標。
44
第一個來看 CLS，全名是 cumulative layout shift，中文是累計版位配置位移，是指測量在頁面的整個存活期間，每個可見元素位移分數的總和。
CLS 的算法是找出可視範圍內個別元素最大的影響範圍和最大的位移比例之總和。如這張投影片，一開始有兩個圖文區塊，然後廣告出現了，把圖文區塊擠下去。
因此
- 最大的影響範圍就是紅框的部份，大約佔總面積的 ⅔。
- 最大的位移比例是藍框位移距離，大約佔高度的 1/3。
CLS 就是 2/9。
45
第二個有關於視覺穩定的指標，是比較偏向視覺流暢性，就是速度指數，全名是 speed index，簡稱 SI，是用來衡量網頁載入期間，內容在視覺上有多快能呈現在使用者面前，簡言之即是視覺上的「流暢性」。SI 的產生方式是利用瀏覽器的工具來錄製影片，針對每個 frame 所載入的畫面來計算完成度，最後再利用 Speedline Node.js 模組來產生 SI 的分數。
概念示意圖如這張投影片，由於 SI 是測量的是視覺的流暢性，因此是計算隨著時間推演，還剩下多少未完成的比率的總和，也就是這張圖藍色的部份。
46
造成視覺不穩定的原因，大致上有幾種
- 第一個是沒有設定明確尺寸的圖檔、動態載入廣告、影片或其他內容。
- 第二個是動態載入元件但未預留足夠空間。
- 第三個是 FOIT (flash of invisible text) 與 FOUT (flash of unstyled text)。
47
我們再次來看露天拍賣的例子。露天拍賣的手機版的問與答，我們還有發現另一個問題，就是此頁面的 CLS 偏高的。
利用 Lighthouse 與 ChromeDev Tools 的 Timeline 檢測，發現是 footer 在商品資訊和提問內容出現後不斷往下推移，而造成大量的位移。
48
露天拍賣的解法為
- 第一個，我們為商品資訊 product-info 預留了所需的最小高度，以減少版位移動的距離。
- 第二個，我們將 footer 移到可視範圍之外。
因此使用者在載入這個頁面時，便能看到商品資訊與提問內容是在固定的位置，而 footer 也不會一閃而過地不斷往下推移。
49
在經過以上的調整後，CLS 下降了 100 %，現在這個頁面是完全沒有任何不預期元素位移的。
50
我們來重新看一下針對使用者來制定的指標有哪些。這些指標，就是能幫助我們以使用者的角度來優化效能的目標。
51
並且，網站指標中最核心的部份稱為「核心網站指標 (core web vitals，簡稱 CWV)」，稱為「核心」的原因是
- 第一，可適用於所有類型的網頁而被測量，並且所有的 Google 的工具都能做檢視。
- 第二，能具體代表使用者體驗的一個面向。
- 第三，能被實際測量而非模擬測量，具體反應以使用者為中心的真實體驗結果。
52
在工具方面，為了能有效利用指標來改善網站，我們勢必需要使用能測量網站指標的工具，並且結合工具與工作流程，將這樣的效能優化的方式融合進每天的工作當中
因此，產品生命週期上，建議結合工具與工作流程是這樣的
- 第一步：利用 Search Console 的核心網站指標報告，蒐集與確認需要關注的議題。
- 第二步：利用 PSI 診斷該網頁實地與模擬的狀況，並將其提供的建議當成優化的方向。
- 第三步：進入開發或除錯階段，使用模擬工具 Lighthouse 與 Chrome DevTools 模擬特定的環境來實作與驗證是否達到改善的目的，這個階段通常需來回重覆多次。
- 第四步：利用 web.dev 取得更多參考資料或範例。
- 第五步：利用 Lighthouse CI 在每個 PR (pull request) 檢查指標的資訊，讓產品在部署到正式環境前，做好效能測試。
- 第六步：利用 CrUX 或其他 RUM 系統驗證在真實環境中問題是否解決，並觀察使用者實際操作的狀況而發掘是否有潛在的效能問題，以及了解網站長期走向與趨勢。
53
經過以上優化，我們讓小明從頭來體驗一次優化後的購物網站…好的，重來一次唷！有一天小明想要買個「iphone 13」來玩玩
54
於是，小明打開他最愛的購物網站，畫面快速載入可互動，順利搜尋無阻礙。
55
廣告是固定在網頁上的，沒有干擾他的操作。
56
往下滾動無比流暢。
57
小明感到開心。
58
我只能說，這個購物網站變得很棒。
59
這樣就結束了嗎？那讓我們來看看關於 SEO 這個議題。
在 2010 年，Google 在官方的部落格宣布網站速度 (site-speed) 為搜尋 的 ranking factor 之一 記得在 2014 年的 Searchmetrics 所發表的 Ranking-Factors 2014 報告中，強調了使用者的動向 (user signals) ，對照現今的網站指標所強調的載入速度、互動性、視覺穩定性與流暢性來看，並非原創的新觀念，只是過去埋藏在眾多因素當中，目前在 Search Console 中被獨立成核心網站指標與網頁體驗的報告。
因此，要做好搜尋引擎優化的工作，基本功是一定不能少的，像是好的內容與關鍵字、良好的網頁結構、圖文並茂、對機器人好爬、對內與對外連結、網站效能、支援行動裝置等，綜合以上才會是做好搜尋引擎優化的工作，進而能讓網站排名提升。
SEO 不只關乎網站體驗，但 SEO 的確是個好理由來改善網站體驗！
60
網站指標的未來會怎麼發展呢？
-
第一，由於目前網站指標主要專注於載入效能 (loading performance) ，而不包含執行互動性，因此未來必會新增後者這一塊。
-
第二，由於 Lighthouse 即將新增 treemap 功能，能快速便利地了解打包檔案的狀況，例如：個別打包檔案的體積、未使用的程式碼的大小與比率，以便讓開發者改善 JavaScript 程式碼對於效能的影響，除了加強載入速度、載入互動性的檢測外，更呼應了第一點檢測執行互動性的可能性。
61
最後，我們來看看結論…
62
覺得優化效能很困難嗎？
63
第一，從前面的實際例子，我們可以知道，只要抓對問題，小小的更動也是有很大的效果
第二，因為是針對使用者體驗，所以不再讓優化效能這件事霧裡看花、好像改了卻沒感受到任何效果 我覺得這很重要，尤其是說服主管、團隊夥伴，甚至是我們開發者本身來讓我們做這件事情，都需要有個強大的理由和動機。
64
再來，專案時程很緊嗎？
65
那就試試看把效能優化的工作切小，然後讓工具幫幫忙，並且融入工作流程中，成為功能開發的一部份，這樣就能試著讓煩瑣龐大的工作變得能夠輕易完成。
66
最後，團隊很難合作嗎？
67
相較於傳統效能的調整與測試，網站指標給予不同角色的人有「提升使用者體驗」的共同目標，這樣呢，就能凝聚大家的共識，大家雖然出發點不同，但目標相同，就比較容易溝通。
也由於大家都參與，因此優化效能就不再只是工程師工作而已。
並且，這樣的工作模式的改變，是有助於將效能調校這件事情成為必要的任務，能被重視、給予時程和資源的安排來做這件事，而不是只做功能的開發。
68
以上就是我的分享，非常感謝大家的參與。
最後想跟大家說，今年年底以前我會出一本書，書名是「打造高速網站，從網站指標開始！」，如果大家對於這個 Web Vitals 這個議題或是對於今天我所分享的內容有興趣，都歡迎來看我的書。
由於這本書還沒有開賣，有興趣的人可以掃描 QR code 來填寫 google 表單，出書後會做通知。
再次感謝大家！
QnA
QnA 紀錄，在當場沒有完整回答的就在這裡寫完整一點！
- 自選題：我的自問自答，想跟大家分享的東西。沒人問問題就自己講好講滿。
- 他選題：當場會眾的問答。
FID 與 TBT 的比較？(自選題)
這裡有個有趣的議題，在觀察 FID 與 TBT 的數據時，我們可能會發現，網站具有良好的 FID，而 TBT 卻十分的糟糕？這是因為，FID 蒐集所得的實地資料是由真實的使用者操作網站所蒐集而來的資訊，而當第 75 百分位的使用者是體驗良好的便會標記為優良，其中個別使用者的行為差異甚大，而在此網站所操作的網頁或功能也各異，因此這樣的實地資料是大量統計的結果；TBT 蒐集所得的是模擬資料，經由 Lighthouse 此類工具模擬某單一使用者的操作行為，操作的流程可能剛好是會造成主執行緒忙碌的的動作，而得到不佳的結果，因此兩者有如此大的差別。因此，FID 與 TBT 雖然相關，可經由改善 TBT 來間接減少 FID，但在資料解讀上意義卻是不同的。
怎麼不在 PR 時檢查 Web Vitals？(自選題)
現在公司的產品不是電商或社群這種非常在乎前端效能的地方，所以我們應該不需要每個 PR 或每個功能都這麼認真 😂 只要對特定相對重要或是複雜的功能來檢測就好，然後發 task 給對應的工程師，不過光是做到這點就非常厲害了，對吧。但我們的確有個產品是在 PR 時檢查 Web Vitals，後來就拔掉了。
團隊合作的秘訣？(自選題)
利用「共同目標」也就是「提升使用者體驗」這件事情作為溝通的重心，因為客戶開心才會賺錢。
記得…不要急，要有耐心，循序漸進的前進，例如…
- 自己要先做一些研究、side project、POC，這些都要有心理準備是下班時間做的。
- 多分享交流、不要逼迫夥伴一定要接受或是做這些事情，而是慢慢帶入日常工作中。我從 Lighthouse 到 STM 開了很多 design review、不同面向的 sharing (自己部門不同角色的夥伴、公司前端 only)、時不時跟同事聊聊這塊內容，跟其他部門的工程師交換心得體悟。很多時候人面對陌生的東西都會抗拒，那就慢慢的把這件事情帶入日常生活中、看見獲得的好處，大家就比較不會那麼抗拒，自己也會得到很多很多很多啟發。任何一點點進展都值得慶祝 👏🏻🎊
- 有可能公司沒辦法排一個優化的時程來做這件事情，那就將平常的工作加上這一點點效能調校的東西，一點點累積久了也會有成效的，要有耐心。
- 如果改善的成果很有限，那就思考怎樣可以改更多。時間沒什麼進步，可以從視覺流暢性來改。
- 能將這些效能調校與相關系統實作成為工作的一部份當然很好，但也許只能靠工作空檔來完成。兼顧這些事情和工作是有難度的，想做就要堅持下去。在這過程中，我覺得最困難的地方是克服自己的心魔，這樣的心魔像是遇到主管或是同事的疑惑、覺得不重要、沒有資源時該怎麼爭取，還有堅持與自己身心的調適。像是一開始主管可能會覺得主要的效能瓶頸一定是在後端，前端有必要大費周章處理這些嗎？就不能當成 bug 偶爾修一下就好嗎？同事有可能也會認為為什麼要增加他們工作負擔？backend or QA 更會看不懂這對他們的工作有什麼幫助。做到後來自己可能也會感到身心俱疲難以負荷，畢竟這不是幾天或一週兩週就可以完成的小東西。對我來說，這就是我想做的，我有收穫，是為了自己的興趣、技術和職涯，那就不用去管其他人要給我什麼資源、怎麼看我，「做就對了」。
有什麼準備工作？(自選題)
重構 legacy code 要先寫測試。
專案中若有技術限制，一定是有歷史原因的，要花比較多時間做處理，同時還要考慮沒人記得的商業邏輯，這時候寫測試就很重要。沒寫測試就重構程式碼真的很危險。
關於工具的建議？(自選題 + 他選題)
可以參考投影片中提到的結合工具與工作的流程圖。
不過，在極端狀況下如果遇到工具不給力，就不太適用這個流程圖的狀況。去年某個 A 專案…我在解 FID 的問題的時候，在專案上遇到一個問題，就是在專案裡面，有一段 code 是把資料從 server 端取回來以後，先做 base64 壓縮，然後存到 session storage。在極端的狀況下，要下載的資料量大約是 75 MB，由於資料很大，所以在做 base64 壓縮這一段大約花了 100 秒，再存到 session storage 時由於超過 5MB 的限制就爆掉了。除了極端狀況外，在其他 case 裡面，這一段也造成 FID 很大的延遲問題。順道一提，我們家的產品當時還沒有任何效能監測系統，因此是產品上線前到客戶家做 on site 測試才發現的，回來就是立刻排時間處理，因此很推薦大家要將效能調校排進工作流程裡面，才能盡量避免這種緊急問題。這困難的地方是在於 Chrome DevTools 由於資料量太大，被我用到當掉，解決問題最怕就是沒工具可用…所以當時對於這種極端狀況的 debug 和測試我就只能一步步 console 出來看，然後當比較確定方向之後，再用比較一般的 case 的資料量，搭配工具 Lighthouse 和 Chrome DevTools 等來處理、做細部調整。最後優化的方式就是調整 UI 和打 API 的流程、把整段壓縮和儲存的 code 都拔掉。
怎麼規劃 test case？(他選題)
選 (1) 商業價值高的 或 (2) 常常有 bug 的、容易有效能問題的。
然後記得要埋追蹤的工具來比較改善前後的狀況，才能有改進的依據。
蓋版廣告會影響 SEO 嗎？(他選題)
會，多年前 user signals 即成為 ranking factor 之一，蓋版廣告會影響使用體驗，導致使用者失去耐心、放棄瀏覽或不再造訪網站，那麼就會影響排名。
補充，影響排名的因子很多，不要希望經由改一兩項就可以提升排名。所以顧好基本功就變得很重要，可是要讓產品固好基本功是很困難的，通常都不是技術問題，比較多的是政治、資源成本考量的問題。
如何開始在工作中做效能調校？有簡單範例嗎？(他選題)
- 自己先做 side project，然後在工作的專案上從小功能開始做起。
- (打廣告) 之後歡迎看我的書，歡迎玩玩書上範例的公開在 GitHub 的 repository。
圖檔優化的 Image Server 怎麼實作的？(他選題)
目前在 Mixtini 是找現有的服務串 API 來做的，像是 Cloudinary。
怎麼實作 preconnect / dns-prefetch？(他選題)
小專案可以直接寫死在 HTML 上，大專案、需動態更新的就用 Webpack plugin「preload-webpack-plugin」來實作。
(歡迎大家補充遺漏的問答，感謝 🙏🏻)
