建站
咨詢
售后
建站咨詢
新聞中心
背景說明
火山引擎veImageX演進之路主要介紹了veImageX在字節(jié)內部從2012年隨著字節(jié)成長過程中逐步演進的過程，演進中包括V1、V2、V3版本并最終面向行業(yè)輸出；整個演進過程中包括服務端、客戶端、網(wǎng)絡庫、業(yè)務場景與優(yōu)化等多個角度介紹在圖像處理壓縮、省成本與體驗優(yōu)化的經(jīng)驗與方案；
本篇文章重點介紹在web端演進和提供的能力，圖片是 Web 站點中的重要元素，圖片體積、格式、分辨率以及渲染方式對用戶體驗有著顯著影響?；鹕揭鎣eImageX 為業(yè)務提供了靈活、高效的一站式圖片解決方案和靜態(tài)素材托管方案，涵蓋了上傳、存儲、處理、分發(fā)、評估等圖片生產和消費階段的全部鏈路。
解決的問題
Web 場景下圖片的應用非常廣泛，從傳統(tǒng)的圖文到視頻封面都有圖片的身影，圖片體驗是用戶體驗中很重要的一環(huán)，常用于衡量站點性能的 LCP 和 CLS 指標都把圖片列為最重要的元素之一。隨著業(yè)務的發(fā)展，用戶量增長的同時也帶來了 CDN 帶寬成本的快速提升，最主要的元素則是圖片和視頻。因此，方案從體驗和成本出發(fā)，旨在為用戶提升體驗的同時降低帶寬成本。
用戶體驗可視化
圖片體驗問題通常有以下幾點：
- 加載速度慢：圖片體積、網(wǎng)絡、CDN、處理耗時等因素均會影響加載耗時；
- 加載失敗率高：導致圖片加載失敗的因素很多，重點在于如何及時定位問題；
- 渲染體驗差：包括圖片區(qū)域長時間空白、加載后導致頁面抖動、出錯后無兜底等場景；
開發(fā)者往往忽視了圖片體驗，也不了解圖片對站點性能的影響，并且缺少可量化的數(shù)據(jù)來衡量站點的圖片體驗。參考 Lighthouse 性能優(yōu)化指南，方案整合了圖片壓縮、圖片懶加載、圖片穩(wěn)定性布局、錯誤兜底等能力，并集成了數(shù)據(jù)監(jiān)控能力，可結合 火山引擎veImageX 控制臺實時大盤數(shù)據(jù)查看，為業(yè)務提供數(shù)據(jù)上報、數(shù)據(jù)分析、數(shù)據(jù)追蹤、數(shù)據(jù)告警等全鏈路支持。
帶寬成本問題
以下問題通常會帶來額外的帶寬成本：
- 圖片壓縮率低；
- 圖片原始分辨率和渲染分辨率不匹配；
- 采用傳統(tǒng)的 PNG、JPEG 等低壓縮率格式；
- 圖片未進行懶加載；
除了圖片壓縮，方案支持了 WebP、AVIF 等高壓縮率圖片格式的自適應加載和圖片分辨率的自適應加載，盡可能減小圖片體積。同時集成了圖片懶加載，避免不可見區(qū)域的圖片加載，降低站點 CDN 成本，同時也提升站點整體加載速度。根據(jù)內部業(yè)務數(shù)據(jù)，圖片傳輸帶寬和圖片加載耗時通?？山档?50% 以上。
方案架構
方案總體上可劃分為圖片加載和數(shù)據(jù)監(jiān)控兩個部分。
圖片
方案架構.png
如圖所示，圖片加載部分支持分辨率、格式自適應以及懶加載、穩(wěn)定性布局等特性，其中涉及到圖片處理部分基于火山引擎veImageX 服務實現(xiàn)，如圖片轉碼、縮放、壓縮等。SDK 側生成當前環(huán)境下最佳的圖片格式和分辨率，從服務獲取相應的圖片 URL，借助云端處理能力在運行時動態(tài)生成所需的圖片。
數(shù)據(jù)監(jiān)控部分可分為加載耗時監(jiān)控、圖片詳情監(jiān)控、畫質評估、大圖監(jiān)控、云控配置幾部分，監(jiān)控 SDK 收集相關數(shù)據(jù)，根據(jù)云端下發(fā)的配置上報數(shù)據(jù)，火山引擎veImageX 服務對數(shù)據(jù)做清洗后可在控制臺側查看數(shù)據(jù)大盤。
模塊詳細介紹
圖片加載
圖片格式自適應
常見的圖片格式有 PNG、JPEG、GIF、WebP、AVIF、HEIC 等，其中 WebP、AVIF、HEIC 等高壓縮率圖片格式可顯著減小圖片體積。但由于不同瀏覽器對高壓縮率格式的支持情況不同，因此在應用時需要考慮圖片加載的環(huán)境。三種高壓縮率格式在 Web 側的兼容性如下：
- WebP
圖片
- AVIF
圖片
- HEIC
圖片
在 APP 端，對于不支持的圖片格式可采用 SDK 軟解的方式進行解碼、渲染，Native 側的性能可保證圖片解碼的耗時和流量的節(jié)省都能有不錯的收益。在 Web 側，由于瀏覽器性能限制，veImageX 內部性能測試表明，SDK 軟解在圖片整體耗時方面的收益并不明顯，尤其是多圖場景下，因此在 Web 側更適合走格式自適應的方案，即根據(jù)瀏覽器的支持性加載相對最優(yōu)的圖片格式。
常見的做法是采用標簽以實現(xiàn)格式的自適應，標簽有相對不錯的兼容性，支持包含零或多個元素和一個 元素來為不同的瀏覽器環(huán)境提供圖片版本，瀏覽器會自上而下選擇可以被渲染的圖片，若沒有匹配的，則選擇 元素當中的圖片作為兜底。加載 SDK 最初也采用了該方案，如下：
但由于瀏覽器版本眾多，在實際應用中，可能會出現(xiàn)很多預期以外的情況，比如：
- 會同時加載多個圖片資源，造成帶寬的浪費；
- 并非完全支持 WebP 的所有特性，存在加載失敗的場景；
- 只支持 AVIF 靜圖格式，不支持動圖；
- ...
為了保證圖片加載成功率，因此在實際應用中無法直接使用標簽，加載 SDK 目前采用格式探測 +相結合的方式來解決該問題。同時，由于 HEIC 支持率太低，格式自適應目前只做了 WebP 和 AVIF 的自適應，同等質量下，WebP 相比 JPEG 可減少 30% 的圖片體積，AVIF 則可在 WebP 的基礎上再減少 20%；
圖片分辨率自適應
分辨率自適應指的是客戶端根據(jù)實際渲染的寬高獲取相應分辨率的圖片，從而減小圖片體積。常見的做法是我們可以借助 HTML 中原生的 srcset 屬性來定義圖像集，以及每個圖像應用的場景。由以下三部分組成：
- 文件名
- 空格
- 圖像描述符，有兩種描述方式
- 寬度描述符 w，描述圖像的固有寬度，以像素為單位。比如 480w 表示當瀏覽器需要 480 像素寬的圖像時應該使用的圖像資源
- 像素密度描述符 x，描述了顯示器的像素密度和圖片資源之間的對應關系，通過
window.devicePixelRatio可查詢顯示器像素密度
sizes 則定義了一組媒體條件，比如：屏幕寬度。并且指明當媒體條件為真時最佳的圖片尺寸。每個條件由以下三部分組成：
- 一個媒體條件，比如
max-width:480px，表示可視窗口的寬度不超過480像素時 - 空格
- 當媒體條件為真時，應該選用的圖片大小
可以將標簽和 srcset 屬性相結合，實現(xiàn)格式和分辨率的自適應，如下：
![]()
然而在實際中又會面臨一些問題，如：
- 指定多個 srcset 會增加 HTML 文件大小，尤其是當中存在多個的場景；
- 媒體查詢條件只能是屏幕寬度和像素密度，不能準確反映真實的圖片渲染情況；
- srcset 配合 sizes 使用，理解成本相對較高；
- ...
在實際應用中，某些情況下可以提前知道圖片渲染大小或者圖片所在區(qū)域的大小，結合方案內置的幾種布局方式以及設備像素密度等信息，加載 SDK 內部可以分析并選擇出當前模塊渲染的最佳分辨率。
圖片穩(wěn)定性布局
Web 側通常基于 CLS（Cumulative Layout Shift，累積布局偏移）指標用于衡量頁面布局的視覺穩(wěn)定性。當可見元素的位置在頁面生命周期內發(fā)生了變化時，就會產生布局偏移。
導致布局偏移的因素有很多（如：動態(tài)插入元素、iframe加載），無尺寸的圖片是影響 CLS 指標的重要因素之一。例如下面兩個頁面中，右側指定了圖片寬高的頁面要比左側沒有指定圖片寬高的頁面穩(wěn)定性更好。
圖片
受 next/image 的啟發(fā)，加載 SDK 內置了四種穩(wěn)定性布局方式：intrinsic、responsive、fixed、fill，通過生成穩(wěn)定的 dom 結構來提升視覺穩(wěn)定性，減少業(yè)務開發(fā)量。效果如下：
圖片
- intrinsic: 若指定寬度小于容器寬度，則根據(jù)指定寬高渲染圖片；反之則圖片寬度為容器寬，圖片高度按照比例縮??；
- responsive: 圖片渲染寬度等于容器寬度，高度按比例縮放；
- fixed: 根據(jù)指定寬高渲染圖片；
- fill: 圖片縮放以填充容器，可傳入 objectFit、objectPosition 屬性表示不同的填充模式；
圖片懶加載
對于圖片懶加載最簡單的做法是基于 的原生屬性 loading="lazy"，但在實際的應用中也發(fā)現(xiàn)了兩個問題：
- 該屬性的兼容性不達標，多數(shù)瀏覽器不支持；
- 在部分 Safari 瀏覽器上存在 bug，可能會導致圖片加載被阻塞；
因此，SDK 內部基于 IntersectionObserver API 實現(xiàn)，該 API 相對更可控，且可以設置懶加載的距離、目標元素等屬性。
數(shù)據(jù)監(jiān)控
圖片
數(shù)據(jù)監(jiān)控.png
數(shù)據(jù)監(jiān)控的整體鏈路為：
- 監(jiān)聽全局的 Load 和 Error 事件，并篩選出屬于圖片的部分；
- 基于 PerformanceObserver 監(jiān)聽圖片資源加載，該事件回調中可拿到圖片加載耗時相關的指標，如 DNS、TCP、SSL、請求、下載各個階段的耗時，并且可以基于該 API 監(jiān)聽 CSS 中圖片資源的加載；
- 對于圖片格式、狀態(tài)碼、畫質打分等信息則依賴 Response Header，而拿到 Response Header 僅有 request 資源這一種方式，因此在資源加載后再去 request 本地緩存中的信息，同時為避免并發(fā)請求影響其他類型的 HTTP 請求，SDK 會根據(jù)采樣率、當前請求量等信息在空閑時讀取需要上報的圖片的緩存；
- 整合所有原始數(shù)據(jù)，根據(jù)采樣率上報至 veImageX 數(shù)據(jù)服務，由數(shù)據(jù)服務對原始數(shù)據(jù)做清洗；
- 經(jīng)過后端服務處理后最終即可在 veImageX 質量監(jiān)控大盤查看，具體支持的指標及維度如下圖所示：
- 下行網(wǎng)絡監(jiān)控
圖片
- 客戶狀態(tài)監(jiān)控
圖片
方案演進
方案致力于為 Web 場景提供極致的圖片加載體驗，同時在穩(wěn)定性和場景覆蓋上也在不斷提升。
更低的錯誤率
上面提到在某些瀏覽器下會存在部分 WebP、AVIF 圖片加載失敗的場景，在監(jiān)控到此類場景后加載 SDK 基于格式探測的方式最低成本的解決了此類問題，同時保證了性能。
例如：在 iOS 14.3 & 14.4 版本下的 Safari 瀏覽器加載部分的 WebP 失敗，而標簽并不會對 WebP 的支持性做檢測，其對于傳入的 WebP 格式是全盤接收的，且 SDK 也無法對所有傳入的圖片做檢測，因此只能通過構造特定圖片，在業(yè)務圖片加載前對其進行檢測從而規(guī)避該問題，如下：
const checkWebP = () => {
const pro: Promise = new Promise((resolve) => {
if(typeof window === 'undefined') resolve(false);
if (window['__support_webp__'] !== undefined) {
resolve(!!window['__support_webp__']);
} else {
const img = new Image();
img.onload = () => {
window['__support_webp__'] = true;
resolve(true);
};
img.onerror = () => {
window['__support_webp__'] = false;
resolve(false);
};
img.src = 'error image';
}
});
return pro;
}; 更多的場景覆蓋
目前方案支持了 React、Vue2、Vue3 以及小程序，為了保證體驗的一致性、降低維護成本，加載 SDK 做了分層的設計，將核心的 Core 層抽離出來給到各個框架使用，并對各項能力做了插件化。
場景覆蓋.png
小結
隨著方案的迭代，我們也在嘗試覆蓋更多的業(yè)務場景，比如：加密圖渲染、Hybrid HEIC 渲染等，火山引擎veImageX 希望給客戶帶來全面、穩(wěn)定、流暢的圖片體驗，同時給業(yè)務帶來極致的成本收益。
我們將如上能力封裝成簡單的webSDK，向行業(yè)輸出，并可以免費獲取和使用此SDK，更高級的能力也可以配合veImageX來使用；
本文名稱：veImageX演進之路：Web圖片加載提速50%
文章路徑：http://www.dlmjj.cn/article/dhhcjej.html
