背景說明

火山引擎veImageX演進之路主要介紹了veImageX在字節內部從2012年隨著字節成長過程中逐步演進的過程，演進中包括V1、V2、V3版本并最終面向行業輸出；整個演進過程中包括服務端、客戶端、網絡庫、業務場景與優化等多個角度介紹在圖像處理壓縮、省成本與體驗優化的經驗與方案；

本篇文章重點介紹在web端演進和提供的能力，圖片是 Web 站點中的重要元素，圖片體積、格式、分辨率以及渲染方式對用戶體驗有著顯著影響。火山引擎veImageX 為業務提供了靈活、高效的一站式圖片解決方案和靜態素材托管方案，涵蓋了上傳、存儲、處理、分發、評估等圖片生產和消費階段的全部鏈路。

解決的問題

Web 場景下圖片的應用非常廣泛，從傳統的圖文到視頻封面都有圖片的身影，圖片體驗是用戶體驗中很重要的一環，常用于衡量站點性能的 LCP 和 CLS 指標都把圖片列為最重要的元素之一。隨著業務的發展，用戶量增長的同時也帶來了 CDN 帶寬成本的快速提升，最主要的元素則是圖片和視頻。因此，方案從體驗和成本出發，旨在為用戶提升體驗的同時降低帶寬成本。

用戶體驗可視化

圖片體驗問題通常有以下幾點：

• 加載速度慢：圖片體積、網絡、CDN、處理耗時等因素均會影響加載耗時；
• 加載失敗率高：導致圖片加載失敗的因素很多，重點在于如何及時定位問題；
• 渲染體驗差：包括圖片區域長時間空白、加載后導致頁面抖動、出錯后無兜底等場景；

開發者往往忽視了圖片體驗，也不了解圖片對站點性能的影響，并且缺少可量化的數據來衡量站點的圖片體驗。參考 Lighthouse 性能優化指南，方案整合了圖片壓縮、圖片懶加載、圖片穩定性布局、錯誤兜底等能力，并集成了數據監控能力，可結合 火山引擎veImageX 控制臺實時大盤數據查看，為業務提供數據上報、數據分析、數據追蹤、數據告警等全鏈路支持。

帶寬成本問題

以下問題通常會帶來額外的帶寬成本：

• 圖片壓縮率低；
• 圖片原始分辨率和渲染分辨率不匹配；
• 采用傳統的 PNG、JPEG 等低壓縮率格式；
• 圖片未進行懶加載；

除了圖片壓縮，方案支持了 WebP、AVIF 等高壓縮率圖片格式的自適應加載和圖片分辨率的自適應加載，盡可能減小圖片體積。同時集成了圖片懶加載，避免不可見區域的圖片加載，降低站點 CDN 成本，同時也提升站點整體加載速度。根據內部業務數據，圖片傳輸帶寬和圖片加載耗時通常可降低 50% 以上。

方案架構

方案總體上可劃分為圖片加載和數據監控兩個部分。

圖片

方案架構.png

如圖所示，圖片加載部分支持分辨率、格式自適應以及懶加載、穩定性布局等特性，其中涉及到圖片處理部分基于火山引擎veImageX 服務實現，如圖片轉碼、縮放、壓縮等。SDK 側生成當前環境下最佳的圖片格式和分辨率，從服務獲取相應的圖片 URL，借助云端處理能力在運行時動態生成所需的圖片。

數據監控部分可分為加載耗時監控、圖片詳情監控、畫質評估、大圖監控、云控配置幾部分，監控 SDK 收集相關數據，根據云端下發的配置上報數據，火山引擎veImageX 服務對數據做清洗后可在控制臺側查看數據大盤。

模塊詳細介紹

圖片加載

圖片格式自適應

常見的圖片格式有 PNG、JPEG、GIF、WebP、AVIF、HEIC 等，其中 WebP、AVIF、HEIC 等高壓縮率圖片格式可顯著減小圖片體積。但由于不同瀏覽器對高壓縮率格式的支持情況不同，因此在應用時需要考慮圖片加載的環境。三種高壓縮率格式在 Web 側的兼容性如下：

1. WebP

圖片

2. AVIF

圖片

3. HEIC

圖片

在 APP 端，對于不支持的圖片格式可采用 SDK 軟解的方式進行解碼、渲染，Native 側的性能可保證圖片解碼的耗時和流量的節省都能有不錯的收益。在 Web 側，由于瀏覽器性能限制，veImageX 內部性能測試表明，SDK 軟解在圖片整體耗時方面的收益并不明顯，尤其是多圖場景下，因此在 Web 側更適合走格式自適應的方案，即根據瀏覽器的支持性加載相對最優的圖片格式。

常見的做法是采用標簽以實現格式的自適應，標簽有相對不錯的兼容性，支持包含零或多個元素和一個  元素來為不同的瀏覽器環境提供圖片版本，瀏覽器會自上而下選擇可以被渲染的圖片，若沒有匹配的，則選擇  元素當中的圖片作為兜底。加載 SDK 最初也采用了該方案，如下：

<picture>
  <source srcset="image1.webp" type="image/webp" />
  <img src="image1.jpg" decoding="async" loading="lazy"/>
</picture>

但由于瀏覽器版本眾多，在實際應用中，可能會出現很多預期以外的情況，比如：

• 會同時加載多個圖片資源，造成帶寬的浪費；
• 并非完全支持 WebP 的所有特性，存在加載失敗的場景；
• 只支持 AVIF 靜圖格式，不支持動圖；
• ...

為了保證圖片加載成功率，因此在實際應用中無法直接使用標簽，加載 SDK 目前采用格式探測 +相結合的方式來解決該問題。同時，由于 HEIC 支持率太低，格式自適應目前只做了 WebP 和 AVIF 的自適應，同等質量下，WebP 相比 JPEG 可減少 30% 的圖片體積，AVIF 則可在 WebP 的基礎上再減少 20%；

圖片分辨率自適應

分辨率自適應指的是客戶端根據實際渲染的寬高獲取相應分辨率的圖片，從而減小圖片體積。常見的做法是我們可以借助 HTML 中原生的 srcset 屬性來定義圖像集，以及每個圖像應用的場景。由以下三部分組成：

• 文件名
• 空格
• 圖像描述符，有兩種描述方式

• 寬度描述符 w，描述圖像的固有寬度，以像素為單位。比如 480w 表示當瀏覽器需要 480 像素寬的圖像時應該使用的圖像資源
• 像素密度描述符 x，描述了顯示器的像素密度和圖片資源之間的對應關系，通過window.devicePixelRatio可查詢顯示器像素密度

sizes 則定義了一組媒體條件，比如：屏幕寬度。并且指明當媒體條件為真時最佳的圖片尺寸。每個條件由以下三部分組成：

• 一個媒體條件，比如max-width:480px，表示可視窗口的寬度不超過480像素時
• 空格
• 當媒體條件為真時，應該選用的圖片大小

可以將標簽和 srcset 屬性相結合，實現格式和分辨率的自適應，如下：

<picture>
  <source   
      srcset="image1.webp 200w,
              image2.webp 600w"
      sizes="100vw"
      type="image/webp"
   />
   <img 
      srcset="image1.jpg 200w,
              image2.jpg 600w"
      sizes="100vw"
      decoding="async"
      loading="lazy"
   />
</picture>

然而在實際中又會面臨一些問題，如：

• 指定多個 srcset 會增加 HTML 文件大小，尤其是當中存在多個的場景；
• 媒體查詢條件只能是屏幕寬度和像素密度，不能準確反映真實的圖片渲染情況；
• srcset 配合 sizes 使用，理解成本相對較高；
• ...

在實際應用中，某些情況下可以提前知道圖片渲染大小或者圖片所在區域的大小，結合方案內置的幾種布局方式以及設備像素密度等信息，加載 SDK 內部可以分析并選擇出當前模塊渲染的最佳分辨率。

圖片穩定性布局

Web 側通常基于 CLS（Cumulative Layout Shift，累積布局偏移）指標用于衡量頁面布局的視覺穩定性。當可見元素的位置在頁面生命周期內發生了變化時，就會產生布局偏移。

導致布局偏移的因素有很多（如：動態插入元素、iframe加載），無尺寸的圖片是影響 CLS 指標的重要因素之一。例如下面兩個頁面中，右側指定了圖片寬高的頁面要比左側沒有指定圖片寬高的頁面穩定性更好。

圖片

受 next/image 的啟發，加載 SDK 內置了四種穩定性布局方式：intrinsic、responsive、fixed、fill，通過生成穩定的 dom 結構來提升視覺穩定性，減少業務開發量。效果如下：

圖片

• intrinsic: 若指定寬度小于容器寬度，則根據指定寬高渲染圖片；反之則圖片寬度為容器寬，圖片高度按照比例縮小；
• responsive: 圖片渲染寬度等于容器寬度，高度按比例縮放；
• fixed: 根據指定寬高渲染圖片；
• fill: 圖片縮放以填充容器，可傳入 objectFit、objectPosition 屬性表示不同的填充模式；

圖片懶加載

對于圖片懶加載最簡單的做法是基于  的原生屬性 loading="lazy"，但在實際的應用中也發現了兩個問題：

• 該屬性的兼容性不達標，多數瀏覽器不支持；
• 在部分 Safari 瀏覽器上存在 bug，可能會導致圖片加載被阻塞；

因此，SDK 內部基于 IntersectionObserver API 實現，該 API 相對更可控，且可以設置懶加載的距離、目標元素等屬性。

數據監控

圖片

數據監控.png

數據監控的整體鏈路為：

1. 監聽全局的 Load 和 Error 事件，并篩選出屬于圖片的部分；
2. 基于 PerformanceObserver 監聽圖片資源加載，該事件回調中可拿到圖片加載耗時相關的指標，如 DNS、TCP、SSL、請求、下載各個階段的耗時，并且可以基于該 API 監聽 CSS 中圖片資源的加載；
3. 對于圖片格式、狀態碼、畫質打分等信息則依賴 Response Header，而拿到 Response Header 僅有 request 資源這一種方式，因此在資源加載后再去 request 本地緩存中的信息，同時為避免并發請求影響其他類型的 HTTP 請求，SDK 會根據采樣率、當前請求量等信息在空閑時讀取需要上報的圖片的緩存；
4. 整合所有原始數據，根據采樣率上報至 veImageX 數據服務，由數據服務對原始數據做清洗；
5. 經過后端服務處理后最終即可在 veImageX 質量監控大盤查看，具體支持的指標及維度如下圖所示：

1. 下行網絡監控

圖片

1. 客戶狀態監控

圖片

方案演進

方案致力于為 Web 場景提供極致的圖片加載體驗，同時在穩定性和場景覆蓋上也在不斷提升。

更低的錯誤率

上面提到在某些瀏覽器下會存在部分 WebP、AVIF 圖片加載失敗的場景，在監控到此類場景后加載 SDK 基于格式探測的方式最低成本的解決了此類問題，同時保證了性能。

例如：在 iOS 14.3 & 14.4 版本下的 Safari 瀏覽器加載部分的 WebP 失敗，而標簽并不會對 WebP 的支持性做檢測，其對于傳入的 WebP 格式是全盤接收的，且 SDK 也無法對所有傳入的圖片做檢測，因此只能通過構造特定圖片，在業務圖片加載前對其進行檢測從而規避該問題，如下：

const checkWebP = () => {
  const pro: Promise<boolean> = new Promise<boolean>((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

小結

隨著方案的迭代，我們也在嘗試覆蓋更多的業務場景，比如：加密圖渲染、Hybrid HEIC 渲染等，火山引擎veImageX 希望給客戶帶來全面、穩定、流暢的圖片體驗，同時給業務帶來極致的成本收益。

我們將如上能力封裝成簡單的webSDK，向行業輸出，并可以免費獲取和使用此SDK，更高級的能力也可以配合veImageX來使用；