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

よくある質問

WebP とはメリット

WebP は、非可逆圧縮および可逆圧縮の手法で、ウェブ上のさまざまな写真、半透明画像、グラフィカル画像に使用できます。ロッシー圧縮の程度は調整可能です。これにより、ファイルサイズと画質のトレードオフを選択できます。WebP では、通常、画質を損なうことなく、JPEG と JPEG 2, 000 より 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（PC と 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 は、ウェブブラウザの HTML5 と CSS3 の機能のサポートを簡単に検出するための JavaScript ライブラリです。Modernizr.webp、Modernizr.webp.lossless、Modernizr.webp.alpha、Modernizr.webp.animation プロパティを探します。

HTML5 `<picture>` 要素

HTML5 では <picture> 要素がサポートされています。これにより、複数の代替画像ターゲットを優先度の高い順に一覧表示して、適切に表示される最初の候補画像をクライアントがリクエストできるようになります。HTML5 Rocks のディスカッションをご覧ください。<picture> 要素は、常により多くのブラウザでサポートされています。

独自の JavaScript の場合

もう 1 つの検出方法は、特定の機能を使用する非常に小さな 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 を使用すると、誰でもこの形式を使用して改善を提案できます。Google は、皆様からのご意見や提案を参考にして、時間の経過とともにグラフィックフォーマットとして 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 画像の最大ピクセルサイズは 16,383 x 16,383 です。

WebP 形式はどの色空間をサポートしていますか。

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

Lossless WebP は RGBA 形式専用です。WebP 非可逆ビットストリームの仕様をご覧ください。

WebP の画像は元の画像よりも大きくすることができますか？

はい。通常、ロッシー形式から WebP ロスレス形式に変換するか、その逆を行います。これは主に、色空間の違い（YUV420 と ARGB）と、それらの間の変換によるものです。

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

ソース画像がロスレス ARGB 形式の場合、YUV420 への空間的ダウンサンプリングにより、元の色よりも圧縮が困難な新しい色が導入されます。このような状況は、ソースが PNG 形式で色がほとんどない場合に発生することがあります。非可逆 WebP に変換する（または非可逆 JPEG に変換する）と、ファイルサイズが大きくなる可能性があります。
ソースが非可逆圧縮モードの場合は、可逆圧縮 WebP 圧縮を使用してソースの非可逆性を捕捉すると、通常、ファイルサイズが増大します。これは WebP に限ったことではなく、JPEG ソースを可逆形式の WebP 形式や PNG 形式に変換する場合などに発生することがあります。
ソースが非可逆形式で、高品質の設定を持つ非可逆 WebP として圧縮しようとしている。たとえば、品質 80 で保存されている JPEG ファイルを品質 95 の WebP ファイルに変換しようとすると、通常は非可逆圧縮の場合でもサイズが大きくなります。多くの場合、ソースの品質を評価できないため、ファイルサイズが一貫して大きい場合は、ターゲットの WebP の品質を下げることをおすすめします。別の方法として、品質設定を使用せず、cwebp ツールの -size オプションまたは同等の API を使用して、特定のファイルサイズをターゲットにすることもできます。たとえば、元のファイルサイズの 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 を使用する理由

アニメーション WebP とアニメーション GIF の利点

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

アニメーション GIF とアニメーション GIF のデメリット

シークがない場合、WebP の直線デコードは GIF よりも CPU 使用率が高くなります。非可逆 WebP では GIF のデコード時間が 2.2 倍、可逆圧縮の WebP では 1.5 倍の時間がかかります。
WebP のサポートは、GIF サポートほど広くはないため、実質的に普遍的です。
WebP サポートをブラウザに追加すると、コードのフットプリントと攻撃対象領域が増加します。Blink では、約 1,500 行のコードが追加されます（WebP demux ライブラリと Blink サイド WebP 画像デコーダを含む）。なお、WebP と WebM がより一般的なデコードコードを共有する場合や、WebP の機能が WebM の機能を利用される場合には、この問題が今後減少する可能性があります。

<img> で WebM をサポートするのはなぜでしょうか？

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

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

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

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

³ WebM は 4 つの YUV 参照フレームをメモリに保持し、各フレームは（幅 + 96）*（高さ + 96）ピクセルを保存します。YUV 4:2:0 では、6 ピクセルあたり 4 バイト（または 1 ピクセルあたり 3/2 バイト）が必要です。したがって、これらの参照フレームは 4*3/2*(width+96)*(height+96) バイトのメモリを使用します。一方、WebP は、利用可能な前のフレーム（RGBA 単位）（4*width*height バイトのメモリ）のみを必要とします。

⁴ WebP アニメーションのレンダリングには Google Chrome バージョン 32 以降が必要です。