谷歌的使命是通過Core Web Vitals來提高網路效能。為什麼？因為谷歌的業務主要是基於網路的——緩慢的網站和網路應用程式將使用者推回到本地應用程式。
你在谷歌搜尋結果中的位置在很大程度上取決於搜尋詞的關鍵詞、這些關鍵詞在你頁面中的使用情況，以及根據其他地方連結的數量（和質量）你頁面的受歡迎程度。從2021年8月開始，谷歌也在努力根據效能評估頁面。
本教程將向您展示如何針對谷歌Core Web Vitals優化您的網站。
為什麼要做Core Web Vitals？
內容仍然至關重要。但是，如果你比較兩個文字和人氣相似的網站，在谷歌搜尋結果中，提供最佳網路體驗的網站將獲得更高的優先順序。
除了提高頁面排名外，高效能網站也有資格加入移動搜尋轉盤。這之前是為加速移動頁面（AMP）保留的，它要求您將內容匯入一個單獨的谷歌託管站點。AMP已經引起了批評，尤其是因為頁面並不總是比優化良好的WordPress或靜態站點更快。然而，這不再是一個要求。
無論你選擇了什麼，你的網站越快，響應速度越快，它在谷歌搜尋結果中排名越高的機會就越大。
當你認為平均頁面大約是2 MB時，生成超過60個HTTP請求，並且在移動裝置上充分渲染16秒，你會發現有一些改進你的站點的範圍。我們將向您展示實現這些改進的最佳方法。
谷歌的主要排名因素
在開始評估績效之前，需要檢查四個關鍵排名因素：
- HTTPS：HTTPS是必不可少的。您的站點是否在使用者的瀏覽器和Web伺服器之間建立了安全連線？
- 移動友好性：你的網站必須在移動裝置上執行良好。您的站點在小螢幕裝置上可用嗎？它呈現時沒有內容溢位嗎？文字夠大嗎？可點選區域是否足以進行觸控控制？
- 無間隙：避免需要不合理螢幕空間的侵入性間隙。你的內容總是可讀的嗎？是否部分被彈出的間隙或橫幅遮擋？您的廣告或市場推廣是否使網站難以使用？
- 安全瀏覽：您的網站應該沒有惡意軟體、病毒、網路釣魚、欺詐和其他欺詐。
一旦您滿足這些要求，您的網站將進行效能評估。
谷歌如何評估網站效能？
使您的網站載入速度快、渲染速度快、響應速度快是至關重要的。但它對使用者來說感覺快嗎？
效能度量應用程式（如瀏覽器開發工具）報告技術度量，例如：
- 阻塞時間：等待下載開始所花費的時間，通常是因為樣式表和指令碼等其他資產具有更高的優先順序。
- DNS解析：將主機名解析為IP地址以檢索資產的時間。
- 連線時間：初始化TCP連線的時間。
- 首位元組時間（TTFB）：請求和響應的第一個位元組之間的總時間。
- 接收時間：檢索整個資產的時間。
- DOM載入時間：下載和呈現HTML文件物件模型的時間。這通常是分析或修改DOM的指令碼可以可靠執行的第一個點。
- 頁面載入時間：下載頁面和所有資產（如影象、樣式表、指令碼等）的時間。
- 總頁面重量：所有資產的總大小。通常報告為壓縮（下載）大小和未壓縮大小。
- DOM元素數：頁面上HTML元素的總數。元素越多，頁面處理時間越長。
- 首次內容繪製 （FCP）：瀏覽器渲染第一個內容畫素之前所用的時間。
- 首個有意義繪製（FMP）：主頁內容對使用者可見之前所花費的時間。
- 互動時間（TTI）：頁面完全互動並能夠可靠響應使用者輸入所需的時間。
- 首次CPU空閒（FCI）：CPU呈現頁面並執行所有初始化指令碼，等待進一步輸入的時間。
- CPU使用率：呈現頁面和響應使用者輸入時所需的處理活動。
- 每秒佈局數：瀏覽器必須重新計算樣式和頁面佈局的速率。
這些可用於確定特定的瓶頸，如伺服器負載、CMS快取、瀏覽器快取、下載速度和JavaScript效率。但他們無法確定頁面提供的使用者體驗是好是壞。例如：
應用程式可以快速下載並顯示，但在第一次互動後會變得無響應，因為它正在執行大量未優化的JavaScript程式碼。
聊天應用程式可以在使用者釋出訊息時不斷下載資料。評估工具可能會假定它從未完成載入，儘管頁面感覺有響應。
Core Web Vitals 是谷歌試圖解決這些困境。
什麼是 Core Web Vitals?
Google的Core Web Vitals（CWV）是評估現實世界使用者體驗的三個效能指標：
- 最大內容繪製（LCP）：載入效能
- 首次輸入延遲（FID）：互動效能（Update：2024 年 3 月 12 日，INP 被新增到 Core Web Vitals 框架中，取代了舊的首次輸入延遲 FID 指標。）
- 累積佈局偏移（CLS）：視覺穩定性效能
到2021年8月底，谷歌新的演算法更新已經開始在全球範圍內推廣。Core Web Vitals主要影響移動搜尋結果，但如果實驗成功，桌面等價物也會隨之產生。
頁面的LCP、FID和CLS分數基於最近28天通過Chrome瀏覽器匿名收集的真實使用者指標。由於使用者的裝置、連線和其他併發活動，這些測量值可能會有所不同，因此第75個百分位是計算出來的，而不是平均值。
換句話說，所有使用者的指標都是從最好到最差排序的，並且取四分之三點的數字。因此，四分之三的網站訪問者將體驗到該級別或更高的效能。
任何在所有三個核心網路關鍵指標上都獲得良好（綠色）分數的頁面都將在搜尋結果中獲得更高的排名，並被包括在谷歌新聞應用程式的“熱門故事”旋轉木馬中。
在以下部分中，我們將介紹用於計算度量的演算法、可用於確定頁面分數的工具、分數低的典型原因以及解決效能問題的步驟。
最大內容繪製（LCP）
最大內容繪製測量載入效能。本質上，可用內容在頁面上呈現的速度有多快？
根據同一份 Chrome 瀏覽器 Core Web Vitals 報告，64.8% 的網站已經達到了 LCP 分數。而且每月都有更多新網站以更快的速度提供主要內容。
LCP分析最大影象或文字塊在瀏覽器視口（摺疊上方）中可見所需的時間。在大多數情況下，最突出的專案將是Hero影象、橫幅、標題或大型文字塊。
以下任何元素均可進行最大含量的油漆分析：
- 影象（
<img>元素） - 向量圖形中的影象（嵌入到
<svg>中的<image>） - 視訊縮圖（海報屬性設定為
<video>元素中的影象URL） - 具有背景影象的元素（通常使用CSS
background-image url()屬性載入） - 包含文字的塊級元素
在頁面載入的前2.5秒內完成最大內容繪製的頁面視為良好（綠色）。超過4.0秒的頁面視為不良（紅色）：
最大內容繪製（LCP）
最大內容繪製分析工具
LCP是最容易理解的Core Web Vital，但選擇哪個元素進行分析可能並不明顯。
DevTools Lighthouse面板在基於鉻的瀏覽器中提供，如Chrome、Edge、Brave、Opera和Vivaldi。從瀏覽器選單中開啟DevTools–通常位於“更多工具”>“開發人員工具”或鍵盤快捷鍵Ctrl | Cmd+Shift+I或F12–然後導航到Lighthouse選項卡（舊版本可能會將其命名為Audit）。
生成移動效能報告，然後檢查生成的效能部分。最大內容繪製時間顯示為可展開部分，該部分標識所選元素：
DevTools Lighthouse移動效能報告
如果您無法訪問基於Chromium的瀏覽器，則可以在訪問PageSpeed Insights和web.dev Measure tools中生成相同的資訊：
PageSpeed Insights執行LCP分析
DevTools效能面板還顯示LCP指示器。要開始，請單擊迴圈記錄圖示，重新載入頁面，然後單擊停止按鈕檢視報告。單擊“計時”部分中的LCP圖示以標識元素並檢視統計資訊摘要。
DevTools效能面板LCP指示器
Web Vitals擴充套件可用於Google Chrome，但可以安裝在大多數基於Chrome的瀏覽器上。它為您訪問的每個站點計算核心Web關鍵指標，其圖示根據結果變為綠色、橙色或紅色。您還可以單擊擴充套件圖示檢視更多LCP詳細資訊：
Web Vitals擴充套件LCP
Google’s Search Console現在提供了Core Web Vitals部分，如果你的網站是作為屬性新增的。該報告說明了CWV指標是如何隨時間變化的。請注意，它沒有確定具體的LCP指標，只有具有合理高流量的站點可用：
谷歌搜尋控制檯Core Web Vitals
Chrome使用者體驗報告允許您查詢特定URL的實際使用統計資料，包括不同國家、連線和裝置的LCP。這是Google BigQuery上的一個公共專案，所以您必須註冊一個Google雲平臺帳戶並提供賬單詳細資訊。同樣，報告只有在URL具有相當高的流量水平時才有用。
最後，web-vitals JavaScript庫是一個1KB的小指令碼，可以為您的實時站點上的真實使用者計算LCP和其他核心web重要指標。由於可以從CDN下載，您可以將以下指令碼新增到HTML中的<head>：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP()是一個非同步函式，在計算LCP值時會觸發回撥（但如果在後臺選項卡中載入頁面，則可能永遠不會觸發回撥）。向回撥函式傳遞一個物件，該物件包含：
name：度量的名稱（本例中為“LCP”）value：計算出的值id：表示當前頁面的此度量的唯一iddelta：當前值與上次報告值之間的增量entries：值計算中使用的條目陣列
上面的指令碼將物件輸出到控制檯，不過將資料傳送到伺服器或Google Analytics進行進一步分析更為實際。
LCP分數低的常見原因
LCP分數差通常是由阻塞最大塊快速出現的緩慢載入頁面造成的：
- 在客戶端上生成的頁面內容，而不是伺服器上生成的內容也需要更長的時間才能顯示出來。
- 伺服器響應可能會很慢，因為它超載或做了太多工作來呈現頁面。這可能不一定是您的站點的錯誤-如果您使用的是共享託管服務，則可能是由於伺服器限制。
- 如果在主內容上方的HTML中引用了呈現阻塞CSS和JavaScript，則它們可能會延遲頁面載入。
- 其他資源（如大型影象和視訊）可能會減少可用頻寬，並需要更長的渲染時間。
在客戶端而不是伺服器上生成的頁面內容也需要更長的時間才能顯示。
如何提高LCP分數
徹底的審查可以發現載入問題，但通常是減少傳送到瀏覽器的資料量的問題。以下提示將有助於獲得更健康的LCP分數：
- 升級伺服器和/或主機服務。確保下載速度即使在高使用率時也保持快速。
- 啟用伺服器壓縮和HTTP/2+。沒有理由不這樣做！
- 減少伺服器工作。刪除未使用的程式碼和CMS外掛，然後啟用有效快取。
- 確保瀏覽器可以有效快取檔案。在HTTP頭中設定適當的Expires、Last Modified和/或ETag雜湊，以便不再請求檔案。
- 使用內容交付網路（CDN）在地理位置更靠近使用者的伺服器上拆分負載和託管資源。
- 優化你的影象。將它們減少到最小尺寸，並使用適當的格式來最小化檔案大小。確保儘早請求最大內容塊中的任何影象；預載入可能會有所幫助。
- 通過新增
loading="lazy"屬性延遲載入影象。新增寬度和高度屬性，以確保在影象完成載入之前在頁面上保留適當的空間。 - 最小化第三方請求，並將移動資產考慮到主域以避免無關DNS查詢。
- 最小化請求檔案的數量和大小，尤其是在HTML的頂部。
- 確保僅載入所需的web字型。切換到web安全字型以獲得最佳效能。
- 刪除未使用的JavaScript和CSS檔案。
- 連線並縮小JavaScript和CSS檔案。
- 避免CSS@import語句-它們是串聯的渲染塊和載入樣式。
- 避免Base64編碼-它會增加檔案大小並需要額外的處理。
- 考慮關鍵的聯機CSS。在頁面頂部的
<link>塊中嵌入基本的“摺疊上方”CSS，然後非同步載入更多樣式表。 - 稍後使用非同步、延遲或ES模組JavaScript執行指令碼。在服務工作者中執行長時間執行的JavaScript程序。
首次輸入延遲（FID）
首次輸入延遲（FID）測量頁面的響應性。本質上，它對使用者的點選、點選和滾動等操作的響應速度有多快？
FID指標計算為使用者互動和瀏覽器處理其請求之間的時間。它不度量執行處理程式函式的時間，處理程式函式通常會處理輸入並更新DOM。
FID時間小於等於100毫秒的頁面視為良好（綠色）。超過300毫秒的頁面視為不良（紅色）：
首次輸入延遲
Info：
2024 年 3 月 12 日，INP 被新增到 Core Web Vitals 框架中，取代了舊的首次輸入延遲（FID）指標。FID 只衡量使用者的首次互動，而 INP 則關注整個頁面訪問過程中的所有互動。
Chrome 瀏覽器報告資料顯示，85% 的網站已經獲得了良好的 INP 分數。如果您能很好地優化網站的前兩個分數，那麼 INP 分數也會很高。
為了讓使用者滿意並參與其中，請將 INP 的目標設定為 200 毫秒或更低。如果您的 INP 在 200 至 500 毫秒之間徘徊，那麼您就有一些工作要做了。
如果超過 500 毫秒，您就會給訪問者帶來撥號上網的體驗。
首次輸入延遲分析工具
首次輸入延遲是不可能模擬的，因為它只能在頁面提供給與頁面互動的實際使用者時測量。因此，結果取決於每個裝置的處理器速度和能力。
FID不在DevTools Lighthouse面板或PageSpeed Insights中計算。但是，它們可以確定總阻塞時間（TBT）。這是第一個輸入延遲的合理近似值。它測量以下各項之間的時間差：
- 首個內容繪製（FCP），或頁面內容開始呈現的時間，以及
- 互動時間（TTI），或頁面可以響應使用者輸入的時間。當沒有長時間執行的任務處於活動狀態且尚未完成的HTTP請求少於三個時，假定為TTI。
PageSpeed Insights總阻塞時間
Google Chrome的Web Vitals擴充套件也可以在通過滾動或單擊與頁面互動後顯示FID度量。單擊擴充套件的圖示以顯示更多資訊：
Web Vitals擴充套件FID
與LCP一樣，Chrome使用者體驗報告允許您查詢在不同國家、連線和裝置上記錄的特定URL的真實FID統計資料。
web vitals JavaScript庫還可以計算實時站點上真實使用者的FID指標。您可以將以下指令碼新增到HTML的<head>以將FID度量輸出到回撥函式：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
FID分數低的常見原因
FID和TBT分數低通常是由佔用處理器的客戶端程式碼引起的，例如：
- 大量的呈現阻塞CSS和JavaScript，這會在下載和解析程式碼時停止頁面載入
- 載入頁面時立即執行的大型流程密集型指令碼
- 長時間執行或優化較差的JavaScript任務
預設情況下，瀏覽器執行在單個執行緒上，一次只能處理一個任務。如果一個JavaScript函式需要一秒鐘的時間來執行，那麼所有其他渲染過程都會在這一秒鐘內被阻塞。頁面無法響應使用者輸入、更新DOM、顯示動畫等。甚至GIF動畫也可以在舊瀏覽器中被阻塞。
如何提高FID分數
客戶端JavaScript審計可以識別問題，但通常需要刪除冗餘程式碼並確保任務快速執行。
以下提示將有助於獲得更健康的FID分數：
- 在伺服器上生成並快取儘可能多的靜態HTML內容。儘量不要依賴客戶端JavaScript框架為每個人呈現相同的HTML。
- 確保瀏覽器可以有效快取檔案。在HTTP頭中設定適當的Expires、Last Modified和/或ETag雜湊，以便不再請求檔案。
- 採用漸進式增強技術，因此在JavaScript執行之前，該介面可以在HTML和CSS中使用。
- 刪除未使用的JavaScript和CSS檔案。
- 連線並縮小JavaScript和CSS檔案。
- 避免過度使用昂貴的CSS屬性，如框陰影和過濾器。
- 稍後使用非同步、延遲或ES模組JavaScript執行指令碼。
- 最小化對分析、社交媒體小部件、論壇等的第三方JavaScript請求。這些請求可以快速載入到數兆位元組的JavaScript。
- 根據需要延遲載入JavaScript元件，例如聊天視窗小部件、視訊播放器等。
- 延遲載入不太重要的指令碼，如分析、廣告和社交媒體工具。
- 將長時間執行的JavaScript任務分解為一系列較小的作業，這些作業在短時間的requestIdleCallback、setTimeout或requestAnimationFrame延遲後執行。
- 考慮在Web工作者中使用一個後臺執行緒來執行長時間執行的JavaScript程序。
累計佈局偏移 （CLS）
CLS測量頁面的視覺穩定性。本質上，頁面內容是否會意外移動或跳轉，尤其是在初始載入期間？
當元素在沒有警告或使用者互動的情況下移動時，CLS計算分數。當你在移動裝置上閱讀一篇文章時，你可能已經體驗到了這一點——文字突然跳出螢幕，你失去了位置。最糟糕的例子可能會導致您單擊錯誤的連結。
當一個大的影象或廣告載入到當前滾動位置之上，並且零高度空間立即增加數百畫素時，CLS問題最為突出。
通過將以下指標相乘計算累積佈局輪班分數：
- 影響分數：這是視口中所有不穩定元素的總面積，即那些將“跳躍”的元素。如果覆蓋60%視口的元素在頁面載入期間發生位移，則影響分數為0.6。請注意，導致移動的元素（例如影象或廣告）被認為是穩定的，因為它們在渲染後不一定移動。
- 距離分數：這是視口中任何單個不穩定元素移動的最大距離。如果最大位移發生在從0100移動到0800的元素上，則該元素已移動700個垂直畫素。如果裝置視口的高度為1000 px，則距離分數為700 px/1000 px=0.7。因此，計算的累積佈局輪班分數為0.6 x 0.7=0.42。
谷歌對CLS指標進行了修改，以適應以下情況：
佈局移位被分組為“會話”，持續5秒，但如果沒有進一步的佈局移位，則在1秒後關閉。如果在一秒鐘內發生兩次或兩次以上的輪班，則將其分數相加。
使用者互動（如單擊）後500毫秒內不會記錄佈局移動。在某些情況下，這會觸發DOM更新（例如開啟選單、顯示錯誤訊息、顯示模式對話方塊等）。
單頁應用程式在更長時間內保持開啟狀態並進行大量DOM更新，不會受到不利影響。
CLS分數為0.1或更低的頁面視為良好（綠色）。超過0.25的頁面被視為較差（紅色）：
累積佈局偏移
截至 2024 年 9 月，78.2% 的網站獲得了良好的 CLS 分數，且逐月持續增長。這表明，越來越多的開發人員將流暢、無偏移的使用者體驗放在首位。
因此，如果您希望獲得穩定的使用者體驗，請將 CLS 分數控制在 0.1 或以下。如果超過 0.25，使用者就會感覺整個頁面都在移動。
累積佈局偏移分析工具
CLS度量在DevTools Lighthouse面板、PageSpeed Insights和web.dev Measure工具中計算：
PageSpeed Insights CLS
Google Chrome的Web Vitals擴充套件還顯示了CLS指標：
Web Vitals擴充套件CLS
與LCP和FID一樣，Chrome使用者體驗報告允許您查詢在不同國家、連線和裝置上記錄的特定URL的真實CLS統計資料。
web-vitals JavaScript庫還可以為實時站點上的真實使用者計算CLS指標，就像LCP和FID一樣。可以將以下指令碼新增到HTML的<head>以將CLS度量輸出到回撥函式：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
累積佈局偏移分數低的常見原因
CLS分數低通常是由於載入頁面資產和動態或未調整大小的DOM元素速度慢造成的：
- 頁面上的空間不用於影象、iFrame、廣告等。
- 內容被動態地注入DOM，通常是在網路請求廣告、社交媒體小部件等之後。
- Web字型載入會導致不可見文字（FOIT）或未設定樣式文字（FOUT）的明顯閃爍。
如何提高累積佈局偏移分數
客戶端審計可以發現問題，但通常是確保在內容下載之前為內容預留空間。為最大內容繪製建議的伺服器優化提示將有一些好處，但可能會有進一步的改進：
- 在HTML的
<img>和<iframe>標記中新增寬度和高度屬性，或者使用新的CSS縱橫比屬性確保在下載資產之前在頁面上保留適當的空間。 - 為封裝第三方內容（如廣告和小部件）的容器元素設定適當的尺寸。
- 確保儘早請求顯示在頁面頂部的影象和其他資產-預載入可能會有所幫助。
- 儘量減少Web字型的使用，並考慮在可能的時候使用常用的OS字型。
- 載入web字型並將CSS字型顯示設定為可選或交換。確保使用大小相似的回退字型，以最小化佈局偏移。
- 避免向頁面頂部插入元素，除非頁面響應使用者操作（如單擊）。
- 確保在輸入觸發器的500毫秒內完成使用者互動。
- 使用CSS變換和不透明度可以獲得更高效的動畫，而不會導致重新佈局。
- 考慮關鍵的聯機CSS。在頁面頂部的
<link>塊中嵌入基本的“摺疊上方”CSS，然後非同步載入其他樣式表。 - 必要時，考慮包容，一種新的CSS特性，允許您識別頁面的孤立子樹。瀏覽器可以通過渲染或不渲染特定的DOM內容塊來優化處理。
如何衡量Core Web Vitals
在前面 Core Web Vitals 的核心關鍵點我們已經詳細說明每一個關鍵點的分析工具。總而言之，在開始努力提高 Core Web Vitals 之前，最好先了解一下網站目前的狀況。這樣，您就能衡量自己的進步。定期評估得分是網站維護工作的重要組成部分。
讓我們來看看衡量網站效能的幾種不同方法。
PageSpeed Insights
您可以使用一些線上工具來衡量核心網站活力，包括 Pingdom 和 GTmetrix。不過，我們推薦使用 Google PageSpeed Insights 。
要開始使用，請輸入您網站的 URL，然後點選 Analyze 按鈕。
分析完成後，它會提供一些關鍵資料的摘要和網站的核心網路活力資料。如上圖所示，預設的谷歌網站有
- LCP: 0.7 秒
- INP: 63 毫秒
- CLS: 0
PageSpeed Insights 會同時測試移動和桌面得分，你可以在進入網站的下方進行切換。
如果進一步滾動，您還會發現一些診斷結果和改進建議。根據網站的得分，PageSpeed Insights 會提供一些建議，供你用來提高得分和改善網站效能。
Chrome 瀏覽器使用者體驗報告
您還可以通過 Chrome 瀏覽器使用者體驗報告訪問您的 Core Web Vitals。這對開發人員和網站管理員特別有幫助。
該報告可通過 Google Search Console 獲取，提供來自訪客的真實資料和見解。它可以幫助你瞭解使用者是如何使用網路並與網站互動的。
要檢視該報告，您需要前往 Google Search Console 的控制面板。然後，導航到位於 Experience 部分下的 Core Web Vitals。
Core Web Vitals 的 Chrome 擴充套件
如果您是 Chrome 瀏覽器使用者，可以使用 Web Vitals Chrome 擴充套件來評估您在任何網站上的核心網路體驗。
只需將擴充套件新增到 Chrome 瀏覽器，就可以開始使用了！
下次訪問網站時，只需點選頁面頂部的擴充套件圖示，就能看到該網站的 Core Web Vitals 分數。
以下是該擴充套件的輸出結果：
您無需每次訪問 PageSpeed insights 頁面，就能一目瞭然地看到 LCP、CLS 和 INP 分數。
如何提高 Core Web Vitals 以獲得更好的 Google 分數？
既然我們已經掌握了基礎知識，那就讓我們再次歸納一些提高 Core Web Vitals 評分的最佳做法。請記住，這不僅僅是為了給谷歌留下深刻印象，而是為了建立一個讓訪客喜歡使用的網站。
1. 使用現代影象格式
我們是視覺動物，但如果壓縮不當，那些漂亮的高解析度圖片會影響網站效能。
你需要優化圖片，然後將優化後的圖片上傳到網站，而不是使用伺服器端解決方案。
為了解決這個問題，使網路速度更快，谷歌推出了 WebP 格式。它保留了大量影象細節，同時大大縮小了影象尺寸。
WebP 可以作為照片和複雜影象的首選格式。它比 JPEG 或 PNG 有更好的壓縮效果，這意味著你可以在不犧牲質量的情況下獲得更小的檔案大小。WebP 影象比 JPEG 影象小 30%。因此，你可以節省大量頻寬和載入頁面所需的時間。
我們喜歡使用 Squoosh 將圖片轉換為WebP，或者壓縮圖片以節省空間。
以下是一些值得考慮的其他影象優化外掛：
除了 WebP，我們還建議使用 SVG 來製作圖示、徽標和插圖。
SVG（可縮放向量圖形）本身並不是影象。與 JPEG、PNG、WebP 等常規影象格式相比，SVGs 是一種基於 XML 的標記語言，可在二維幾何平面上描述影象。
然後將描述文字傳送給使用者，使用者的瀏覽器在收到完整的 SVG 標記後將其轉換為 “影象”。
所有這些使得 SVG 非常輕量級–因為它們本質上只是一些小的文字塊。
此外，由於它是基於數學建立的，SVG 影象可以無限縮放而不會降低質量，而且在任何裝置上，從小小的智慧手機到巨大的 4K 顯示器，都能清晰顯示。
SVG 被稱為向量格式，而 WebP 則是光柵格式，你可以看到兩者在放大時的反應。
該字型是日常使用的向量字型的典型範例。你可以隨意放大字型，但它們不會畫素化。說到字型，您還可以使用另一種方法來優化 Core Web Vitals 網站，那就是減少字型的使用。
2. 優化字型，提高 CWV 效能
字型可以決定網站設計的成敗。但在優化字型效能方面，字型越少越好。
以下是為網站優化字型的幾個技巧：
- 限制字型數量：在整個網站中堅持使用兩種主要字型–一種用於標題，一種用於正文。這樣可以減少 HTTP 請求的數量，簡化設計。此外，要有選擇性地使用字型重量；只使用您需要的字型。
- 儘可能使用系統字型：大多數裝置已經安裝了 Arial、Helvetica 或 Georgia 等系統字型。它們可以立即載入，無需額外下載字型。
- 預載關鍵字型：在 HTML 中新增一個預載入連結，可以指示瀏覽器在載入過程的早期獲取最重要的字型。這可以大大縮短文字渲染時間。
- 優化自定義字型以防止 CLS：瀏覽器在下載自定義字型之前並不知道它們的確切尺寸，從而導致佈局偏移。一些開源工具，如Font Pie，可以幫助生成消除或至少減少 CLS 的 CSS。
- 子集字型：刪除字型檔案中未使用的字元，比如非拉丁字元（如果你的網站不使用它們）。這樣可以減小檔案大小，加快載入速度。
我們將在今後介紹一些先進的字型優化策略，但現在，使用這個快速列表應該可以幫助你為網站字型取得更好的成績做好準備。
3. 使用 Google 標籤管理器前請三思
我們知道你在想什麼： 但是 Google 標籤管理器讓我的生活變得如此簡單！
你說得沒錯。
它是一款無需深入程式碼即可管理多個標籤的神奇工具。但是，在使用 Core Web Vitals 時，它既有優點也有缺點。
雖然 Google 標籤管理器是組織標籤的絕佳工具，但如果使用不當，有可能會降低網站的執行速度。每個標籤都會增加一點載入時間，而這些毫秒的增加速度可能比你在開發者大會上喝咖啡的速度還要快。
捫心自問：你真的需要在每次頁面載入時都啟動所有這些標籤嗎？是否可以手動實施其中一些標籤，以便更好地控制載入時間？
根據經驗法則，只使用 Google 標籤管理器來執行必要的、全站範圍的標籤，而手動執行不那麼重要或特定頁面的標籤。
4. 實施快取解決方案
將快取視為網站的短期記憶。快取不是為每個訪問者從頭開始生成每個頁面，而是儲存頁面的副本，並以迅雷不及掩耳之勢提供給訪問者。
實施快取可以顯著提高 LCP 分數，尤其是動態網站。您可以考慮使用不同級別的快取：
- 瀏覽器快取：告訴瀏覽器在本地儲存某些檔案。
- 伺服器端快取：儲存生成的頁面或資料庫查詢。
- 物件快取：快取小部件或選單等單個元素。
根據你的虛擬主機，你也許可以在伺服器上利用快取。
另外，假設你使用 WordPress 作為網站的內容管理系統（CMS）。在這種情況下，W3 Total Cache 或 WP Super Cache 等外掛可以幫助您實施更多層次的快取，包括瀏覽器快取和物件快取，從而進一步提高網站速度。
5. 消除渲染阻塞資源
渲染阻塞元素是指在網站上渲染頁面所需的靜態 HTML、CSS 和 JavaScript 檔案。這些檔案中的每一個都包含會阻止使用者檢視內容的指令碼。
通常，它們是由第三方外掛和工具（如Google Analytics）建立的。
但是，避免這些指令碼損害使用者體驗的方法之一（反過來也有助於改善 Core Web Vitals）就是消除渲染阻塞資源，並對任何未使用的 CSS 或指令碼進行最小化和刪除。
您可以使用多種技術來實現這一點。
一種是通過消除空白或不必要的註釋來對 JavaScript 和 CSS 進行最小化。
您可以使用 CSS Minifier 等工具來簡化這項工作：
輸入 CSS 並選擇 Minify 按鈕。然後，你就可以複製並貼上輸出結果，下載並替換你的程式碼。
另一種方法是通過合併檔案來壓縮 JavaScript 和 CSS。這是 WP Rocket 檔案優化功能可以幫助完成的另一項任務。
6. 延遲載入 JavaScript
如果你想提高 FID 分數，可以使用延遲載入 JavaScript 的技術。這是另一種消除渲染阻塞元素的方法。
這個過程會使網頁載入更快，因為它會延遲 JavaScript 的載入。換句話說，當訪問者到達時，它會載入頁面上的其他內容，而不是等待所有 JavaScript 檔案載入完畢。
您的檔案將被迫等待載入，直到網頁上的其他內容都準備就緒。
此外，您還可以對網站設定進行配置，使關鍵 CSS 更快地載入頁面首屏的內容。頁面首屏內容即指的是網頁上最先出現的元素。
要做到這一點，你可以將內容從主 CSS 檔案中移出，並將其內嵌到程式碼中。這將有助於加快載入速度，從而改善使用者體驗。一些快取外掛（如 WP Rocket）提供的優化 CSS 傳遞功能對此很有幫助。
7. 使用 CDN 加速
想象一下，如果你的網站在全球各大城市都有一個自己的克隆版本。這就是內容分發網路（CDN）的基本功能。
它可以將靜態資產（如圖片、CSS 和 JavaScript 檔案）的副本分發到全球各地的伺服器，這樣您的訪問者就可以從最近的地方下載它們。
結果如何？更快的載入時間、更高的 LCP 分數，以及為全球受眾帶來更好的使用者體驗。它還可以幫助最大限度地減少首位元組時間（TTFB）。
您可以在 WordPress 網站上使用多種第三方工具。其中最受歡迎的是 Cloudflare 。
與快取一樣，一些託管服務提供商提供內建 CDN 或至少與 CDN 整合。
8. 適當調整圖片大小
圖片越大，檔案尺寸就越大。
因此，明智的做法是確保不要隨處使用過大的圖片。例如，縮圖沒有必要使用高清圖片。您可以使用更小、解析度更低的圖片。
要進一步優化圖片，可以在 HTML 程式碼中使用 srcset 屬性。使用該標籤，您可以指定不同尺寸圖片的位置，現代瀏覽器可以根據裝置的解析度自動提供正確尺寸的圖片，從而提高 LCP 分數。
除此之外，您還可以為圖片標籤指定寬度和高度屬性，或使用 CSS 寬高比預留所需空間，以確保使用者自動看到較小的圖片。
不過，我們始終建議在上傳圖片前使用 Sqoosh 等工具調整圖片大小。
9. 實施懶載入
我們還建議你實施懶載入。這有助於確保圖片在使用者進入網頁該部分時精確載入，而不是與網頁上的其他內容同時載入。
懶載入圖片有助於提高 LCP 和載入速度。最重要的是，它很容易實現。
現代瀏覽器支援本機懶載入，在 <img> 標記上使用 loading="lazy"屬性 。
只需新增一個屬性，你的頁面就可以懶載入了。
對於 WordPress 使用者來說，只需使用 Jetpack 或 Smush 等外掛即可啟用懶載入功能。
10. 升級主機
有時，你可以把一切都做得很好，但 Core Web Vitals 分數仍然很低。此時，考慮升級託管服務提供商的計劃是有意義的。
例如，如果您最近開始接待大量訪客，或者新增了許多帶有大量圖片的新產品，那麼您可能已經達到了虛擬主機的上限。
在這種情況下，如果您使用的是共享主機計劃，您可以轉到虛擬專用伺服器（VPS）主機或獨立主機。
對於 WordPress 使用者來說，WordPress 託管可以很好地提升網站效能，而且價格也不會太貴。
無論你選擇哪種型別的主機，或者已經在使用哪種型別的主機，大家都認為升級主機提供商或計劃是加快網站速度的最快方法。
我們建議選擇託管主機，其伺服器專為 WordPress 優化，可以處理網站效能的各種技術問題。
小結
開發者並不總是熱衷於跟隨谷歌的調子跳舞。大型公司擁有相當大的實力，搜尋引擎的微小更新可能會對網路組織的生產力和盈利能力產生不利影響。
這就是說，Core Web Vitals採取了“胡蘿蔔”而不是“大棒”的方法。優化良好的、可用的、放棄黑暗模式的網站比那些提供糟糕的移動使用者介面的、臃腫的、彈出式密集型的網站更容易成功。
Core Web Vitals提供了一種可測量的方法來評估使用者體驗，幫助您專注於最關鍵的改進。對你的重要資訊的改變可能不會增加收入，但你的使用者會更快樂、更忠誠。
如果您要進一步深入瞭解基於Core Web Vitals進行網站優化，可以閱讀以下相關文章：
- 什麼是FCP以及如何針對您的網站優化
- 什麼是首次輸入延遲 (FID)以及如何有針對性地優化
- 什麼是最大內容繪製 (LCP) 以及如何有效地優化
- 什麼是累計佈局偏移 (CLS) 及應該如何優化提升
- 什麼是首位元組時間 (TTFB) 及如何為您的網站優化該指標
- 什麼是首屏展現平均值 (Speed Index) 及如何做相應優化措施
- 如何做到Google PageSpeed Insights測試滿分
當你摸透一些指標定義及學會有針對性地對網站進行優化，結合本文及如何做到Google PageSpeed Insights測試滿分，相信您的網站的速度有了質的飛躍。
評論留言