大家好，我是Echa。

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

(相關(guān)資料圖)

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

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

Barry Pollard

Barry Pollard本在文章中分享了2023年的最佳Core Web Vitals的優(yōu)化建議。Web性能方面有非常多的建議，但很難判斷哪些建議會產(chǎn)生最大的影響。Chrome團(tuán)隊(duì)花費(fèi)了一年的時(shí)間確定了每個核心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活動上，他們展示了實(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中的加載瀑布工具來識別開始加載較晚的資源，通過把圖片包含在HTML中（讓圖片元素預(yù)加載）即可解決這個問題。但是在將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)先級。只需將fetchprority屬性添加到我們的圖像或預(yù)加載LCP元素中，就可以使瀏覽器更早地開始下載它們，并具有更高的優(yōu)先級，這可以對LCP時(shí)間產(chǎn)生很大的影響。這個API已經(jīng)在基于chromium的瀏覽器中提供，Safari和Firefox也正在實(shí)現(xiàn)相關(guān)代碼，并且這個屬性是漸進(jìn)式的，在不支持它的其他瀏覽器中會被簡單地忽略?；氐街暗睦樱覀兘鉀Q了圖片可盡早被發(fā)現(xiàn)的問題，但是請求圖像和開始下載依然會存在很大的延遲。使用fetch proirity API可以將延遲最小化，并且讓圖像盡快下載。

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

例如使用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)先級的支持，團(tuán)隊(duì)也正在開發(fā)Next.js的Image組件，以支持這個新的API。

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

使用 CDN

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

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

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

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）是執(zhí)行這兩個操作的最佳方法。CDN是一組全球分布式的服務(wù)器，它作為用戶的連接點(diǎn)。由于最后一英里的傳輸速度往往是最慢的，而使用CDN可以盡可能的優(yōu)化這個問題。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文檔請求會通過CDN服務(wù)加載。如果你不是這樣做的，那么這意味著你還有很大的機(jī)會來優(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)常跳動。

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

內(nèi)容大小

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

一般情況下，我們都會熱衷于推薦大家設(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來為廣告卡片等動態(tài)的內(nèi)容保留最小空間，空元素的默認(rèn)高度為零像素，所以即使對于某些動態(tài)的內(nèi)容，我們不能確定實(shí)際的高度，也是可以通過使用min-height來減少CLS的影響。

BF Cache

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

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

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

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

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

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

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

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

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

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

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

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

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)檫@會導(dǎo)致瀏覽器無法響應(yīng)用戶輸入。

分解長任務(wù)

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

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

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

我們可以使用設(shè)置超時(shí)settimeout 0毫秒延遲來放入非關(guān)鍵的工作和新的任務(wù)，這些新任務(wù)就會在已經(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上，還有一個專門關(guān)于優(yōu)化長任務(wù)的獨(dú)立演講。

去除不必要的 JS

盡管優(yōu)化我們頁面上的 JavaScript 代碼執(zhí)行是一個不錯的方法，但更好的方式是一開始就不要發(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ā)了一個xjs腳本組件，允許我們加載較少且關(guān)鍵的第三方代碼，并采用各種策略來減少這些腳本的影響。標(biāo)簽管理器是另一個容易積累舊JavaScript代碼的地方，這些代碼可能不再需要了。定期檢查我們的標(biāo)簽，以確保刪除所有標(biāo)簽，因?yàn)榧词顾鼈儾辉儆|發(fā)，它們?nèi)匀恍枰螺d、解析和編譯。

避免大型渲染更新

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

我們還有一個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)鍵的渲染工作，如果通過這個API安排了過多的工作，它會導(dǎo)致渲染變慢。

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

免責(zé)聲明：本文不構(gòu)成任何商業(yè)建議，投資有風(fēng)險(xiǎn)，選擇需謹(jǐn)慎！本站發(fā)布的圖文一切為分享交流，傳播正能量，此文不保證數(shù)據(jù)的準(zhǔn)確性，內(nèi)容僅供參考

關(guān)鍵詞：