常見問題

什麼是 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)
    • Safari 14 以上版本 (iOS 14 以上版本、macOS Big Sur+)
  • WebP 有損、無損與 Alpha 版支援
    • Google Chrome (電腦版) 23 以上版本
    • Google Chrome Android 25 以上版本
    • 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 以上版本
    • 19 歲以上
    • Safari 14 以上版本 (iOS 14 以上版本、macOS Big Sur+)

另請參閱:

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

建議您只向能正確顯示圖片的用戶端提供 WebP 映像檔,而在無法進行用戶端的用戶端上,可改用舊版格式。幸好,在用戶端和伺服器端,可以透過多種技術偵測 WebP 支援。部分 CDN 供應商會在服務中提供 WebP 支援偵測。

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

網路用戶端通常會傳送「Accept」(接受) 要求標頭,以指定他們願意接受的內容格式。如果瀏覽器提前指出它會「接受」image/webp 格式,網路伺服器就知道它可以安全地傳送 WebP 圖片,大幅簡化了內容交涉流程。詳情請參閱下列連結。

摩登

Modernizr 是一個 JavaScript 程式庫,可用來偵測網路瀏覽器中的 HTML5 和 CSS3 功能支援。找出 Modernizr.webpModernizr.webp.lossless 屬性、Modernizr.webp.alphaModernizr.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) 以及兩者之間的轉換。

一般情況有以下三種:

  1. 如果來源圖片採用無損 ARGB 格式,則將 YUV420 空間空間降低取樣會引入更無法壓縮原始顏色的新色彩。如果發生這種情況,通常來源是 PNG 格式且僅有少量色彩:
  2. 如果來源採用有損格式,使用無損 WebP 壓縮功能來擷取來源的有損性質,通常就會產生較大的檔案。這並不是 WebP 檔案,而且在將 JPEG 來源轉換為無損 WebP 或 PNG 格式時會發生。
  3. 如果來源採用有損格式,而您想將其壓縮為有損的 WebP 設定,並採用較高的品質設定,舉例來說,如果嘗試將以品質 80 儲存的 JPEG 檔案轉換成品質為 95 的 WebP 檔案,則即使兩個格式都遺失,通常也會產生更大的檔案。評估來源品質通常並不容易,因此如果檔案大小持續較大,則建議降低目標 WebP 品質。另一種做法是避免使用品質設定,而使用 cwebp 工具中的 -size 選項或對等 API,指定特定檔案大小。舉例來說,如果指定原始檔案大小的 80%,可能有助於更可靠。

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

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

WebP 並未以 JPEG 或 PNG 格式提供漸進式或交錯式解碼重新整理。這可能會對解碼用戶端的 CPU 和記憶體造成過多壓力,因為每個重新整理事件都涉及完整的解壓縮系統。

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

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

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

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

Eclipse 中建構程式庫:

  1. 請確認您已在安裝 NDK 工具時一併安裝 ADT 外掛程式,且 NDK 路徑設定無誤 (Preferences > Android > NDK)。
  2. 建立新專案:檔案 > 新增 > 專案 > Android 應用程式專案
  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 動畫有什麼好處?

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

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

  2. WebP 支援有損和無損壓縮;事實上,單一動畫可以結合有損和無損頁框。GIF 僅支援無損壓縮。WebP 有損壓縮技術非常適合用於從實際影片中建立的動畫圖片 (日益增加的動畫圖片來源)。

  3. WebP 所需的位元組少於 GIF1。動畫 GIF 轉換成有損 WebP 的檔案大小會減少 64%,無損 WebP 則小 19%。這一點在行動網路上尤其重要。

  4. WebP 需要找回資料的時間較少。在 Blink 中,捲動或變更分頁可以隱藏和顯示圖片,導致動畫暫停後指向另一個點。導致 CPU 出現動畫捨棄影格的過度 CPU 用量,也可能需要解碼器在動畫中向前快轉。在這些情況下,動畫 WebP 總解碼時間是 GIF 的 0.57 倍2,所以在捲動過程中可以減少資源浪費,同時快速恢復 CPU 使用率高峰。與 WebP 相比 GIF 有兩大優點:

    • WebP 映像檔會儲存有關每個影格是否包含 Alpha 版的中繼資料,因此不需要將影格解碼以做出判斷。這可以更準確地推斷特定影格所依附的前一個影格,進而減少之前影格的非必要解碼。

    • 如同現代化影片編碼器,WebP 編碼器會隨機加入按鍵影格 (大多數 GIF 編碼器皆不支援)。可大幅增加在長片搜尋時的效果。為了方便插入這類影格而無需大幅增加圖片大小,WebP 還會針對各個影格加上 [混合方法] 標記,以及 GIF 使用的影格處理方法。這可讓主要畫面格繪製為如同將整個圖片已清除為背景顏色,而不強制使用前一個畫格。

與 GIF 動畫相比,GIF 動畫的缺點

  1. 如果缺乏理想情況,直接對 WebP 進行直線解碼的 CPU 量會比 GIF 來得高。有損 WebP 所需的解碼時間是 GIF 的 2.2 倍,無損 WebP 需要 1.5 倍。

  2. WebP 支援幾乎不如 GIF 支援,這相當普遍。

  3. 在瀏覽器中新增 WebP 支援,增加程式碼足跡和攻擊面。在 Blink 中,這大約有 1500 行程式碼 (包含 WebP demux 程式庫和 Blink 端 WebP 圖片解碼器)。請注意,如果 WebP 和 WebM 共用較常見的解碼代碼,或是 WebP 的功能發生在 WebM 中,則未來可能會減少這個問題。

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

<img> 標記中支援影片格式可能很合理。不過,由於現在 <img> 中的 WebM 可以填入所建議 WebP 中的角色,因此會發生問題:

  1. 解碼依賴先前影格的影格時,WebM 需要的記憶體比動畫 WebP 多出 50%,才能保留先前的影格數量下限3

  2. 各瀏覽器和裝置的視訊轉碼器和容器支援需求不盡相同。為了協助自動內容轉碼 (例如節省頻寬的 Proxy),瀏覽器必須新增接受標頭,指出圖片標記支援哪些格式。但這可能並不足夠,因為 MIME 類型 (例如「video/webm」或「video/mpeg」) 仍未指出轉碼器支援 (例如 VP8 與 VP9)。另一方面,WebP 格式有效被凍結,如果提供供應商的供應商同意傳送 WebP 動畫,則所有通用 Analytics (分析) 中的 WebP 行為應保持一致;且由於「image/webp」接受標頭已用於指出 WebP 支援,因此不需變更新的接受標頭。

  3. Chromium 影片堆疊已針對流暢播放體驗進行最佳化,並假設一次只會播放一或兩部影片。因此,在採用系統資源 (執行緒、記憶體等) 時,該團隊採取積極的措施,以盡可能提高播放品質。因為這類實作方式並無法同時套用至許多同時啟用的影片,因此必須重新設計,適合搭配大量圖片使用。

  4. WebM 目前沒有整合 WebP 的所有壓縮技術。因此,與替代圖片相比,這張圖片的 WebP 壓縮效果明顯更好:


1 針對動畫 GIF 和 WebP 動畫之間的所有比較,我們使用大約 7, 000 張從網路上隨機擷取的 GIF 動畫圖片資料庫。這些映像檔使用預設設定的「gif2webp」工具,以「Web2Webp」工具轉換為動畫 WebP (自 2013 年 10 月 8 日起的 libwebp 來源樹狀結構建構而成)。比較數字是這些圖片的平均值。

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

3 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 個位元組的記憶體。

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