このページは Cloud Translation API によって翻訳されました。

よくある質問

WebP とはメリット

WebP は不可逆圧縮と可逆圧縮の手法で、ウェブ上にあるさまざまな写真、半透明、グラフィック画像で使用できます。非可逆圧縮の度合いは調整できるため、ユーザーはファイルサイズと画質のトレードオフを選択できます。WebP は通常、画質を損なうことなく、JPEG および JPEG 2000 よりも平均で圧縮率が 30% 高くなりました（比較調査を参照）。

WebP 形式は、ウェブを高速化できるように、より小さく見栄えの良い画像を作成することを目的としています。

WebP をネイティブにサポートしているウェブブラウザ

サイトのパフォーマンス向上に関心をお持ちのウェブマスターは、現在の画像用に最適化された代替の WebP を簡単に作成し、WebP をサポートするブラウザにターゲットに基づいて提供できます。

WebP 非可逆サポート
- Google Chrome（パソコン）17 以降
- Google Chrome for Android バージョン 25 以降
- Microsoft Edge 18 以降
- Firefox 65 以降
- Opera 11.10 以降
- ネイティブウェブブラウザ、Android 4.0 以降（ICS）
- Safari 14 以降（iOS 14 以降、macOS Big Sur+）
WebP の非可逆、可逆圧縮、アルファのサポート
- Google Chrome（パソコン）23 以降
- Google Chrome for 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 以降
- Opera 19 以降
- Safari 14 以降（iOS 14 以降、macOS Big Sur+）

WebP のブラウザサポートを検出するにはどうすればよいですか？

WebP 画像を正しく表示できるクライアントにのみ配信し、表示できないクライアントには従来の形式にフォールバックする必要があります。WebP サポートを検出するには、クライアントサイドとサーバーサイドの両方にいくつかの手法があります。一部の CDN プロバイダは、サービスの一部として WebP サポート検出を提供しています。

Accept ヘッダーによるサーバーサイドのコンテンツネゴシエーション

ウェブクライアントは一般的に、応答で受け入れるコンテンツ形式を示す「Accept」リクエストヘッダーを送信します。ブラウザで事前に image/webp 形式を「受け入れる」ように指定していれば、ウェブサーバーは WebP 画像を安全に送信できることを認識し、コンテンツネゴシエーションを大幅に簡素化できます。詳しくは、以下のリンクをご覧ください。

モダニズル

Modernizr は、ウェブブラウザにおける HTML5 と CSS3 の機能サポートを簡単に検出するための JavaScript ライブラリです。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 をオープンソースとしてリリースしたのはなぜですか？

Google はオープンソースモデルの重要性を強く信じています。オープンソースの 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 形式でサポートされている色空間は何ですか？

非可逆 WebP は VP8 ビットストリームと同様に、8 ビットの Y'CbCr 4:2:0（YUV420 とも呼ばれます）画像形式でのみ動作します。詳細については、RFC 6386 のセクション 2「Format Overview」と VP8 Data Format and Decoding Guide をご覧ください。

可逆圧縮 WebP は RGBA 形式のみに対応しています。WebP Lossless Bitstream の仕様をご覧ください。

WebP 画像はソース画像よりも大きくなりますか？

はい。通常は、非可逆形式から WebP 可逆変換（またはその逆）を行います。その主な原因は、色空間の違い（YUV420 と ARGB）と、これらの変換によるものです。

一般的な状況には、次の 3 つがあります。

ソース画像が可逆 ARGB 形式の場合、YUV420 への空間ダウンサンプリングにより、元の色よりも圧縮が難しい新しい色が使用されます。このような状況は通常、色数の少ない PNG 形式のソースで発生します。非可逆 WebP（または非可逆 JPEG）に変換すると、ファイルサイズが大きくなる可能性があります。
ソースが非可逆形式の場合、可逆 WebP 圧縮を使用してソースの非可逆性をキャプチャすると、通常、ファイルが大きくなります。これは WebP に限ったことではなく、JPEG ソースを可逆 WebP 形式や PNG 形式に変換する場合などに発生することがあります。
ソースが非可逆形式のもので、これを高品質の設定で非可逆 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 には、swig/ ディレクトリのシンプルなエンコーダインターフェースとデコーダインターフェースへの JNI バインディングのサポートが含まれています。

Eclipse でライブラリをビルドする:

NDK ツールとともに ADT プラグインがインストールされており、NDK パスが正しく設定されていることを確認します（[Preferences] > [Android] > [NDK]）。
新しいプロジェクトを作成します（[File] > [New] > [Project] > [Android Application Project]）。
新しいプロジェクトの jni という名前のフォルダに libwebp のクローンを作成するか展開します。
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 の利点

WebP は、GIF の 8 ビットカラーと 1 ビットのアルファに対して、8 ビットのアルファチャンネル、24 ビットの RGB カラーをサポートしています。
WebP は、非可逆圧縮と可逆圧縮の両方をサポートしています。実際、単一のアニメーションで非可逆フレームと可逆フレームを組み合わせることができます。GIF は可逆圧縮のみに対応しています。WebP の不可逆圧縮手法は、アニメーション画像のソースが増えつつある現実世界の動画から作成されたアニメーション画像に適しています。
WebP で必要なバイト数は GIF¹ より少なくなります。非可逆 WebP に変換されたアニメーション GIF は 64% 小さく、可逆 WebP は 19% 小さくなります。これは、モバイルネットワークでは特に重要です。
シーク設定がある場合、WebP のデコード時間は短縮されます。Blink では、タブのスクロールやタブの変更により、画像の表示 / 非表示が切り替わるため、アニメーションが一時停止され、別の位置にスキップされます。CPU 使用率が過剰に高く、アニメーションのフレームが落ちる場合にも、デコーダがアニメーションを前方にシークする必要が生じる場合があります。このシナリオでは、アニメーション WebP は GIF の 0.57 倍の合計デコード時間²を要します。そのため、スクロール中のジャンクが減り、CPU 使用率の急増からの回復が速くなります。これは、WebP が GIF より優れている 2 つの利点によるものです。
- WebP 画像には、各フレームにアルファが含まれているかどうかに関するメタデータが保存されています。これにより、アルファを判断するためにフレームをデコードする必要がなくなります。これにより、特定のフレームがどの前のフレームに依存しているかをより正確に推測でき、前のフレームの不要なデコードを減らすことができます。
- 最新の動画エンコーダとほぼ同様に、WebP エンコーダは、キーフレームを一定間隔でヒューリスティック的に追加します（ほとんどの GIF エンコーダでは行いません）。これにより、長いアニメーションでのシークが大幅に改善されます。画像サイズを大幅に増やすことなくこのようなフレームを簡単に挿入できるように、WebP では、GIF で使用されているフレーム廃棄方法に加えて、各フレームに「ブレンド方法」フラグを追加します。これにより、前のフレームを強制的にフルサイズにすることなく、画像全体が背景色にクリアされたかのようにキーフレームを描画できます。

アニメーション GIF と比較したアニメーション WebP のデメリット

シークがない場合、WebP の直線デコードは GIF よりも CPU の負荷を高めます。非可逆 WebP のデコード時間は GIF の 2.2 倍であるのに対し、可逆 WebP のデコード時間は GIF の 1.5 倍です。
WebP サポートは、GIF サポートほど広く普及しているわけではありません。GIF サポートは実質的に普遍的です。
ブラウザに WebP のサポートを追加すると、コードのフットプリントと攻撃対象領域が増加します。Blink では、約 1,500 行の追加コードとなります（WebP demux ライブラリと Blink 側の WebP 画像デコーダを含む）。WebP と WebM がより共通のデコードコードを共有するか、WebP の機能が WebM に組み込まれている場合、この問題は今後軽減される可能性があります。

単純に <img> で WebM をサポートしてはどうでしょうか？

長期的には、<img> タグ内で動画形式をサポートすることが合理的です。ただし、これを行うと、<img> の WebM がアニメーション WebP の提案された役割を果たすため、問題が発生します。

前のフレームに依存するフレームをデコードするとき、WebM はアニメーション WebP よりも 50% 多くのメモリを必要とします。それによって前フレームの最小数を保持します³。
動画コーデックとコンテナのサポートは、ブラウザやデバイスによって大きく異なります。コンテンツの自動コード変換を容易にするには（帯域幅を節約するプロキシなど）、ブラウザでは画像タグがサポートする形式を示す allow ヘッダーを追加する必要があります。「video/webm」や「video/mpeg」などの MIME タイプは依然としてコーデックのサポートを示していないため（VP8 と VP9 など）、これだけでは不十分である可能性もあります。一方、WebP 形式は実質的に凍結されているため、リリースするベンダーがアニメーション WebP の提供に同意していれば、すべての UA で WebP の動作は一貫している必要があります。また、「image/webp」Accept ヘッダーがすでに WebP のサポートを示すために使用されているため、新しい Accept ヘッダーを変更する必要はありません。
Chromium 動画スタックはスムーズな再生に最適化されており、同時に再生される動画が 1 つか 2 つしかないことを前提としています。そのため、この実装では、再生品質を最大限に高めるためにシステムリソース（スレッド、メモリなど）を積極的に消費します。このような実装は、多くの同時動画にうまく対応できないため、画像の多いウェブページでの使用に適しているように再設計する必要があります。
WebM には現在、WebP のすべての圧縮手法が組み込まれているわけではありません。その結果、この画像は他の画像よりも WebP の方が圧縮率が著しく優れています。

¹ アニメーション GIF とアニメーション WebP のすべての比較に、ウェブからランダムに取得した約 7, 000 のアニメーション GIF 画像のコーパスを使用しました。これらの画像は、gif2webp ツールを使用してデフォルトの設定（2013 年 10 月 8 日時点の最新の libwebp ソースツリーからビルド）を使用してアニメーション WebP に変換されました。比較数値は、これらの画像の平均値です。

² デコード時間は、ベンチマークツールを使用し、2013 年 10 月 8 日時点の最新の libwebp と ToT Blink を使用して計算されています。「シーク後のデコード時間」は、「最初の 5 フレームのデコード、フレームバッファキャッシュのクリア、次の 5 フレームのデコードなど」として計算されます。

³ 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 以降が必要です