Chrome把視頻延遲加載藏了6年，這次真敢動真格了

2019年，Chrome給圖片和iframe（內嵌框架）加上了懶加載——用戶滾動到附近才開始加載，頁面打開速度肉眼可見地變快。但視頻和音頻標簽里的多媒體內容，Chrome愣是晾了6年沒管。

Google現在宣布，Chrome 148版本要把這塊補丁打上。桌面端和移動端同步更新，代碼直接進Chromium（開源瀏覽器核心）倉庫，Edge這些"換皮瀏覽器"也會跟著喝湯。

為什么偏偏是第6年才動手

視頻音頻標簽在現代網頁里確實不如圖片常見。大多數站點要么用YouTube/ Vimeo外鏈，要么上H5播放器，原生video/audio標簽反而成了"遺老遺少"。

但遺老也有遺老的麻煩。比如新聞站點的視頻摘要、播客平臺的內嵌音頻，這些場景下標簽是輕量方案，卻拖著整頁加載速度。Google的測試數據顯示，部分頁面因視頻預加載多耗了30%的首屏時間。

技術債就是這樣。2019年解決80%的問題，剩下20%因為"不夠疼"被無限期擱置，直到某次性能審計翻出來。

懶加載到底省了什么

原理像餐廳上菜：先給前菜（文字、布局），主菜（視頻）等客人眼神飄過來再端。對帶寬敏感的用戶——地鐵通勤、偏遠地區、國際漫游——這意味著少付流量費。

更隱蔽的好處是電池。視頻解碼是耗電大戶，延遲加載等于減少無效運算。Chrome團隊沒公布具體數字，但參考2019年圖片懶加載的數據：某些頁面加載時間從3秒壓到1.5秒，數據用量砍掉一半。

這次擴展的邏輯完全一致：用戶沒看到的視頻，就當它不存在。

開發者要改什么

好消息是大概率不用改。Chrome的懶加載默認開啟，只要標簽本身帶loading="lazy"屬性，或者瀏覽器判斷元素在視口外足夠遠。

但有個細節：自動播放的視頻可能被策略攔截。Chrome對自動播放的限制本來就嚴——靜音才能自動播，用戶交互后才能有聲。懶加載疊加這層規則，意味著"滾動到+點擊"雙重觸發，部分舊站點需要檢查交互鏈路。

Edge、Opera、Brave等Chromium系瀏覽器會陸續跟進，時間表看各自維護團隊的合并速度。Safari和Firefox（火狐）不在此列，它們走自己的渲染引擎路線。

6年時間，足夠一個前端框架從爆紅到過氣。Google這次補票，是終于想起角落里那批原生標簽用戶，還是被Core Web Vitals（核心網頁指標）的考核壓力逼的？