幫助業務決策者改善 Core Web Vitals

瞭解業務決策者和非開發人員如何改善 Core Web Vitals。

經證實,網站使用者體驗對業務成果有直接影響。如果加快網站的載入和回應速度,讓使用者享有更優質的體驗,參與度與轉換率通常也會隨之提高。Core Web Vitals 計畫旨在量化網站使用者體驗,協助找出可改善的地方。

不過,許多網站體驗核心指標說明文件的適用對象為網站開發人員,他們對相關技術有深厚的瞭解,並能完全掌控自己的程式碼。許多網站是由非開發人員使用「網站製作工具」建立,不必仰賴網站開發團隊,

即使有專屬的團隊或網站開發人員,他們並非唯一負責網站效能的團隊。不論是決定內容和設計,還是擬定廣告策略,致力於提高網站流量,業務決策者對網站成效都有很大的影響。這類決策通常對網站效能有重大影響。

本指南旨在提供相關資訊,讓網站製作工具和網站擁有者不必具備網頁開發方面的深厚知識,也能瞭解並改善使用者體驗。

此外,許多效能問題需要開發人員實作技術修正,而我們的開發人員指南可協助您解決這個問題。這並非完整的指南,而是將介紹「Core Web Vitals」計畫的重點內容,並介紹給業務決策者,其中一些常見的非開發根本原因,是會導致網頁效能不佳的根本原因。除此之外,也可能需要網頁程式開發人員協助尋求進一步進展。

什麼是 Core Web Vitals?

Core Web Vitals 是一組用來評估網頁使用者體驗的指標,特別是網頁給予使用者網頁體驗的速度。每個項目都有三個字母縮寫:

  • 「Largest Contentful Paint (LCP)」會評估「載入」成效,也就是網頁開始載入後,最醒目內容需要多久 (以秒為單位) 顯示。
  • 累計版面配置位移 (CLS) 會評估網頁的視覺穩定性,也就是內容載入時所移動的程度。
  • 與下一個顯示的內容互動 (INP):網頁回應點擊、輕觸和鍵盤互動的速度。

每項指標都會評估不同使用者體驗的面向,Google 也會為每項指標提供建議門檻,並將低於門檻值的使用者體驗視為良好,高於上限門檻的使用者體驗就會視為不佳。如果達到上述門檻,系統會將網頁視為「需要改善」範圍。請記住,這些指標的值越小越好。

Core Web Vitals 指標的評估方式為何?

Core Web Vitals 評估依據是您網站的實際使用者,不同使用者會產生不同的結果。這些都不是「Google 的想法」也不是「googlebot 的想法」,而是你網站的實際使用者經驗。

部分使用者的裝置速度更快、網路速度更快。有些則採用速度較慢的裝置,或是網路連線速度較慢的裝置。有些使用者會在網站上瀏覽更簡潔、更快速的網頁,有些則瀏覽更複雜、速度較慢的網頁。然後匯總這些使用者體驗的結果,估算出您整個網站的整體成效。

Google 會在 Chrome 使用者體驗報告 (CrUX) 中收集選擇納入 Chrome 的使用者資料,並在許多 Google 工具 (例如 PageSpeed InsightsGoogle Search Console) 中存取這些資料。

可在數百萬個熱門網站中使用 CrUX,但並非所有網站都採用 CrUX。其他「即時使用者監控」(RUM) 工具也可以為您的網站收集這些指標。

如何找到網站的 Core Web Vitals?

有許多工具會顯示 Google 和第三方提供的 Core Web Vitals 指標。這篇文章將介紹兩項工具,協助您快速查看網站的 Core Web Vitals。如要進一步瞭解其他 Google 工具 (包括運用這些工具解決 Core Web Vitals 問題的工作流程),請參閱「搭配使用 Core Web Vitals 工作流程」一文。

如果您的平台提供整合式 RUM 解決方案,它可以針對您網站上的網頁提供更詳細的資訊,或者可讓您深入細查特定網頁或區隔使用者,以幫助瞭解並找出問題。

PageSpeed Insights

如要快速查看不需要設定的項目,可以使用 PageSpeed Insights (PSI)。輸入網址,然後按一下「分析」。如果網站已納入 CrUX 的涵蓋範圍,系統應會快速顯示「瞭解實際使用者的體驗」區段:

PageSpeed Insights 如何呈現網址 Core Web Vitals 的 CrUX 資料。Core Web Vitals 會個別顯示,並將每個 Core Web Vitals 歸類到「良好」、「需要改善」和「不佳」過去 28 天的門檻。
PageSpeed Insights 會顯示使用者實際體驗的 Core Web Vitals。

顯示過去 28 天內,實際 Chrome 使用者造訪網站的體驗。畫面頂端會顯示三個 Core Web Vitals,下方則會列出其他支援指標 (包括待處理的 INP 指標)。只有 Core Web Vitals 會採計在頁面頂端的整體通過/未通過評估的範圍內,但其他指標有助於排解 Core Web Vitals 相關問題,如下一節所示。

您可以使用這部分上方的按鈕,在行動版和電腦版檢視模式之間切換。您也可以使用右上方的切換按鈕,在「這個網址」與該「來源」之間進行切換 (其中有兩項資料都存在)。

這些數據應能帶您大致瞭解網站成效,以及哪些指標需要改進,以及哪些裝置在哪些類型的裝置上可以改進。

Google Search Console

Google Search Console (GSC) 僅供網站擁有者使用,因此需要註冊並驗證網站擁有權才能使用。這個頁面會提供詳細資料,讓你瞭解 Google 搜尋如何檢視你的網站。

GSC 與 PageSpeed Insights 不同,會列出 Google 搜尋在您網站上偵測到的所有網頁,並為這些網頁提供 Core Web Vitals 的詳細資料:

Search Console 中的 Core Web Vitals 報表。報表分為「電腦」和「行動裝置」類別,其中的折線圖會詳細列出網站體驗核心指標的網頁分佈情形,包括「良好」、「需要改善」和「不佳」
Google Search Console 網站體驗核心指標報表。

系統會將網頁彙整至網址群組,方便你查看特定類別的網頁 (例如產品詳細資料頁面、網誌網頁等) 是否有 Core Web Vitals 問題。這些頁面通常是根據類似的技術或範本建立而成,因此這些網頁容易發生問題。

網站製作工具的 Core Web Vitals 問題

許多效能問題都需要開發人員實作技術修正,而開發人員專用的指南可以協助開發人員解決這個問題。本節會探討業務決策者如何協助改善這些指標的常見非開發人員問題。

標示「非開發人員」時所謂的網站製作工具平台

最大內容繪製 (LCP) 問題

LCP 的目標是測量使用者點擊連結後,直到瀏覽器顯示大部分內容 (通常是橫幅圖片或標題) 的時間,藉此衡量網頁的載入速度

LCP 元素的網頁以綠色醒目顯示。
LCP 元素是網頁載入過程中的最大元素,在本例中以綠色標示。

為提供良好的網頁體驗,網頁應在使用者點選連結後的 2.5 秒內顯示內容。如果載入時間超過 4 秒,則視同「不佳」體驗。

以下各節將說明業務決策者可能會影響 LCP 的部分常見問題。

開始載入頁面時發生延遲

我們經常認為縮短網頁本身的載入時間,但通常要經過一段時間才會開始。如果網站未下載幾秒鐘,就不可能達到 2.5 秒正確門檻的 LCP!

「首次位元組時間」(TTFB) 是指網頁第一個部分的下載時間。如果 PageSpeed Insights 顯示大型 TTFB 診斷指標 (以紅色或琥珀色),表示解決這個問題,應該直接影響 LCP。

瞭解目標對象

遇到 TTFB 相關問題時,請務必瞭解你的目標對象。如果網站託管於某個國家/地區,但服務的目標對像是全球目標對象,那麼網站使用者和網路伺服器之間的地理位置就會成為網頁 TTFB 的其中一項因素。內容傳遞網路 (CDN) 可讓您將網站副本儲存在世界各地,以便更貼近使用者的需求。許多代管服務供應商將 CDN 視為其服務的一部分,因此會自動完成這項工作。檢查您的網站是否必須受到代管。部分平台提供不同級別的服務,並搭配更多 CDN 位置,提供給高級付費方案。在這種情況下,全球商家應考慮較高的等級。

將重新導向次數降到最低

重新導向是 TTFB 速度緩慢的另一個常見原因。在放送廣告活動或傳送電子郵件通訊時,請避免使用多個縮短連結或在需要重新導向的網址時,盡量減少重新導向的數量。舉例來說,在必須重新導向至 www.example.com/blog 的廣告活動中使用 example.com/blog,之後重新導向至 https://www.example.com/blog 會增加網頁的 TTFB 時間。確認行銷廣告活動使用最少的重新導向次數。

確保廣告活動指定了合適的目標對象

此外,也能確保廣告活動有效鎖定目標對象。許多人透過廣告吸引到世界各地 (但無法運送產品) 的新流量,不僅浪費廣告資金,網站成效也會下滑。

網址參數可能會影響網站效能

行銷廣告活動經常使用 Urchin 流量監視器 (UTM) 參數等網址參數。這種重新導向方式可以降低基礎架構中的快取效率,因為每個網址看起來都像是同一個網頁,但每次都會提供同一個網頁。如果您使用 Urchin 流量監視器 (UTM) 參數,請與 CDN 供應商或基礎架構團隊聯絡,確保快取基礎架構忽略這些網址參數,讓廣告活動受益於已快取的網頁。

媒體可能會耗用大量資源

請考量媒體對網頁的影響。圖片和影片等媒體通常比文字大上許多,因此需要較長的時間才能下載完成。這也會使頁面其餘部分的速度變慢。當 LCP 元素為媒體而非文字時,這一點尤其重要。LCP 元素是大約 80% 網頁內容上的圖片,因此務必考量媒體對網站的影響。

此外,比起以文字為主的網站,媒體素材資源可提供豐富的視覺體驗,比起以文字為主的網站更吸引人。因此,移除媒體並不容易,但需留意媒體費用,並思考如何降低,盡可能避免發生效能問題。

避免使用輪轉介面

如未以最佳方式呈現,由多張圖片組成的輪轉介面可能會影響網頁的整體載入時間,因為這類輪轉介面需要同時下載多張圖片。此外,由於輪轉介面無形,但通常無法提供良好的使用者體驗,因此在網站上使用輪轉介面前,請務必謹慎考慮。

使用針對網路最佳化的圖片

接著是媒體素材資源的大小。網路上的許多圖片都解析度過高。請確保媒體合作夥伴或設計代理商提供針對網路最佳化的圖片,而非他們經常提供的原尺寸列印品質圖片。你可以先透過 TinyJPG 等服務,快速清除圖片中不必要的資料,然後再上傳。許多網頁平台會試著自動最佳化上傳圖片時的圖片,但由於他們不知道這些圖片在使用者裝置上顯示的尺寸,因此建議您一開始就提供較小的圖片,才能大幅提升收益。

請謹慎處理影片

使用影片時應額外考量。影片是網站下載及顯示的最大型 (而且因此速度最慢) 的影片,因此請勿過度使用這些內容。避免在網頁最上方使用,而是儲存在網頁後面。如此可讓費用較低的內容快速載入,為使用者提供更優質的載入體驗,同時確保 LCP 不會受到影響。

A/B 版本測試

許多商家都會執行 A/B 版本測試,然後測試對網站所做的變更。實作方式可能會對 LCP 產生重大影響。

許多 A/B 測試解決方案會在網站首次向使用者顯示時延遲顯示,直到變更套用完畢為止。這樣能夠避免顯示原始版本的網站,但會導致網站對使用者的能見度有所延遲。其他解決方案則是在伺服器端套用,以避免出現延遲。請花一些時間瞭解 A/B 測試的執行方式,以及是否會發生延遲問題。此外,請盡量改用伺服器端 A/B 測試解決方案。

在執行新的變更之前,A/B 測試可提供寶貴的意見回饋,但網頁效能必須用在實際影響上。

無論您的基礎架構為何,執行 A/B 測試的所有人一律請謹記以下最佳做法:

  • 將 A/B 測試工具限制在測試中的網頁,不要延遲所有網頁,因為大多數網頁可能不會在任何特定時間執行 A/B 測試。
  • 只對部分使用者進行 A/B 測試,以免影響大多數使用者。
  • 請限制 A/B 版本測試提供決定性結果所需的時間。A/B 測試執行的時間越長,使用者瀏覽網頁效能所需的時間越長。
  • 最重要的是,別忘了視需要移除 A/B 測試實驗

累計版面配置位移 (CLS) 問題

CLS 會評估網頁的視覺穩定性,也就是網頁載入時內容隨時間移位的程度。如果使用者已經開始閱讀網頁,但之後卻因為插入了更多內容或廣告版位而失去位置,這可能會令人分心。此外,如果網頁的版面配置過度移動,使用者也可能會無意間點按錯誤的內容。請謹慎處理稍後載入的動態內容,且可能會移動部分初始網頁內容。

螢幕側錄說明版面配置不穩定會對使用者造成負面影響。

這個指標會使用數學公式計算,計算內容移動幅度和移動幅度。是以無單位分數表示,值 0.1 以下則視為 good,0.25 以上則視為

以下各節將說明業務決策者可能會影響 CLS 的部分常見問題。

檢查圖片在捲動頁面時的載入速度

許多範本都避免在網頁下方載入圖片,以便為網頁在初始載入期間顯示的圖片提供更多資源。隨後使用者向下捲動畫面時,這些圖片就會載入。這種圖片載入技術稱為「延遲載入」

頁面範本應保留空間給延遲載入的圖片,這樣一來,如果使用者在圖片載入之前就捲動速度相當快,周圍的內容就不會改變。如果您的範本或平台無法使用此功能,請考慮改用所需的範本或平台。

請謹慎處理內容中顯示的廣告

在內容中插入廣告可能會導致內容往下移,因為廣告通常需要較長的載入時間,比上一節描述的圖片還長。在主要網頁內容的側邊放置這兩種廣告,是可以降低風險的常見模式。實際達到的效果取決於您使用的平台,以及用於建立網站的範本。

避免在網頁頂端加入動態內容

避免在網頁載入後,在網頁頂端顯示快訊和橫幅 (例如 Cookie 橫幅或特價優惠)。如果在主要內容上方選擇重疊警示和橫幅,網頁內容就不會改變。與上一節類似,這裡的選項取決於您網頁使用的平台和範本。

與下一個顯示的內容 (INP) 問題互動

INP 會評估網頁的回應度,評估網頁是否快速回應點擊、輕觸和鍵盤輸入等互動。網頁無法快速回應使用者輸入要求,往往會讓使用者感到疲乏,進而讓使用者感到困擾。

回應速度不佳與良好回應的範例。左邊的任務很長,會讓這個指示無法打開。這會造成使用者多次點擊,造成體驗不佳。當主要執行緒接收到回應時,就會處理延遲的輸入內容,導致協調啟動及關閉。

INP 會評估網頁效期內每次有效互動的整體情況,並回報最差的互動。INP 的良好門檻為 200 毫秒,而「不正確」門檻為 500 毫秒。

回應指標 (尤其是 INP) 對進行最佳化來說是相當棘手的指標。如果這些指標低於門檻,通常是因為網頁嘗試過多而延遲互動,因此主要的解決方案是移除不必要的程式碼,用來建構精簡版網頁。

以下各節將說明業務決策者可能會影響 INP 的一些常見問題。

洗個春天吧!

檢查網站新增的外掛程式和小工具;如果有不再使用的外掛程式,請予以移除。新增外掛程式來試用的功能通常比較簡單,如果之後沒發現有用的外掛程式,請記得將其移除。這會導致互動速度緩慢,但最佳化方式比許多其他網頁來得簡單。

同樣地,如果您在行銷廣告活動使用代碼管理工具,請確認舊的廣告活動已移除。即使行銷廣告活動不再觸發,您還是需要在每個網頁上下載和編譯過期行銷廣告活動的程式碼,這可能會拖慢使用者初次載入網頁時的互動。

避免使用昂貴的小工具和外掛程式

運算成本高昂的小工具和外掛程式或許看起來很棒,但它們能否改善使用者體驗,還是反過來?PageSpeed Insights 的「診斷效能」報表是由 Lighthouse 提供,可協助您找出網站效能有顯著影響的 JavaScript。

在理想情況下,請只在需要的網頁加入小工具,如果您只在「與我們聯絡」網頁上使用 Google 地圖嵌入,就不需要在每個網頁上載入小工具,以免引發回應速度問題。

考量廣告數量,尤其是在行動裝置上

對許多商家來說,廣告是理想的營利策略,但往往相當複雜且耗費資源。您放送的廣告越多,廣告消耗的資源就越多,對網頁載入速度造成乾擾。在行動裝置上更是如此,因為在行動裝置中,處理電力記憶體通常不如桌機或筆電那麼好。

在營利與成效之間取得平衡。

在營利與成效之間取得平衡。如果使用者因為體驗不佳而放棄瀏覽,這些多出的廣告所產生的收益可能會多於增加的收益。

避免頁面大小過大

大型的複雜頁面需要較長的處理時間才能顯示。舉例來說,假設您的產品圖片庫有 1,000 種不同產品,使用者需要花費一些時間才能在瀏覽器視窗中顯示。請思考在何時分頁分頁以縮短時間。

如何取得進一步協助?

這篇文章列出業主可能影響成效的一些一般注意事項。此外,您可能也需要諮詢網頁程式開發人員,以深入瞭解如何改善網站效能。

平台專屬資訊

大多數平台非常關心網站效能,對改善方式可能會有針對特定平台的專屬建議。您也可以在平台中獲得專屬的網頁成效團隊,由他們進一步提供改善網站的建議。

Lighthouse 也可使用 Stack Pack 功能顯示平台特定資訊,指示支援平台的使用者取得適當的建議。

平台會持續改善,其中許多平台目前正專注於效能和 Core Web Vitals。請確保平台保持在最新狀態,享有平台開發人員的最新改善功能。

Google Cloud 的代管平台可自動管理平台,包括平台更新。如果您是自行代管平台 (例如在自己的伺服器上安裝本機 WordPress),那麼請確保平台定期更新,網站才能從開發人員實作的平台中受益。商家應優先處理這項作業,或選擇管理這項設定的服務。

與網頁程式開發人員交流

具備網站效能專業知識的網頁程式開發人員,可能比業主還要解決更多問題。您或許已經請網頁程式開發人員代為架設網站,或者定期進行變動;您或許會有專屬的開發團隊,或是需要請開發人員協助 (最好是具備網站效能專業知識的開發人員)。

如果此處提供的建議不足以解決網站的效能問題,請向開發人員尋求協助。雖然上述範例也顯示,和開發人員合作十分重要,因此在業務優先要務與開發決策之間取得平衡,能夠為網站採用合適的解決方案。

請注意,網站效能通常不是一蹴可幾的事情。維持網站維持良好效能通常需要定期監控和維護,才能確保網站改善後不會退化。

結論

網站通常是客戶的第一個進入點,希望網站提供他們便利的使用體驗。這項原則適用於初次接觸您商家的初次訪客,以及回訪者和忠實客戶。他們應該盡可能提供流暢的體驗,不讓使用者感到困擾,避免產生負面印象。網站體驗核心指標是 Google 建議網站考量的使用者體驗之一。網路提供諸多功能,如果對您的網站感到不悅,使用者能夠 (而且絕對不能) 嘗試其他的網站。

同時,「Core Web Vitals」報告只是網站的一部分。商家必須自行決定網站投資金額及投資報酬率。

特別銘謝

縮圖圖片是由 Carlos Muza 提供的 Unsplash 提供