大家好，我是Echa。

【資料圖】

不知道大家最近有沒有關(guān)注 2023谷歌 Google I/O 大會(huì)呢？作為小編的我最近也是非常重視，非常關(guān)心2023 谷歌 Google I/O 大會(huì)。作為程序員，一年一度的谷歌 Google I/O大會(huì)哪怕太忙也的了解了解，因?yàn)镚oogle I/O 大會(huì)太多太多的新技術(shù)和未來發(fā)展方向，有利于個(gè)人的未來規(guī)劃和學(xué)習(xí)方向。

今天繼續(xù)帶著大家解讀2023年Google I/O，我會(huì)重點(diǎn)為大家解讀前端開發(fā)者應(yīng)該關(guān)注的信息，應(yīng)該包括以下這些方向：

一、Web 平臺(tái)的最新動(dòng)態(tài)（已發(fā)布）二、提升 Web 核心性能指標(biāo)優(yōu)化建議 （本篇）三、準(zhǔn)備好迎接三方 Cookie 的終結(jié)四、Web UI 開發(fā)的最新動(dòng)態(tài)五、Web 動(dòng)畫開發(fā)的最新動(dòng)態(tài)六、合作打造穩(wěn)定的 Web 體驗(yàn)七、移動(dòng)端 Web 開發(fā)的新功能

Barry Pollard

Barry Pollard本在文章中分享了2023年的最佳Core Web Vitals的優(yōu)化建議。Web性能方面有非常多的建議，但很難判斷哪些建議會(huì)產(chǎn)生最大的影響。Chrome團(tuán)隊(duì)花費(fèi)了一年的時(shí)間確定了每個(gè)核心Web指標(biāo)的三項(xiàng)最佳建議，這些建議對于大多數(shù)網(wǎng)站都是相關(guān)的，并且對于大多數(shù)開發(fā)人員來說也是實(shí)際可行的。

LCP 優(yōu)化建議

首先，讓我們來看看網(wǎng)站最大內(nèi)容渲染時(shí)間（LCP）的建議。LCP是渲染網(wǎng)頁最大內(nèi)容的時(shí)間，相比于CLS或FID，LCP往往是大多數(shù)網(wǎng)站最難以應(yīng)付的衡量指標(biāo)。

在大多數(shù)情況下，約70-80%的網(wǎng)站是因?yàn)樾枰秩净蛳螺d圖片引起的。去年的Google I/O活動(dòng)上，他們展示了實(shí)際的下載時(shí)間往往不是圖像的最大延遲，今年的分析進(jìn)一步證實(shí)了這一點(diǎn)。

Image 加載優(yōu)化

為了優(yōu)化LCP的時(shí)間，我們可以讓使靜態(tài)HTML中的圖片資源更易于被發(fā)現(xiàn)，這有可以讓瀏覽器的預(yù)加載掃描程序更早的找到并加載它。

使用背景圖片、客戶端渲染和懶加載等方法是可能存在問題的，它們不利于LCP的發(fā)現(xiàn)。

而使用傳統(tǒng)的img元素或添加預(yù)加載鏈接等方式則可以使圖像資源被預(yù)加載掃描程序發(fā)現(xiàn)，并被瀏覽器盡早加載。

你還可以使用Chrome devtools中的加載瀑布工具來識(shí)別開始加載較晚的資源，通過把圖片包含在HTML中（讓圖片元素預(yù)加載）即可解決這個(gè)問題。但是在將LCP圖像優(yōu)化的可以被易于發(fā)現(xiàn)后，并不代表就可以更快的加載。因?yàn)闉g覽器更傾向于優(yōu)先處理阻塞渲染的內(nèi)容，如CSS和同步JavaScript，而不是圖像。

fetch proirity API

新的fetch proirity API允許我們自定義標(biāo)記資源的優(yōu)先級(jí)。只需將fetchprority屬性添加到我們的圖像或預(yù)加載LCP元素中，就可以使瀏覽器更早地開始下載它們，并具有更高的優(yōu)先級(jí)，這可以對LCP時(shí)間產(chǎn)生很大的影響。這個(gè)API已經(jīng)在基于chromium的瀏覽器中提供，Safari和Firefox也正在實(shí)現(xiàn)相關(guān)代碼，并且這個(gè)屬性是漸進(jìn)式的，在不支持它的其他瀏覽器中會(huì)被簡單地忽略。回到之前的例子，我們解決了圖片可盡早被發(fā)現(xiàn)的問題，但是請求圖像和開始下載依然會(huì)存在很大的延遲。使用fetch proirity API可以將延遲最小化，并且讓圖像盡快下載。

這是一個(gè)優(yōu)化LCP指標(biāo)的最佳示例，我們還可以通過其他多種方式降低非關(guān)鍵資源的優(yōu)先級(jí)。

例如使用fetchprority=low或者對它們進(jìn)行懶加載，以便按需獲取，這樣就可以讓瀏覽器集中處理更重要的資源，比如影響LCP指標(biāo)的元素。我們只需要確保不要在LCP圖像本身上使用這些技術(shù)即可。

如果我們使用了JavaScript框架，建議使用Chrome Aurora團(tuán)隊(duì)開發(fā)的Image組件添加圖像。其中Angular和XJS組件已經(jīng)內(nèi)置了提取優(yōu)先級(jí)的支持，團(tuán)隊(duì)也正在開發(fā)Next.js的Image組件，以支持這個(gè)新的API。

Chrome團(tuán)隊(duì)也與其他平臺(tái)有著合作，例如如果大家使用的是WordPress，就可以嘗試使用官方WordPress性能實(shí)驗(yàn)室插件的新提取優(yōu)先級(jí)模塊。這是Chrome團(tuán)隊(duì)與WordPress核心性能團(tuán)隊(duì)開發(fā)合作的成果。

使用 CDN

前兩個(gè)LCP的建議是和如何構(gòu)建HTML來讓LCP資源易于被發(fā)現(xiàn)以及優(yōu)先下載有關(guān)，但這都取決于首屏加載HTML的速度。所以，最后一個(gè)建議是使用CDN來優(yōu)化First Byte的時(shí)間。

在瀏覽器收到第一次HTML請求響應(yīng)的第一個(gè)字節(jié)之前，網(wǎng)站是無法開始加載任何子資源的。越快將首節(jié)傳遞給瀏覽器，瀏覽器就可以越快地開始處理它，同時(shí)也可以讓其他所有的操作都更快的進(jìn)行。下面是兩個(gè)減少ttfb的最佳方法：

（1）盡可能地將內(nèi)容服務(wù)器設(shè)置為地理位置更靠近用戶的位置來減少用戶與服務(wù)器之間的距離；（2）對內(nèi)容進(jìn)行緩存，以便最近請求的內(nèi)容可以快速再次提供。

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）是執(zhí)行這兩個(gè)操作的最佳方法。CDN是一組全球分布式的服務(wù)器，它作為用戶的連接點(diǎn)。由于最后一英里的傳輸速度往往是最慢的，而使用CDN可以盡可能的優(yōu)化這個(gè)問題。CDN還允許在這些邊緣節(jié)點(diǎn)上緩存內(nèi)容，從而進(jìn)一步降低加載時(shí)間，所以即使必須要返回到我們的源服務(wù)器進(jìn)行回源加載，CDN通常也可以更快地完成。

開發(fā)者經(jīng)常使用CDN來托管靜態(tài)資源，如CSS、JavaScript或Media文件，但是通過CDN提供HTML也可以獲得更多的好處。根據(jù)Web Almanac的統(tǒng)計(jì)結(jié)果，只有29%的HTML文檔請求會(huì)通過CDN服務(wù)加載。如果你不是這樣做的，那么這意味著你還有很大的機(jī)會(huì)來優(yōu)化網(wǎng)站的性能。

CLS 優(yōu)化建議

下面，我們來看看累積布局移位（CLS）的優(yōu)化建議。CLS是網(wǎng)頁視覺穩(wěn)定性的度量指標(biāo)，意味著當(dāng)有新的內(nèi)容加載時(shí)，頁面的內(nèi)容是否經(jīng)常跳動(dòng)。

雖然CLS在2020年以來得到了很大的改進(jìn)，但仍然有約四分之一的網(wǎng)站未達(dá)到推薦的閾值，所以很多網(wǎng)站在這方面還有很好的改進(jìn)用戶體驗(yàn)的機(jī)會(huì)。

內(nèi)容大小

第一個(gè)CLS優(yōu)化建議是確保內(nèi)容能被顯式地縮放，當(dāng)它第一次被瀏覽器渲染時(shí)，它就可以以正確的尺寸渲染。

一般情況下，我們都會(huì)熱衷于推薦大家設(shè)定圖像的寬度和高度的尺寸或CSS等效尺寸，現(xiàn)在這仍然是影響CLS的主要原因，網(wǎng)站也往往可以通過提供這些尺寸來輕松的優(yōu)化CLS，但還有一些其他的優(yōu)化點(diǎn)。

比如我們可以通過新的CSSaspect-ratio屬性，就可以確保像視頻這樣的其他非圖像內(nèi)容也能夠較好的響應(yīng)。

另外還可以將渲染的文字設(shè)置適當(dāng)?shù)母叨?，例如使用min-height來為廣告卡片等動(dòng)態(tài)的內(nèi)容保留最小空間，空元素的默認(rèn)高度為零像素，所以即使對于某些動(dòng)態(tài)的內(nèi)容，我們不能確定實(shí)際的高度，也是可以通過使用min-height來減少CLS的影響。

BF Cache

我們?nèi)ツ昕吹紺LS的最大改進(jìn)之一是在Chrome中推出的回退緩存或BF緩存中。另外，Safari和Firefox也已經(jīng)上線這個(gè)功能一段時(shí)間了。

一個(gè)頁面可能在初始加載時(shí)具有很大的CLS，因?yàn)殡S著其他內(nèi)容（如圖像和廣告）的加載，頁面的結(jié)構(gòu)會(huì)一直產(chǎn)生變化，從而影響CLS。當(dāng)然，我們應(yīng)該盡量在首屏頁面渲染時(shí)避免加載這些內(nèi)容。

BF緩存會(huì)在用戶離開之后，在內(nèi)存中存儲(chǔ)一個(gè)用戶加載頁面后的完整CLS快照。如果用戶返回了這個(gè)頁面，就會(huì)恢復(fù)這個(gè)快照。同樣的，如果用戶再次向前訪問，則也可以恢復(fù)這個(gè)快照。這就完全消除了任何CLS的加載，如果從頭開始重新渲染頁面，BF緩存也會(huì)默認(rèn)啟用，我們不需要采取任何措施來主動(dòng)啟用它，但是我們可以使用某些API阻止瀏覽器使用它，但這可能會(huì)導(dǎo)致瀏覽器沒辦法更好的響應(yīng)，建議大家不要放棄這種免費(fèi)的性能優(yōu)化方案。

Chrome DevTools有一個(gè)工具，可以讓我們測試頁面是否有使用BF Cache的資格。如果沒辦法使用BF Cache，工具一般都會(huì)告訴我們具體原因。最常見的原因是我們設(shè)定了cache-control這個(gè)Header的值為no-storage或者在頁面中使用了unload handler，這兩者都會(huì)阻止BF Cache的使用。

在Lighthouse 10中，也添加了一個(gè)類似的檢測能力，也可以解釋頁面不符合資格的原因。

BF Cache是Chrome團(tuán)隊(duì)為了讓網(wǎng)頁瀏覽更快的正在開發(fā)的一系能力之一，這個(gè)領(lǐng)域還有一些其他的能力，比如預(yù)加載和預(yù)渲染也是可以改善網(wǎng)站CLS指標(biāo)的。

動(dòng)畫和轉(zhuǎn)換的處理

最后一個(gè)CLS建議是處理動(dòng)畫和轉(zhuǎn)換。動(dòng)畫通常用于移動(dòng)端的內(nèi)容，如cookie banner或從頂部或底部滑入的其他通知橫幅，者具體取決于這些動(dòng)畫或過渡是怎么編碼的，它們可以更少或者更有效，并且可以幫助優(yōu)化CLS。

動(dòng)畫的渲染需要瀏覽器重新布局頁面，因此需要更多的工作，即使脫離正常文檔流的絕對定位元素，例如使用top或left移動(dòng)內(nèi)容，也會(huì)將其計(jì)算為布局移位，即使它不會(huì)移動(dòng)任何周圍其他的內(nèi)容，內(nèi)容本身也在移動(dòng)，并且有可能影響其他內(nèi)容，所以這也會(huì)影響CLS。

使用translate進(jìn)行相同的動(dòng)畫不會(huì)在瀏覽器的布局處理中移動(dòng)內(nèi)容，而是在合成器層中進(jìn)行的，除了對于瀏覽器來說工作量較小之外，這還意味著它無法影響其他的內(nèi)容，這也意味著它對CLS的影響就變小了。所以我們的解決方案就是替換使用top或left的動(dòng)畫，并且這種方式在所有的瀏覽器中都得到了支持。

始終優(yōu)先使用復(fù)合動(dòng)畫，比如如transform，而不是圖層誘導(dǎo)的非復(fù)合動(dòng)畫，如更改top、right、bottom和left。

并且Lighthouse也有一個(gè)相關(guān)的能力來識(shí)別這些問題。

FID 優(yōu)化建議

最后我們來看看用戶響應(yīng)相關(guān)的優(yōu)化建議，這包括用戶和頁面進(jìn)行首次交互操作所花費(fèi)的時(shí)間（FID），以及更全面的交互到下一次繪制的時(shí)間（INP）。

網(wǎng)站響應(yīng)性的關(guān)鍵在于確保不阻塞主線程，因?yàn)檫@會(huì)導(dǎo)致瀏覽器無法響應(yīng)用戶輸入。

分解長任務(wù)

第一個(gè)建議是識(shí)別并分解長任務(wù)，相當(dāng)于給瀏覽器一些喘息的空間，以便它能夠響應(yīng)用戶輸入。

Chrome Devtools和Lighthouse將長任務(wù)定義為需要50毫秒或更長時(shí)間的渲染工作。這可能聽起來不是很多，但在瀏覽器術(shù)語中，這可以是網(wǎng)站能感覺到比較好的響應(yīng)或不響應(yīng)的區(qū)別。

JavaScript是單線程且貪婪的，一旦它占用了CPU，它就會(huì)盡可能地一直保持它，直到它不能處理或者處理完畢為止。在這個(gè)例子中，即使有五個(gè)子進(jìn)程，所有的五個(gè)進(jìn)程也是會(huì)一個(gè)接一個(gè)地執(zhí)行。所以，在我們的代碼中放置一些斷點(diǎn)就是關(guān)鍵了。

我們可以使用設(shè)置超時(shí)settimeout 0毫秒延遲來放入非關(guān)鍵的工作和新的任務(wù)，這些新任務(wù)就會(huì)在已經(jīng)排隊(duì)的任何任務(wù)之后執(zhí)行。

還有一些新的和即將推出的瀏覽器API，如isInputPending、scheduler.postTask和scheduler.yield，它們可以幫助大家決定何時(shí)以及如何放棄主線程。有關(guān)更多詳細(xì)的信息，可以去看web.dev上優(yōu)化長任務(wù)的相關(guān)文章 ：https://web.dev/optimize-long-tasks/ 。另外，在Google I/O上，還有一個(gè)專門關(guān)于優(yōu)化長任務(wù)的獨(dú)立演講。

去除不必要的 JS

盡管優(yōu)化我們頁面上的 JavaScript 代碼執(zhí)行是一個(gè)不錯(cuò)的方法，但更好的方式是一開始就不要發(fā)送太大的JavaScript。

現(xiàn)在的網(wǎng)站上加載的JavaScript越來越大了，但我們需要重新檢查一下有這些JavaScript是否都是必要的。

我們可以使用Chrome Devtools的Coverage特性來查看我們的JavaScript有多少被執(zhí)行了。如果在頁面加載期間沒有使用的大部分JavaScript，都可以考慮進(jìn)行代碼分離以在需要時(shí)或?yàn)g覽器不太繁忙的時(shí)候加載這些代碼。

Aurora團(tuán)隊(duì)還開發(fā)了一個(gè)xjs腳本組件，允許我們加載較少且關(guān)鍵的第三方代碼，并采用各種策略來減少這些腳本的影響。標(biāo)簽管理器是另一個(gè)容易積累舊JavaScript代碼的地方，這些代碼可能不再需要了。定期檢查我們的標(biāo)簽，以確保刪除所有標(biāo)簽，因?yàn)榧词顾鼈儾辉儆|發(fā)，它們?nèi)匀恍枰螺d、解析和編譯。

避免大型渲染更新

改善響應(yīng)性的最后一個(gè)建議是避免大型渲染更新。JavaScript不是唯一可以影響我們網(wǎng)站響應(yīng)性的東西，如果瀏覽器需要大量的工作來將頁面渲染到屏幕上，那么瀏覽器本身也可能會(huì)變慢。大型渲染更新可能會(huì)在有大量Dom更改時(shí)發(fā)生，無論是有意還是由于一個(gè)更改導(dǎo)致許多其他元素需要重新計(jì)算。避免大型渲染更新的最佳方法是保持較小的Dom結(jié)構(gòu)，以便即使存在關(guān)聯(lián)效應(yīng)，也可以快速處理它們。

我們還有一個(gè)Lighthouse審計(jì)工具來幫助大家實(shí)現(xiàn)這一目標(biāo)。

CSS containment是另一種分離網(wǎng)頁區(qū)域的方法，它可以告訴瀏覽器某些區(qū)域中的元素可以不受其他區(qū)域更改的影響，從而減少布局的工作。

content-visibility是CSS containment的一種擴(kuò)展能力，允許我們能完全跳過離屏內(nèi)容的布局和渲染。

最后，大家應(yīng)該避免濫用requestAnimationFrame API，它應(yīng)應(yīng)該只用于關(guān)鍵的渲染工作，如果通過這個(gè)API安排了過多的工作，它會(huì)導(dǎo)致渲染變慢。

這些就是我們認(rèn)為大家首先應(yīng)考慮的九個(gè)改善網(wǎng)站核心性能指標(biāo)的優(yōu)化建議。這并不是一個(gè)明確的列表，而是我們的研究表明可以真正提高大家網(wǎng)站性能的幾個(gè)更有影響力的選項(xiàng)。包括Chrome Devtools、Lighthouse和我們添加到JavaScript框架和平臺(tái)中的組件，許多這些建議已經(jīng)涵蓋在我們的各種工具中。但我們并沒有放松警惕，并且也在一直更新我們的工具和文檔，來呈現(xiàn)這些關(guān)鍵建議。

關(guān)鍵詞：