導讀《打造高速網站,從網站指標開始!全方位提升使用者體驗與流量的關鍵》逐字稿@新竹敏捷

導讀《打造高速網站,從網站指標開始!全方位提升使用者體驗與流量的關鍵》逐字稿@新竹敏捷。

導讀《打造高速網站,從網站指標開始!全方位提升使用者體驗與流量的關鍵》逐字稿@新竹敏捷。

不知道逐字稿在幹嘛?歡迎對照

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

過去,我們在做網站的效能調校時,有很多很多的方法和目標。但是,我們可能都會遇到一些難題,像是

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

9

Web Vitals 目前主要衡量三個面向,就是載入速度、載入互動性和視覺穩定性。為什麼要選這三個方向呢?因為,對使用者來說

10

目前測量使用者對於效能感知的網站指標,

11

網站指標中最核心的部份稱為「核心網站指標(core web vitals,簡稱 CWV)」,核心網站指標有 LCP、FID 與 CLS,稱為「核心」的原因是這三個指標能被實際測量以具體反應真實體驗結果,並且具體代表使用者體驗的特定面向。

12

網站指標可以幫助我們了解網站的現況,與確認是否朝著正確的方向做改善,那麼,我們當然需要「工具」來協助我們做測量、給建議。那麼,到底有什麼工具能幫助我們測量指標與調整網站狀態呢?基本上,Google 目前當紅的產品都可以偵測這些指標。

13

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

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

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

14

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

15

我們來看一個實際的例子 Mixtini。

Mixtini 是一個推廣調酒與酒吧的線上服務網站。由於 Mixtini 的首頁以大圖並多圖的方式呈現,這個網站的首頁的 FCP 與 LCP 不論在桌機或是手機上其實都滿高的。首頁是使用者對此網站的第一印象,因此改善載入效能就成為當務之急。

16

影響 FCP 和 LCP 的原因是資源載入的速度,歸納起來是有三個原因:禁止轉譯的資源、伺服器回應速度過慢或資源載入過慢,這三個原因就成為我們優化載入速度的方向與目標

17

因此,針對 Mixtini 的狀況,我們做了以下四件事情的調整

18

在經過以上的調整後

19

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

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

20

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

21

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

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

22

針對載入效能不佳的狀況,經由 Lighthouse 檢測後,發現有很多很多問題,像是

等等問題。

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

23

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

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

24

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

25

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

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

26

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

在打包專案程式碼之後,會用 Lighthouse CI 檢測效能。關於這部分,我們會檢測專案內,特定網頁的狀況,並且針對 Lighthouse 的建議做調整。之後在產品上線後,會蒐集資訊與驗證成效。由於產品並非公開網站,因此不會使用 CrUX 蒐集資訊,而是經由 onsite 測試來做驗證。我們將 Lighthouse CI 整合至 CI/CD 工具中,每週對專案中的特定頁面做效能檢測,並將報告發給相關工程師來改善,而且定期檢測就能找出潛在的效能問題,避免上線後才發現重大缺陷。

27

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

28

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

29

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

30

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

31

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

32

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

33

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

34

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

35

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

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

36

露天拍賣的解法為

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

37

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

38

以上看完了指標和工具,那麼,我們該怎麼將效能優化融合進每天的工作當中呢?

39

產品生命週期上,建議的工作流程是這樣的

40

這樣就結束了嗎?那讓我們來看看關於 SEO 這個議題。

從 Search Console 的網頁體驗報告可知,所謂「曝光數」是指品質良好的網址被搜尋到的總次數,意即「流量來自於具有良好品質的網頁」,因此,若想讓網頁提高曝光率,依照網站指標來改善網頁品質、提升使用者體驗是絕對必要的。

但是,要做好搜尋引擎優化的工作,基本功不可少 —— 好的內容與關鍵字、良好的網頁結構、圖文並茂、對機器人好爬、對內與對外連結、網站效能、支援行動裝置等,綜合以上才會是做好搜尋引擎優化的工作,進而能讓網站排名提升。

41

最後,我們來看看結論…

42

覺得優化效能很困難嗎?

43

第一,從前面的實際例子,我們可以知道,只要抓對問題,小小的更動也是有很大的效果

第二,因為是針對使用者體驗,所以不再讓優化效能這件事霧裡看花、好像改了卻沒感受到任何效果

44

再來,專案時程很緊嗎?

45

那就試試看把效能優化的工作切小,然後讓工具幫幫忙,並且融入工作流程中,成為功能開發的一部份,這樣就能試著讓煩瑣龐大的工作變得能夠輕易完成

46

最後,團隊很難合作嗎?

47

相較於傳統效能的調整與測試,網站指標給予不同角色的人有「提升使用者體驗」的共同目標、凝聚大家的共識,較容易溝通,也因為共識而改變工作模式,凸顯效能調校的重要,而不是只做功能的開發。

48

以上是我的分享,非常感謝大家的參與。

若對於以上主題有興趣,歡迎讀讀我的書!

再次感謝大家!