大家好，我是Echa。
不知道大家最近有沒有關注 2023谷歌 Google I/O 大會呢？作為小編的我最近也是非常重視，非常關心2023 谷歌 Google I/O 大會。作為程式員，一年一度的谷歌 Google I/O大會哪怕太忙也的了解了解，因為Google I/O 大會太多太多的新技術和未來發展方向，有利于個人的未來規劃和學習方向。
今天繼續帶着大家解讀2023年 Google I/O ，我會重點為大家解讀前端開發者應該關注的資訊，應該包括以下這些方向：
- 一、Web 平台的最新動态（已釋出）
- 二、提升 Web 核心性能名額優化建議 （本篇）
- 三、準備好迎接三方 Cookie 的終結
- 四、Web UI 開發的最新動态
- 五、Web 動畫開發的最新動态
- 六、合作打造穩定的 Web 體驗
- 七、移動端 Web 開發的新功能
Barry Pollard
Barry Pollard 本在文章中分享了 2023 年的最佳 Core Web Vitals 的優化建議。Web 性能方面有非常多的建議，但很難判斷哪些建議會産生最大的影響。Chrome 團隊花費了一年的時間确定了每個核心 Web 名額的三項最佳建議，這些建議對于大多數網站都是相關的，并且對于大多數開發人員來說也是實際可行的。
LCP 優化建議
首先，讓我們來看看網站最大内容渲染時間（LCP）的建議。LCP 是渲染網頁最大内容的時間，相比于 CLS 或 FID，LCP 往往是大多數網站最難以應付的衡量名額。
在大多數情況下，約 70-80% 的網站是因為需要渲染或下載下傳圖檔引起的。去年的 Google I/O 活動上，他們展示了實際的下載下傳時間往往不是圖像的最大延遲，今年的分析進一步證明了這一點。
Image 加載優化
為了優化 LCP 的時間，我們可以讓使靜态 HTML 中的圖檔資源更易于被發現，這有可以讓浏覽器的預加載掃描程式更早的找到并加載它。
使用背景圖檔、用戶端渲染和懶加載等方法是可能存在問題的，它們不利于 LCP 的發現。
而使用傳統的 img 元素或添加預加載連結等方式則可以使圖像資源被預加載掃描程式發現，并被浏覽器盡早加載。
你還可以使用 Chrome devtools 中的加載瀑布工具來識别開始加載較晚的資源，通過把圖檔包含在 HTML 中（讓圖檔元素預加載）即可解決這個問題。但是在将 LCP 圖像優化的可以被易于發現後，并不代表就可以更快的加載。因為浏覽器更傾向于優先處理阻塞渲染的内容，如 CSS 和同步 JavaScript，而不是圖像。
fetch proirity API
新的 fetch proirity API 允許我們自定義标記資源的優先級。隻需将 fetchprority 屬性添加到我們的圖像或預加載 LCP 元素中，就可以使浏覽器更早地開始下載下傳它們，并具有更高的優先級，這可以對 LCP 時間産生很大的影響。這個 API 已經在基于 chromium 的浏覽器中提供，Safari 和 Firefox 也正在實作相關代碼，并且這個屬性是漸進式的，在不支援它的其他浏覽器中會被簡單地忽略。
回到之前的例子，我們解決了圖檔可盡早被發現的問題，但是請求圖像和開始下載下傳依然會存在很大的延遲。使用 fetch proirity API 可以将延遲最小化，并且讓圖像盡快下載下傳。
這是一個優化 LCP 名額的最佳示例，我們還可以通過其他多種方式降低非關鍵資源的優先級。
例如使用fetchprority=low 或者對它們進行懶加載，以便按需擷取，這樣就可以讓浏覽器集中處理更重要的資源，比如影響 LCP 名額的元素。我們隻需要確定不要在 LCP 圖像本身上使用這些技術即可。
如果我們使用了 JavaScript 架構，建議使用 Chrome Aurora 團隊開發的 Image 元件添加圖像。其中 Angular 和 XJS 元件已經内置了提取優先級的支援，團隊也正在開發 Next.js 的 Image 元件，以支援這個新的 API 。
Chrome 團隊也與其他平台有着合作，例如如果大家使用的是 WordPress，就可以嘗試使用官方 WordPress 性能實驗室插件的新提取優先級子產品。這是 Chrome 團隊與 WordPress 核心性能團隊開發合作的成果。
使用 CDN
前兩個 LCP 的建議是和如何建構 HTML 來讓 LCP 資源易于被發現以及優先下載下傳有關，但這都取決于首屏加載 HTML 的速度。是以，最後一個建議是使用 CDN 來優化 First Byte 的時間。
在浏覽器收到第一次 HTML 請求響應的第一個位元組之前，網站是無法開始加載任何子資源的。越快将首節傳遞給浏覽器，浏覽器就可以越快地開始處理它，同時也可以讓其他所有的操作都更快的進行。下面是兩個減少 ttfb 的最佳方法：
- （1）盡可能地将内容伺服器設定為地理位置更靠近使用者的位置來減少使用者與伺服器之間的距離；
- （2）對内容進行緩存，以便最近請求的内容可以快速再次提供。
内容分發網絡（CDN）是執行這兩個操作的最佳方法。CDN 是一組全球分布式的伺服器，它作為使用者的連接配接點。由于最後一英裡的傳輸速度往往是最慢的，而使用 CDN 可以盡可能的優化這個問題。
CDN 還允許在這些邊緣節點上緩存内容，進而進一步降低加載時間，是以即使必須要傳回到我們的源伺服器進行回源加載，CDN 通常也可以更快地完成。
開發者經常使用 CDN 來托管靜态資源，如 CSS、JavaScript 或 Media 檔案，但是通過 CDN 提供 HTML 也可以獲得更多的好處。根據 Web Almanac 的統計結果，隻有 29% 的 HTML 文檔請求會通過 CDN 服務加載。如果你不是這樣做的，那麼這意味着你還有很大的機會來優化網站的性能。
CLS 優化建議
下面，我們來看看累積布局移位（CLS）的優化建議。CLS 是網頁視覺穩定性的度量名額，意味着當有新的内容加載時，頁面的内容是否經常跳動。
雖然 CLS 在 2020 年以來得到了很大的改進，但仍然有約四分之一的網站未達到推薦的門檻值，是以很多網站在這方面還有很好的改進使用者體驗的機會。
内容大小
第一個 CLS 優化建議是確定内容能被顯式地縮放，當它第一次被浏覽器渲染時，它就可以以正确的尺寸渲染。
一般情況下，我們都會熱衷于推薦大家設定圖像的寬度和高度的尺寸或 CSS 等效尺寸，現在這仍然是影響 CLS 的主要原因，網站也往往可以通過提供這些尺寸來輕松的優化 CLS，但還有一些其他的優化點。
比如我們可以通過新的 CSS aspect-ratio 屬性，就可以確定像視訊這樣的其他非圖像内容也能夠較好的響應。
另外還可以将渲染的文字設定适當的高度，例如使用 min-height 來為廣告卡片等動态的内容保留最小空間，空元素的預設高度為零像素，是以即使對于某些動态的内容，我們不能确定實際的高度，也是可以通過使用 min-height 來減少 CLS 的影響。
BF Cache
我們去年看到 CLS 的最大改進之一是在 Chrome 中推出的回退緩存或 BF 緩存中。另外，Safari 和 Firefox 也已經上線這個功能一段時間了。
一個頁面可能在初始加載時具有很大的 CLS ，因為随着其他内容（如圖像和廣告）的加載，頁面的結構會一直産生變化，進而影響 CLS。當然，我們應該盡量在首屏頁面渲染時避免加載這些内容。
BF 緩存會在使用者離開之後，在記憶體中存儲一個使用者加載頁面後的完整 CLS 快照。如果使用者傳回了這個頁面，就會恢複這個快照。同樣的，如果使用者再次向前通路，則也可以恢複這個快照。這就完全消除了任何 CLS 的加載，如果從頭開始重新渲染頁面，BF 緩存也會預設啟用，我們不需要采取任何措施來主動啟用它，但是我們可以使用某些 API 阻止浏覽器使用它，但這可能會導緻浏覽器沒辦法更好的響應，建議大家不要放棄這種免費的性能優化方案。
Chrome DevTools 有一個工具，可以讓我們測試頁面是否有使用 BF Cache 的資格。如果沒辦法使用 BF Cache ，工具一般都會告訴我們具體原因。最常見的原因是我們設定了 cache-control 這個 Header 的值為 no-storage或者在頁面中使用了 unload handler，這兩者都會阻止 BF Cache 的使用。
在 Lighthouse 10 中，也添加了一個類似的檢測能力，也可以解釋頁面不符合資格的原因。
BF Cache 是 Chrome 團隊為了讓網頁浏覽更快的正在開發的一系能力之一，這個領域還有一些其他的能力，比如預加載和預渲染也是可以改善網站 CLS 名額的。
動畫和轉換的處理
最後一個 CLS 建議是處理動畫和轉換。動畫通常用于移動端的内容，如 cookie banner 或從頂部或底部滑入的其他通知橫幅，者具體取決于這些動畫或過渡是怎麼編碼的，它們可以更少或者更有效，并且可以幫助優化 CLS。
動畫的渲染需要浏覽器重新布局頁面，是以需要更多的工作，即使脫離正常文檔流的絕對定位元素，例如使用 top 或 left 移動内容，也會将其計算為布局移位，即使它不會移動任何周圍其他的内容，内容本身也在移動，并且有可能影響其他内容，是以這也會影響 CLS。
使用 translate 進行相同的動畫不會在浏覽器的布局進行中移動内容，而是在合成器層中進行的，除了對于浏覽器來說工作量較小之外，這還意味着它無法影響其他的内容，這也意味着它對 CLS 的影響就變小了。是以我們的解決方案就是替換使用 top 或 left 的動畫，并且這種方式在所有的浏覽器中都得到了支援。
始終優先使用複合動畫，比如如 transform ，而不是圖層誘導的非複合動畫，如更改 top、right、bottom 和 left。
并且 Lighthouse 也有一個相關的能力來識别這些問題。
FID 優化建議
最後我們來看看使用者響應相關的優化建議，這包括使用者和頁面進行首次互動操作所花費的時間（FID），以及更全面的互動到下一次繪制的時間（INP）。
網站響應性的關鍵在于確定不阻塞主線程，因為這會導緻浏覽器無法響應使用者輸入。
分解長任務
第一個建議是識别并分解長任務，相當于給浏覽器一些喘息的空間，以便它能夠響應使用者輸入。
Chrome Devtools和 Lighthouse 将長任務定義為需要 50 毫秒或更長時間的渲染工作。這可能聽起來不是很多，但在浏覽器術語中，這可以是網站能感覺到比較好的響應或不響應的差別。
JavaScript 是單線程且貪婪的，一旦它占用了 CPU，它就會盡可能地一直保持它，直到它不能處理或者處理完畢為止。在這個例子中，即使有五個子程序，所有的五個程序也是會一個接一個地執行。是以，在我們的代碼中放置一些斷點就是關鍵了。
我們可以使用設定逾時 settimeout 0 毫秒延遲來放入非關鍵的工作和新的任務，這些新任務就會在已經排隊的任何任務之後執行。
還有一些新的和即将推出的浏覽器 API ，如 isInputPending、scheduler.postTask 和 scheduler.yield，它們可以幫助大家決定何時以及如何放棄主線程。有關更多詳細的資訊，可以去看 web.dev 上優化長任務的相關文章 ：https://web.dev/optimize-long-tasks/ 。另外，在 Google I/O 上，還有一個專門關于優化長任務的獨立演講。
去除不必要的 JS
盡管優化我們頁面上的 JavaScript 代碼執行是一個不錯的方法，但更好的方式是一開始就不要發送太大的 JavaScript。
現在的網站上加載的 JavaScript 越來越大了，但我們需要重新檢查一下有這些 JavaScript 是否都是必要的。
我們可以使用 Chrome Devtools 的 Coverage 特性來檢視我們的 JavaScript 有多少被執行了。如果在頁面加載期間沒有使用的大部分 JavaScript ，都可以考慮進行代碼分離以在需要時或浏覽器不太繁忙的時候加載這些代碼。
Aurora 團隊還開發了一個 xjs 腳本元件，允許我們加載較少且關鍵的第三方代碼，并采用各種政策來減少這些腳本的影響。标簽管理器是另一個容易積累舊 JavaScript 代碼的地方，這些代碼可能不再需要了。定期檢查我們的标簽，以確定删除所有标簽，因為即使它們不再觸發，它們仍然需要下載下傳、解析和編譯。
避免大型渲染更新
改善響應性的最後一個建議是避免大型渲染更新。JavaScript 不是唯一可以影響我們網站響應性的東西，如果浏覽器需要大量的工作來将頁面渲染到螢幕上，那麼浏覽器本身也可能會變慢。大型渲染更新可能會在有大量Dom 更改時發生，無論是有意還是由于一個更改導緻許多其他元素需要重新計算。避免大型渲染更新的最佳方法是保持較小的 Dom 結構，以便即使存在關聯效應，也可以快速處理它們。
我們還有一個 Lighthouse 審計工具來幫助大家實作這一目标。
CSS containment 是另一種分離網頁區域的方法，它可以告訴浏覽器某些區域中的元素可以不受其他區域更改的影響，進而減少布局的工作。
content-visibility 是 CSS containment 的一種擴充能力，允許我們能完全跳過離屏内容的布局和渲染。
最後，大家應該避免濫用 requestAnimationFrame API，它應應該隻用于關鍵的渲染工作，如果通過這個 API 安排了過多的工作，它會導緻渲染變慢。
這些就是我們認為大家首先應考慮的九個改善網站核心性能名額的優化建議。這并不是一個明确的清單，而是我們的研究表明可以真正提高大家網站性能的幾個更有影響力的選項。包括 Chrome Devtools、Lighthouse 和我們添加到 JavaScript 架構和平台中的元件，許多這些建議已經涵蓋在我們的各種工具中。但我們并沒有放松警惕，并且也在一直更新我們的工具和文檔，來呈現這些關鍵建議。
最後
一台電腦,一個鍵盤,盡情揮灑智慧的人生;幾行數字,幾個字母,認真編寫生活的美好;
一 個靈感,一段程式,推動科技進步,促進社會發展。
創作不易，喜歡的老鐵們加個關注，點個贊，打個賞，後面會不定期更新幹貨和技術相關的資訊，速速收藏，謝謝！你們的一個小小舉動就是對小編的認可，更是創作的動力。