HubSpot One在去年介紹了谷歌提出的衡量用戶網頁瀏覽體驗的新指標Core Web Vitals（核心網頁指標），該系列指標將在今年5月納入谷歌的核心算法用以影響網頁排名，尤其是移動設備上的排名。在時間表上僅剩3個月的今天，依然有三分之一的數字行銷者不清楚Core Web Vitals是什麼，意味著什麼。這不禁令人擔憂。
CWV包含了三個最核心的指標。它們分別是LCP、FID和CLS。這三個指標要全部飄綠才算合格。前兩者和網頁的加載速度緊密相關。而大多數網頁是非強交互的，因此LCP就成為在CWV中最應該讓行銷者們投入時間來盡快改善的指標。同時LCP又是優化CWV的難點，因此本篇，HubSpot One將展開與讀者探討如何優化LCP來滿足即將到來的變革。推薦行銷者和前端開發的小伙伴一同閱讀。
LCP的意義
LCP（Largest Contentful Paint）是一個時間長度的考量。它始於網頁請求，終於網頁視口（Viewport）中最大的內容元素的顯示。知道了它的衡量方法我們至少可以從兩方面考慮：
一是如何鎖定網頁上視口中最大元素，二是如何減少最大元素顯示之前的各個步驟並壓縮這些步驟所花費的時間。
LCP中鎖定視口最大元素
谷歌在最近的Chrome 88版本中的DevTools裡添加了查看Web Vitals的方式。
如上圖所示，我們在Performance中勾選了Web Vitals，然後在時間序列中找到了LCP的標籤。點擊該標籤後我們可以在下方視窗中查看詳情。看來最大的一塊是個圖片，長寬乘積48960，時間戳在3120.2毫秒。
當我們將鼠標移到LCP標籤上時，我們可以看到網頁中標記出了最大元素的位置。見下圖：
優化LCP的思路
我們知道LCP的benchmark分三檔，小於2.5秒是健康，大於4秒是糟糕，中間算馬馬虎虎。上面的結果顯然算不上健康，我們需要對其進行優化。我們可以先看看在該圖片載入之前瀏覽器都做了什麼。
在上圖中首先我們看到當藍色的網頁HTML下載後瀏覽器開始解析，此時前三個紫色的css文件，下面綠色的logo和icon，以及最下面橙色的js文件陸續進行下載。以上一共6個文件並行下載，這是因為該網站使用的是HTTP1.1協議最多只允許6個下載線程。當其中第一個css文件下載完成之後，這才輪到第四個紫色的css文件開始下載，再等到icon圖片下載完成後，這才輪到我們LCP的圖片開始下載。
這裡我們非常直觀地可以看到，如果我們把HTTP1.1升級到HTTP2，那麼我們LCP圖片的下載至少可以提前700毫秒。於是我們得到了第一個結論強烈建議使用HTTP2節省等待下載的時間。
那麼除了這個我們還能做些什麼呢？我們看到有4個css文件在這一過程中被使用，如果我們將這四個文件瘦身或者合併可以顯著提升LCP 。因為css文件是天生的阻塞元素，瀏覽器需要這4個css文件才能將網頁“畫”出來。
要將css瘦身我們可以通過DevTools – More tools（右上角三點） 中的Coverage來進行診斷，這個工具會告訴我們css（和js）文件中有多少代碼其實根本沒有用到。
我們需要做的是將那些大部分沒有用到的css代碼塊去掉，把剩下的代碼合併成一個css文件。對於首屏需要用到的css代碼，我們可以直接inline寫到HTML的<head></head>裡面。
那些用到的css代碼被整合到css文件之後依然會對頁面加載產生阻塞怎麼辦呢？ web.dev提供了一種不錯的方法來lazyload css。
<link rel =” preload ” href =” styles.css ” as=” style ” onload =” this.onload=null;this.rel=’stylesheet ‘”>
<noscript><link rel =” stylesheet ” href =” styles.css “></noscript>
上面的代碼中我們先用preload下載稍後需要加載的css文件放在一邊，當頁面加載完成到了load事件時將rel的屬性從preload改為stylesheet應用這個css。這方法十分精妙，當JavaScript被禁用時將fallback到noscript的做法。
更多優化LCP的方法
上面的例子中我們提供了優化LCP的思路和難點的解決方法。 web.dev的官方文檔中提供了更多其他的優化LCP的方法，包括但不限於：
- 提升網路、DNS和服務器響應時間
- 應用CDN
- 優化圖片大小
- 減少JavaScript的阻塞並延遲加載JavaScript
- 應用緩存和最小化/壓縮資源
- 預加載和DNS預解析
- 適配伺服（Adaptive Serving）
以上我們也可以藉助谷歌提供的PageSpeed Insights工具進行診斷。我們留待今後展開。