常見問題

什麼是 WebP？使用的好處

WebP 是一種有損和無損壓縮的方法，可用於在網路上找到的大量攝影、半透明和圖形圖片。有損壓縮程度可調整，方便使用者選擇檔案大小和影像品質之間的取捨。相較於 JPEG 和 JPEG 2000，WebP 的壓縮平均比 JPEG 和 JPEG 2000 多 30%，而且圖片品質不會因此下降 (請參閱比較研究)。

WebP 格式基本上就是建立更小、更美觀的圖片，有助於加快網頁載入速度。

哪些網路瀏覽器提供原生支援 WebP？

網站管理員如果希望提升網站效能，可以輕鬆為目前的圖片建立最佳化 WebP 替代方案，並根據支援 WebP 的瀏覽器，針對這些替代版本提供最佳選擇。

  • WebP 有損支援
    • Google Chrome (電腦) 17 以上版本
    • 適用於 Android 25 以上版本的 Google Chrome
    • Microsoft Edge 18 以上版本
    • Firefox 65 以上版本
    • Opera 11.10 以上版本
    • 原生網路瀏覽器，Android 4.0 以上版本 (ICS)
    • Safari 14 以上版本 (iOS 14 以上版本、macOS Big Sur+)
  • WebP 有損、無損和 Alpha 支援
    • Google Chrome (電腦) 23 以上版本
    • 適用於 Android 25 以上版本的 Google Chrome
    • Microsoft Edge 18 以上版本
    • Firefox 65 以上版本
    • Opera 12.10 以上版本
    • 原生網路瀏覽器，Android 4.2 以上版本 (JB-MR1)
    • 淡月 26 歲以上
    • Safari 14 以上版本 (iOS 14 以上版本、macOS Big Sur+)
  • WebP 動畫支援
    • Google Chrome (電腦版和 Android) 32 以上版本
    • Microsoft Edge 18 以上版本
    • Firefox 65 以上版本
    • Opera 19+
    • Safari 14 以上版本 (iOS 14 以上版本、macOS Big Sur+)

另請參閱：

如何偵測 WebP 瀏覽器支援？

建議您只向可正確顯示 WebP 圖片的用戶端提供圖片，並應針對無法重新採用的用戶端改回舊版格式。幸好，在用戶端和伺服器端，有幾種可用於偵測 WebP 支援的技術。有些 CDN 供應商在其服務中提供 WebP 支援偵測功能。

透過「接受標頭」進行伺服器端內容協商

網路用戶端通常會傳送「Accept」要求標頭，指出他們願意回應的內容格式。如果瀏覽器事先指出會「接受」image/webp 格式，網路伺服器知道可以安全傳送 WebP 圖片，大幅簡化內容交涉。請參閱下列連結瞭解詳情。

現代主義

Modernizr 是一個 JavaScript 程式庫，可協助您輕鬆偵測網路瀏覽器中的 HTML5 和 CSS3 功能支援。尋找 Modernizr.webp、Modernizr.webp.lossless、Modernizr.webp.alpha 和 Modernizr.webp.animation 屬性。

HTML5 <picture> 元素

HTML5 支援 <picture> 元素，可讓您按照優先順序列出多個替代圖片目標，這樣一來，用戶端就會要求第一個可正確顯示的候選圖片。請參閱 HTML5 Rocks 的討論。目前更多瀏覽器支援 <picture> 元素。

在自己的 JavaScript 中

另一種偵測方法，是嘗試解碼使用特定功能的極小 WebP 圖片，並檢查是否成功。示例：

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

請注意，載入圖片不會阻塞和非同步。這表示任何依賴 WebP 支援的程式碼都應放在回呼函式中。

Google 為什麼以開放原始碼的形式推出 WebP？

我們深信開放原始碼模型的重要性。在開放原始碼中使用 WebP，任何人都能處理該格式，並提出改善建議。有了您的意見和建議，我們相信 WebP 日後將更加實用，做為一張圖形格式。

如何將個人圖片檔案轉換為 WebP？

您可以使用 WebP 指令列公用程式，將個人圖片檔轉換為 WebP 格式。詳情請參閱使用 WebP。

如果您要轉換的映像檔很多，可以使用平台的殼層來簡化作業。例如，如要轉換資料夾中的所有 jpeg 檔案，請嘗試下列方法：

Windows：

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS：

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

如何判斷自己的 WebP 圖片品質？

目前，您可以將 WebP 檔案轉換為使用無損壓縮的常見格式 (例如 PNG)，然後用任何瀏覽器或圖片檢視器查看 PNG 檔案。如要快速掌握 WebP 品質，請參閱這個網站的圖片庫，瞭解如何並排相片比較。

如何取得原始碼？

您可以在 WebP 開放原始碼專案頁面的下載部分取得轉換器程式碼。如要瞭解輕量解碼器和 VP8 規格的程式碼，請參閱 WebM 網站。如需容器規格，請參閱 RIFF 容器頁面。

WebP 圖片的大小上限為何？

WebP 與 VP8 的位元串流相容，並使用 14 位元設定寬度和高度。 WebP 圖片的像素尺寸上限為 16383 x 16383。

WebP 格式支援哪些色域？

與 VP8 位元串流一樣，lossy WebP 僅支援 8 位元 Y'CbCr 4:2:0 (通常稱為 YUV420) 圖片格式。詳情請參閱 RFC 6386 的「格式總覽」和「VP8 資料格式和解碼指南」。

Lossless WebP 僅支援 RGBA 格式。請參閱 WebP Lossless Bitstream 規格。

WebP 圖片可以大於來源圖片的大小嗎？

是，通常在從有損格式轉換為 WebP 無損格式或反向格式時。這主要是因為色域差異 (YUV420 與 ARGB) 和兩者之間的轉換差異。

典型的情況有以下三種：

  1. 如果來源圖片採用無損 ARGB 格式，則從 YUV420 的空間向下取樣會導入，比原始圖片更難壓縮的新顏色。這種情況通常發生在來源是顏色較少的 PNG 格式時，如果轉換成有損 WebP 格式 (或類似有損 JPEG 的 JPEG) 時，檔案大小可能會較大。
  2. 如果來源為有損格式，使用無損 WebP 壓縮來擷取來源的有損性質，通常就會產生更大的檔案。這一點並不是 WebP 特有，在將 JPEG 來源轉換為無損 WebP 或 PNG 格式時可能會發生。
  3. 如果來源為有損格式，而您想將其壓縮為包含品質設定較佳的有損 WebP 格式，舉例來說，如果嘗試將儲存品質為 80 的 JPEG 檔案轉換為品質 95 的 WebP 檔案，則即使這兩種檔案都出現失真，系統通常還是會產生較大檔案。通常來說，評估來源品質是不可能的，因此如果檔案較大，建議降低目標 WebP 的品質。您也可以避免使用品質設定，而是改用 cwebp 工具或同等 API 中的 -size 選項，指定特定檔案大小。例如，若指定原始檔案大小的 80%，成效可能更加完善。

請注意，將 JPEG 來源轉換成有損 WebP 格式，或是將 PNG 來源轉換成無損 WebP 格式，較容易造成檔案大小意外。

WebP 是否支援漸進式或交錯顯示模式？

WebP 並未提供 JPEG 或 PNG 技術的漸進式或交錯解碼重新整理功能。這可能會導致解碼用戶端的 CPU 和記憶體承受過多壓力，因為每個重新整理事件都需要完全通過解壓縮系統。

平均而言，解碼漸進式 JPEG 圖片等同於解碼基準 3 次。

此外，WebP 提供「漸進式」解碼功能，在此情況下，所有可用位元串流的傳入位元組都會用於嘗試，並盡快產生可顯示的範例列。這樣做可以節省用戶端的記憶體、CPU 和重新繪製工作，同時提供下載狀態的視覺提示。您可以透過 Advanced Decoding API 使用漸進式解碼功能。

如何在 Android 專案中使用 libwebp Java 繫結？

WebP 支援將 JNI 繫結至 swig/ 目錄中的簡易編碼器和解碼器介面。

在 Eclipse 中建構程式庫：

  1. 請確認你連同 NDK 工具一併安裝 ADT 外掛程式，而且 NDK 路徑已正確設定 (「Preferences」 >「Android」 >「NDK」)。
  2. 依序點選「File」 >「New」 >「Project」 >「Android Application Project」。
  3. 將 libwebp 複製或解壓縮至新專案中的 jni 資料夾。
  4. 將 swig/libwebp_java_wrap.c 新增至 LOCAL_SRC_FILES 清單。
  5. 在新專案上按一下滑鼠右鍵，然後依序選取「Android Tools」 >「Add Native Support...」，將程式庫加入版本。

  6. 開啟專案屬性，然後依序前往「C/C++ Build」 >「Behaviour」。將 ENABLE_SHARED=1 新增至 Build (Incremental build) 區段，將 libwebp 建構為共用程式庫。

    注意事項：設定 NDK_TOOLCHAIN_VERSION=4.8 通常能夠改善 32 位元建構效能。

  7. 將 swig/libwebp.jar 新增至 libs/ 專案資料夾。

  8. 建構您的專案。這會建立 libs/<target-arch>/libwebp.so。

  9. 在執行階段使用 System.loadLibrary("webp") 載入程式庫。

請注意，您可以使用 ndk-build 和隨附的 Android.mk 手動建構程式庫。在此情況下，您可以重複使用上述某些步驟。

如何搭配 C# 使用 libwebp？

WebP 可以建構為可匯出 libwebp API 的 DLL。接著，這些函式可在 C# 中匯入。

  1. 建構 libwebp.dll。這會正確設定 WEBP_EXTERN，以匯出 API 函式。

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. 將 libwebp.dll 新增至專案，並匯入所需的函式。請注意，如果您使用簡易 API，應呼叫 WebPFree() 來釋出任何傳回的緩衝區。

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

為什麼要使用動畫 WebP？

動畫 WebP 與動畫 GIF 的優點

  1. 相較於 GIF 的 8 位元色彩和 1 位元 Alpha，WebP 支援具有 8 位元 Alpha 通道的 24 位元 RGB 顏色。

  2. WebP 同時支援有損和無損壓縮，事實上，單一動畫可以結合有損和無失真影格。GIF 僅支援無損壓縮。WebP 的有損壓縮技術非常適合用於從真實影片建立的動畫圖片，這類圖片逐漸成為普遍的動畫圖片來源。

  3. WebP 需要的位元組數小於 GIF1。轉換成有損 WebP 的 GIF 動畫則縮小了 64%，無損 WebP 則小於 19%。這在行動網路上特別重要。

  4. 發生跳轉時，WebP 可減少解碼的時間。在閃爍，捲動或變更分頁可以隱藏及顯示圖片，導致動畫暫停，然後快轉到其他點。如果 CPU 用量過大，導致動畫捨棄影格，解碼器可能也會需要在動畫中向前搜尋。在這類情況下，動畫 WebP 所需的總解碼時間是 GIF 的 0.57 倍2，因此不僅捲動過程中遇到資源浪費情形，也能夠因為 CPU 使用率遽增而快速復原。這是因為 WebP 而非 GIF 具有以下兩項優點：

    • WebP 圖片會儲存每個影格是否包含 Alpha 的中繼資料，因此無需解碼影格即可決定。如此一來，特定影格所依附的影格數就能更準確，進而減少之前影格的不必要的解碼。

    • 與現代影片編碼器類似，WebP 編碼器會自行嘗試，定期新增主要畫面格 (大多數 GIF 編碼器都不需要)。這大幅改善了長篇動畫的跳轉效果。為了在不大幅增加圖片大小的情況下插入這類影格，WebP 會為 GIF 使用的影格處理方法，以及每個影格新增「混合方法」標記。這樣一來，就能繪製主要畫面格，就像整個圖片已清除為背景顏色，而不強制前一個影格為全尺寸。

動畫 WebP 與動畫 GIF 的缺點

  1. 缺少跳轉時，與 GIF 相比，使用 WebP 的直線解碼會耗用更多 CPU 資源。對於失真的 WebP，DP 需要 2.2 倍的解碼時間，而無損 WebP 需要的 1.5 倍。

  2. WebP 支援功能的涵蓋範圍不如 GIF 格式，這可說是普及通用。

  3. 為瀏覽器新增 WebP 支援功能會增加程式碼用量和受攻擊面。在 Blink 中，這大約需要額外的 1500 行程式碼 (包括 WebP Demux 程式庫和 Blink-side WebP 圖片解碼器)。請注意，如果 WebP 和 WebM 共用較常見的解碼程式碼，或是 WebP 的功能遭到捨棄，這個問題日後可能會減少。

為什麼 <img> 不再只是 WebM？

因此，在 <img> 標記內支援影片格式可能很合理。不過，如果現在這個意圖中有 <img> 中的 WebM 可以填入動畫 WebP 提議的角色，就會發生問題：

  1. 在解碼依附於先前影格的影格時，WebM 需要比動畫 WebP 多 50% 的記憶體，以容納先前的影格數量下限3。

  2. 影片轉碼器和容器支援因瀏覽器和裝置而異。為了促進自動內容轉碼 (例如用於節省頻寬的 Proxy)，瀏覽器必須新增接受標頭，指出圖片代碼支援的格式。但數量可能不足，因為「video/webm」或「video/mpeg」等 MIME 類型仍未指出支援轉碼器 (例如 VP8 和 VP9)。另一方面，WebP 格式實際上會凍結，如果提供的話，提供該格式的供應商同意提供動畫 WebP，則所有通用 Analytics (分析) 中 WebP 的行為應保持一致。由於「image/webp」接受標頭已用於表示 WebP 支援，因此不需要變更新的接受標頭。

  3. Chromium 影片堆疊經過最佳化，可流暢播放，且會假設一次只播放一到兩部影片。因此，為了盡可能提升播放品質，實作會積極使用系統資源 (執行緒、記憶體等)。這種實作方式無法同時滿足許多影片的需求，因此需要重新設計，為適合含有大量圖片的網頁使用。

  4. WebM 目前並未納入 WebP 的所有壓縮技術。因此，這張圖片與 WebP 的壓縮效果優於其他替代方法：

1 針對 GIF 和動畫 WebP 之間的所有比較，我們使用了約 7000 張動畫 GIF 圖片從網路隨機擷取的圖片。這些圖片已使用預設設定「gif2webp」工具，轉換為動畫 WebP (截至 2013 年 10 月 8 日的最新 libwebp 來源樹)。比較數字是這些圖片的平均值。

2 截至 2013 年 10 月 8 日，我們使用基準工具使用最新的 libwebp + ToT Blink 計算解碼時間。「需要跳轉時間的解碼時間」的計算方式是「解碼前五個影格、清除影格緩衝區快取，以及解碼接下來五個影格，依此類推。」

3 WebM 會將 4 個 YUV 參考影格保存在記憶體中，每個影格的儲存 (width+96)*(height+96) 像素。如果是 YUV 4:2:0，我們需要每 6 像素 (或每像素 3/2 位元組) 4 個位元組。因此，這些參照影格會使用 4*3/2*(width+96)*(height+96) 位元組的記憶體。另一方面，WebP 只需要上一個影格 (以 RGBA 為單位)，也就是記憶體的 4*width*height 個位元組。

4 動畫 WebP 轉譯功能僅適用於 Google Chrome 32 以上版本