打造高速網站,從網站指標開始!(Speed Up Your App with Web Vitals) MOPCON 2021 逐字稿

打造高速網站,從網站指標開始!(Speed Up Your App with Web Vitals) MOPCON 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

那麼,我們重新回顧一下那些讓小明不開心的片刻,是什麼地方讓小明覺得不好呢?

我們先來看一些例子。

第一個情境是這樣的,假設有兩個頁面…

對使用者來說,雖然第一個頁面和第二個頁面所花的載入內容的時間是相同的,但是感覺上第一個頁面比較快。

所以,在剛剛的小明的最愛的電商網站的顯示過程中,畫面遲遲顯示不出來,一直都是 loading icon,就讓小明覺得等待了太久太久了,網站怎麼這麼慢。

關於這個問題呢,我們等等會看到關於載入速度的 FCP 和 LCP 指標,可以來幫助我們測量與改善。

13

第二個情境是,雖然頁面內容很快載入、使用者很快的看到完整的畫面,但是過了很久之後使用者才能與網頁互動,像是打字之類的,對使用者來說也是很慢的。

所以,在剛剛的小明最愛的電商網站的搜尋 iphone 13 的過程中,雖然看到畫面但是不能打字搜尋,對小明來說這網站依舊效能很差,速度很慢。

關於這個問題呢,我們等等會看到關於載入互動的 FID、TBT 和 TTI 指標,可以來幫助我們測量與改善。

14

第三個情境是,頁面各元素的不預期的移動,這樣的不預期的移動,並非使用者與頁面互動所產生的反應而做的位移。這對使用者來說由於不是預期的效果,因此很容易造成使用者的困擾,甚至是難以操作。

像是小明本來想要在搜尋框輸入關鍵字做搜尋,但是卻被突然下滑的廣告帶離網站。雖然這和效能無關,但是體驗很差。

關於這個問題呢,我們等等會看到關於視覺穩定性和流暢性的 CLS 和 Speed Index 指標可以來幫助我們測量與改善。

15

以上三個情境,總結了小明這樣的使用者瀏覽網站的不愉快的體驗,那麼,什麼是愉快的體驗呢?什麼會讓使用者覺得效能好呢? Google 根據觀察使用者在與網頁互動過程中所得到的容忍程度而提出的 RAIL 模型。

RAIL 模型是一個以使用者的角度來檢視網頁效能的方式,讓我們能了解使用者的期待,來設定正確的優化網站的目標。

這個 RAIL 模型呢,讓我們了解使用者對於網頁整個體驗過程所抱持著期待,而這些期待就成為效能改善的目標。

因此,在接下來的分享中,會設法經由更細膩的指標與工具來協助我們達成這些目標,也就是我們接下來想要來聊聊的主題「網站指標 Web Vitals」。

16

過去,我們在做網站的效能調校時,有很多很多的方法和目標。

但是,我們可能都會遇到一些難題,像是

所以,在這裡,我們可以根據使用者的期待來決定改善的目標,這個目標就是網站指標,就能讓我們有效地改善網站效能,進而以及改善使用者體驗。

17

Web Vitals 目前主要衡量三個面向,就是載入速度、載入互動性和視覺穩定性。

18

為什麼要選這三個方向呢?因為,對使用者來說

從剛剛小明的例子來看,這三個方向基本上就代表了是否能帶給使用者良好體驗的關鍵。

19

網站指標可以幫助我們了解網站的現況,與確認是否朝著正確的方向做改善,那麼,我們當然需要「工具」來協助我們做測量、給建議。

那麼,到底有什麼工具能幫助我們測量指標與調整網站狀態呢?基本上,Google 目前當紅的產品都可以偵測這些指標。

20

這些工具包含 Lighthouse、Chrome DevTools、PageSpeed Insights、CrUX 還有 Search Console。

這些工具,以及這些工具所蒐集得到的資料,分為兩種,就是模擬和實地。也就是說,對於這些指標的資料蒐集呢,我們分為兩種方式,模擬測量與實地測量。所以得到的資料也有兩種,就是模擬資料與實地資料

稍後我們會在一些實際範例中看到怎麼用這些工具,還有怎麼跟工作流程結合。

21

第一個我們要來看的面向,是關於載入速度的指標。

22

第一個要來看的指標是 first contentful paint,簡稱 FCP,中文是「首次顯示內容」,它是指「載入第一個可見元素所花的時間」,在這裡可以看到第一個可見元素是 loading icon,快速的 FCP 可確保使用者不是空等。

而隨著網頁的資源載入,就能看到這個頁面最重要的內容,這叫做 largest contentfaul paint,簡稱 LCP,中文是「最大內容繪製」,它是指「載入最大面積元素所花的載入時間」,通常是指網頁大圖或是最大的文字區塊,快速的 LCP 能讓使用者儘快確認該頁的資訊對他們是否有用。

如這張投影片所看到的,這個頁面在一開始載入時畫面上是什麼都沒有的,然後出現了 loading icon 暗示使用者網站仍在持續載入資源,接著出現搜尋框,並接著載入圖文區塊,最後顯示完整的網頁內容。

因此…

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 的狀況,我們做了以下四件事情的調整

27

在經過以上的調整後

28

在這裡比較特別的地方是,由於 CrUX 蒐集的資料是有流量門檻的,也就是說,小型的專案並不會被蒐集進去,那麽在 PageSpeed Insight 等這些由 CrUX 所提供資料的工具上就看不到這些網站的指標資料,在這邊有兩個選擇

在這裡 Mixtini 因為是小成本專案,所以就選擇了方便好用的 Firebase Performance 來幫我們蒐集指標資料。

29

第二個來看的實際例子是我現在所在的公司,趨勢科技的 DDD 產品。DDD 是我們家趨勢科技的產品,主要用於防禦網路攻擊。

30

在 DDD 專案中,在前端部份主要發現兩個問題

因此,在本次改善上,希望能達到以下兩點目的

31

針對載入效能不佳的狀況,經由 Lighthouse 檢測後,發現有很多很多問題,像是網路傳輸的檔案很大、瀏覽器的主執行緒常常在執行一些會花費比較長時間的任務等等問題。

在檢視這些問題後,我們發現核心的問題在於打包的檔案太大,導致網頁一次載入過多程式碼。也就是說,我們把網站裡面所有的程式碼基本上都打包成一大包。

32

為了解決打包檔案的問題,我們使用的改善策略是,我們要做 Route-based Code Splitting。

這個解法是說,設定 Webpack 的設定檔來針對 route 切分為不同的 chunk 與共用的 chunk。在畫面載入時除了載入共用與目前所在的 route 所需要的 chunk 之外,其他部份的程式碼會依照使用者瀏覽不同頁面時再動態載入。

33

在做以上這些改善後,我們用利用 Webpack Bundle Analyzer 檢視打包後的檔案大小與成效。

34

我們實測專案首頁的狀況下,發現

在這裡,由於減少載入程式碼體積,因此瀏覽器下載、解析與執行程式碼的時間也減少許多,有效改善載入效能,進而改善 FCP 與 LCP;更由於編譯時間變短,開發體驗更好,就能鼓勵開發者投入更多成本來維護專案。

35

本專案除了改善 DDD 的效能之外,同時也實作 STM 系統 synthetic monitoring system 合成監控系統,將效能改善加入工作流程。

我們的工作流程就變成

我們將 Lighthouse CI 整合至 CI/CD 工具中,每週對專案中的特定頁面做效能檢測,並將報告發給相關工程師來改善,而且定期檢測就能找出潛在的效能問題,避免上線後才發現重大缺陷。

36

第二個面向,我們要來看的指標是關於載入互動性的指標。

37

關於載入互動性的指標有三個,分別是 TTI、TBT 和 FID。

由於 FID 是在實地環境中蒐集而得的真實的使用者的資訊,因此我們若想要在自己的開發環境上重現問題或改進效能,會用 TBT 或 TTI 作為 proxy metrics 來協助改善載入互動性。

38

載入互動性的問題,也就是反應不夠即時的問題,通常原因是瀏覽器的主執行緒過於忙碌,所以減少主執行緒任務的數量或時間都有幫助。

39

接下來,我們要來看一個「露天拍賣」的實際的例子。露天拍賣是台灣規模最大的 C2C 電商網站,這次主要來看「手機版商品頁的問與答」。

40

在前端部份我們發現在畫面載入後,使用者若想要使用問與答功能,按下「我要提問」按鈕後,再輸入文字的文字框出現的反應時間是有點慢的。

41

在這裡關於「互動不夠即時」的解法,我們做的改進主要針對兩個方向:「加快取得資源的速度」和「減少瀏覽器主執行的負擔、精簡程式碼」。

具體來說,就是

42

在經過以上的調整後,在行動裝置上

43

最後第三個面向,我們要來看的指標是關於視覺穩定性的指標。

44

第一個來看 CLS,全名是 cumulative layout shift,中文是累計版位配置位移,是指測量在頁面的整個存活期間,每個可見元素位移分數的總和。

CLS 的算法是找出可視範圍內個別元素最大的影響範圍和最大的位移比例之總和。如這張投影片,一開始有兩個圖文區塊,然後廣告出現了,把圖文區塊擠下去。

因此

CLS 就是 2/9。

45

第二個有關於視覺穩定的指標,是比較偏向視覺流暢性,就是速度指數,全名是 speed index,簡稱 SI,是用來衡量網頁載入期間,內容在視覺上有多快能呈現在使用者面前,簡言之即是視覺上的「流暢性」。SI 的產生方式是利用瀏覽器的工具來錄製影片,針對每個 frame 所載入的畫面來計算完成度,最後再利用 Speedline Node.js 模組來產生 SI 的分數。

概念示意圖如這張投影片,由於 SI 是測量的是視覺的流暢性,因此是計算隨著時間推演,還剩下多少未完成的比率的總和,也就是這張圖藍色的部份。

46

造成視覺不穩定的原因,大致上有幾種

47

我們再次來看露天拍賣的例子。露天拍賣的手機版的問與答,我們還有發現另一個問題,就是此頁面的 CLS 偏高的。

利用 Lighthouse 與 ChromeDev Tools 的 Timeline 檢測,發現是 footer 在商品資訊和提問內容出現後不斷往下推移,而造成大量的位移。

48

露天拍賣的解法為

因此使用者在載入這個頁面時,便能看到商品資訊與提問內容是在固定的位置,而 footer 也不會一閃而過地不斷往下推移。

49

在經過以上的調整後,CLS 下降了 100 %,現在這個頁面是完全沒有任何不預期元素位移的。

50

我們來重新看一下針對使用者來制定的指標有哪些。這些指標,就是能幫助我們以使用者的角度來優化效能的目標。

51

並且,網站指標中最核心的部份稱為「核心網站指標 (core web vitals,簡稱 CWV)」,稱為「核心」的原因是

52

在工具方面,為了能有效利用指標來改善網站,我們勢必需要使用能測量網站指標的工具,並且結合工具與工作流程,將這樣的效能優化的方式融合進每天的工作當中

因此,產品生命週期上,建議結合工具與工作流程是這樣的

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

網站指標的未來會怎麼發展呢?

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,後來就拔掉了。

團隊合作的秘訣?(自選題)

利用「共同目標」也就是「提升使用者體驗」這件事情作為溝通的重心,因為客戶開心才會賺錢。

記得…不要急,要有耐心,循序漸進的前進,例如…

有什麼準備工作?(自選題)

重構 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 之一,蓋版廣告會影響使用體驗,導致使用者失去耐心、放棄瀏覽或不再造訪網站,那麼就會影響排名。

補充,影響排名的因子很多,不要希望經由改一兩項就可以提升排名。所以顧好基本功就變得很重要,可是要讓產品固好基本功是很困難的,通常都不是技術問題,比較多的是政治、資源成本考量的問題。

如何開始在工作中做效能調校?有簡單範例嗎?(他選題)

  1. 自己先做 side project,然後在工作的專案上從小功能開始做起。
  2. (打廣告) 之後歡迎看我的書,歡迎玩玩書上範例的公開在 GitHub 的 repository。

圖檔優化的 Image Server 怎麼實作的?(他選題)

目前在 Mixtini 是找現有的服務串 API 來做的,像是 Cloudinary。

怎麼實作 preconnect / dns-prefetch?(他選題)

小專案可以直接寫死在 HTML 上,大專案、需動態更新的就用 Webpack plugin「preload-webpack-plugin」來實作。


(歡迎大家補充遺漏的問答,感謝 🙏🏻)


comments powered by Disqus