本頁面由 Cloud Translation API 翻譯而成。

常見問題

什麼是 WebP？使用自動標記的好處

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

WebP 格式基本上是建立更小且美觀的圖片，協助提升網頁速度。

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

如果網站管理員想要改善網站效能，可以輕鬆為目前的圖片建立最佳化 WebP 替代項目，並根據鎖定的目標提供 WebP 的瀏覽器來提供這些建議。

WebP 有損支援
- Google Chrome (電腦版) 17 歲以上
- Google Chrome Android 25 以上版本
- Microsoft Edge 18 歲以上
- Firefox 65 以上版本
- Opera 11.10 以上版本
- 原生網路瀏覽器、Android 4.0 以上版本 (ICS)
WebP 有損、無損與 Alpha 版支援
- Google Chrome (電腦版) 23 以上版本
- Google Chrome Android 25 以上版本
- Microsoft Edge 18 歲以上
- Firefox 65 以上版本
- Opera 12.10 以上版本
- 原生網路瀏覽器，Android 4.2 以上版本 (JB-MR1)
- 26 歲以上的 Pale Moon
支援 WebP 動畫
- Google Chrome (電腦版和 Android 版) 32 以上版本
- Microsoft Edge 18 歲以上
- Firefox 65 以上版本
- 19 歲以上

另請參閱維基百科 WebP 文章。

如何偵測瀏覽器對 WebP 的支援？

因此，建議您只向可正常顯示這些圖片的用戶端提供 WebP 圖片，並在無法向用戶端使用舊版格式時，改用舊版格式。幸好，在用戶端和伺服器端都有偵測 WebP 支援的幾項技術。部分 CDN 供應商會在自家服務中提供 WebP 支援偵測。

透過 Accept 標頭進行伺服器端內容協商

網路用戶端通常會傳送「接受」的要求標頭，藉此指出他們願意接受的內容格式。如果瀏覽器提前指出它會「接受」 image/webp 格式，網路伺服器就知道它可以安全地傳送 WebP 圖片，大幅簡化內容協商。請點選下方連結以瞭解詳情。

Modernizer

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 開放原始碼專案頁面的下載部分取得。您可以在 WebM 網站上找到輕量解碼器的程式碼和 VP8 規格。如需容器規格，請參閱 RIFF 容器頁面。

WebP 圖片的大小上限為何？

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

WebP 格式支援哪些色域？

和 VP8 位元串流一致，有損 WebP 僅適用於 8 位元 Y'CbCr 4:2:0 (通常稱為 YUV420) 圖片格式。詳情請參閱 RFC 6386 VP8 資料格式與解碼指南第 2 節 (「格式總覽」) 一文。

Lossless WebP 僅適用於 RGBA 格式。請參閱 WebP 無損 Bitstream 規格。

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

是，通常從有損格式轉換為 WebP 無損格式時，反之亦然。這主要是因為色彩空間差異 (YUV420 和 ARGB) 以及兩者之間的轉換作業。

一般情況有以下三種：

如果來源圖片採用無損 ARGB 格式，則將 YUV420 空間空間取樣作業導入新色彩，且會比原始色彩降低。如果發生這種情況，通常來源是 PNG 格式且僅有少量顏色：如果轉換為有損 WebP (或類似有損 JPEG 檔案)，可能會導致檔案大小較大。
如果來源採用有損格式，使用無損 WebP 壓縮功能來擷取來源的有損性質，通常就會產生較大的檔案。這並不是 WebP 檔案，而是可以在將 JPEG 來源轉換為無損 WebP 或 PNG 格式時發生。
如果來源採用有損格式，且您嘗試以品質較高的壓縮格式壓縮。舉例來說，如果嘗試將品質為 80 的 JPEG 檔案轉換為品質為 95 的 WebP 檔案，則即使兩種格式都遺失，通常也會產生更大的檔案。評估來源的品質通常不易，因此如果檔案大小在較大範圍內，建議降低目標 WebP 品質。另一種則是避免使用品質設定，請改用 cwebp 工具中的 -size 選項或對等 API 指定特定檔案大小。舉例來說，指定原始檔案大小的 80% 可能有助於產生更優異的效能。

請注意，如果將 JPEG 來源轉換為有損 WebP 或將 PNG 來源轉換為無損 WebP 檔案，不太可能是這種檔案大小意外。

WebP 是否支援漸進式或交錯螢幕？

WebP 不提供 JPEG 或 PNG 格式的漸進式或交錯解碼重新整理功能。這通常會導致解碼用戶端的 CPU 和記憶體產生過多壓力，因為每個重新整理事件都必須完整通過解壓縮系統。

將漸進式的 JPEG 圖像解碼平均等同於將基準解碼 3 次。

此外，WebP 也提供漸進式解碼，系統會運用所有位元串流可用的位元組位元組，盡可能盡快產生可顯示的範例資料列。這樣做能在用戶端儲存記憶體、CPU 和重新繪製作業，同時提供下載狀態的視覺化提示。進階解碼 API 會提供漸進式解碼功能。

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

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

在 Eclipse 中建構程式庫：

確認您已連同 NDK 工具一併安裝 ADT 外掛程式，而且 NDK 路徑設定無誤 (Preferences > Android > NDK)。
建立新專案：檔案 > 新增 > 專案 > Android 應用程式專案。
複製或解除封裝 libwebp 到新專案中名為 jni 的資料夾。
將 swig/libwebp_java_wrap.c 新增至 LOCAL_SRC_FILES 清單。
在新專案上按一下滑鼠右鍵，然後選取「Android Tools」>「Add Native Support ...」，即可將其納入建構。
開啟專案屬性，然後前往 C/C++ Build > Behaviour。將 ENABLE_SHARED=1 新增至 Build (Incremental build) 區段，將 libwebp 建構為共用程式庫。

注意：設定 NDK_TOOLCHAIN_VERSION=4.8 通常可改善 32 位元的建構效能。
將 swig/libwebp.jar 新增至 libs/ 專案資料夾。
建構您的專案。這項操作會建立「libs/<target-arch>/libwebp.so」。
使用 System.loadLibrary("webp") 在執行階段載入程式庫。

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

如何搭配 C# 使用 libwebp？

您可以將 WebP 建構為可匯出 libwebp API 的 DLL。然後，這些函式就能以 C# 匯入。

建構 libwebp.dll。這將會正確設定 WEBP_EXTERN，以匯出 API 函式。
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

將 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 動畫有什麼好處？

相較於動畫 GIF，動畫 WebP 的優點

相較於 GIF 的 8 位元色彩和 1 位元 Alpha 版，WebP 支援 8 位元 Alpha 通道的 24 位元 RGB 顏色。
WebP 支援有損和無損壓縮；事實上，單一動畫可以結合有損和無損頁框。GIF 僅支援無損壓縮。WebP' 有損壓縮技術適用於以實際影片為基礎的動畫圖片 (日益增加的動畫圖片來源)。
WebP 所需的位元組少於 GIF¹。動畫式 GIF 轉換成有損 WebP 的檔案大小會減少 64%，而無損 WebP 變小了 19%。這一點在行動網路上尤其重要。
WebP 需要較少時間進行解碼，在「連結」中，捲動或變更分頁可以隱藏並顯示圖片，導致動畫暫停後指向另一個點。導致 CPU 使用動畫捨棄影格過多的情況，也可能需要解碼器在動畫中向前快轉。在這類情況下，動畫 WebP 總解碼時間是 GIF 的 0.57 倍²，因此在捲動期間可以減少資源浪費，同時快速恢復 CPU 使用率高峰。這是因為 WebP 與 GIF 有兩項優點：
- WebP 圖片會儲存每個影格是否包含 Alpha 版的中繼資料，因此無需解碼影格以做出判斷。這可以更準確地推斷特定影格依賴的是哪些先前影格，進而減少之前影格的不必要的解碼作業。
- 如同新型影片編碼器，WebP 編碼器會主動加入重要影格 (大多數 GIF 編碼器都不支援)。這項功能可大幅改善在長動畫中尋找歌曲的時間。為方便插入這類影格而不需大幅增加圖片大小，WebP 還會針對各個影格加上 'blending' 旗標。除了 GIF 使用，這可讓主要畫面格繪製為如同將整個圖片清除為背景顏色，而不強制使用前一個畫格。

與 GIFP 動畫相比，GIF 動畫的缺點

如果缺乏 Search Console 的直線解碼，CPU 的耗用量就高於 GIF。有損 WebP 的解碼時間是 GIF 的 2.2 倍，無損 WebP 需要 1.5 倍。
WebP 支援幾乎不如 GIF 支援，因此相當普遍。
為瀏覽器新增 WebP 支援，增加程式碼足跡和攻擊面。在 Blink 中，這大約有 1500 行程式碼 (包括 WebP demux 程式庫和 Blink 端 WebP 圖片解碼器)。請注意，如果 WebP 和 WebM 共用較常見的解碼程式碼，或者 WebP' 的功能會排除在 WebM's 中，則日後可能會減少這個問題。

為什麼不直接在 <img> 支援 WebM？

長期支援 <img> 標記的影片格式。不過，在這種情況下，如果 <img> 中的 WebM 可以填入建議的 WebP 角色，就會發生問題：

解碼依賴先前影格的影格時，WebM 需要的記憶體數量會比動畫 WebP 多 50%，以保留先前的影格數量下限³。
不同瀏覽器和裝置的影片轉碼器和容器支援大小不盡相同。為了協助自動內容轉碼 (例如為節省頻寬的 Proxy)，瀏覽器必須新增接受標頭，指出圖片標記支援的格式。但這可能不足，因為 MIME 類型 (例如「video/webm」或「video/mpeg」) 仍然不代表轉碼器支援，例如 VP8 和 VP9。另一方面，WebP 格式有效被凍結，如果提供供應商的供應商同意發布 WebP 動畫，則所有通用 Analytics (分析) 的 WebP 行為應保持一致；且「image/webp」應接受標頭已用於表示 WebP 支援，因此無需變更新的接受標頭。
Chromium 影片堆疊已針對流暢播放體驗進行最佳化，並假設一次只能播放一或兩部影片。因此，在採用系統資源 (執行緒、記憶體等) 時，該團隊採取積極的措施，以盡可能提高播放品質。這種實作方式並不適用於許多同時錄影的影片，因此必須重新設計，適合與有大量圖片的網頁搭配使用。
WebM 目前不支援整合 WebP 的所有壓縮技術。因此，與替代圖片相比，這張圖片的 WebP 壓縮效果更好：

¹ 針對動畫 GIF 和 WebP 動畫之間的所有比較，我們使用大約 7, 000 張從網頁隨機擷取動畫 GIF 圖片的語料庫。這些圖片使用 'gif2webp' 以預設設定進行轉換 (以 2013 年 10 月 8 日最新的 libwebp 原始碼樹狀結構建構而成)。比較數字是這些圖片的平均值。

² 截至 2013 年 10 月 8 日為止，系統會使用基準工具使用最新的 libwebp + ToT Blink 來解碼解碼時間。「使用要搜尋的解碼時間」的計算方式為「解碼前五個影格、清除影格緩衝區快取、接下來的五個影格解碼等。」

³ WebM 在記憶體中會保留 4 個 YUV 參照影格，每個影格的大小 (寬度 + 96)*(高度 + 96) 像素。對於 YUV 4:2:0，我們每 6 像素需要 4 個位元組 (或每個像素 3/2 個位元組)。因此，這些參照頁框使用 4*3/2*(width+96)*(height+96) 個位元組的記憶體。另一方面，WebP 只需要前一個影格 (RGBA) 即可使用，也就是 4*width*height 位元組的記憶體。

⁴ 如要使用 WebP 轉譯功能，必須使用 Google Chrome 32 以上版本