このページは 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）
- Pale Moon 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

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 画像の最大ピクセルサイズは 16,383 x 16,383 です。

WebP 形式はどのカラースペースをサポートしていますか？

VP8 ビットストリームと同様に、非可逆 WebP は 8 ビット Y'CbCr 4:2:0（YUV420 とも呼ばれます）画像形式でのみ動作します。詳しくは、RFC 6386 のセクション 2「形式の概要」と VP8 データ形式とデコードガイドをご覧ください。

ロスレス WebP は RGBA 形式でのみ機能します。WebP ロスレスビットストリームの仕様をご覧ください。

ロスレス WebP ファイルが元のファイルと異なるのはなぜですか？

Simple Encoding API 関数（WebPEncodeLosslessRGB()、WebPEncodeLosslessBGR()、WebPEncodeLosslessRGBA()、WebPEncodeLosslessBGRA()）は、ライブラリのデフォルト設定を使用します。ロスレスの場合、これは「exact」が無効になっていることを意味します。完全に透明な領域（アルファ値が 0 に等しい領域）の RGB 値は、圧縮を改善するために変更されます。これを回避するには、WebPEncode() を使用し、WebPConfig::exact を 1 に設定します。高度なエンコード API のドキュメントをご覧ください。

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、再描画の労力を節約しながら、ダウンロードステータスに関する視覚的な手がかりを提供できます。増分デコード機能は、高度なデコード API を通じて利用できます。

Android プロジェクトで libwebp Java バインディングを使用するにはどうすればよいですか？

WebP には、swig/ ディレクトリのシンプルなエンコーダインターフェースとデコーダインターフェースへの JNI バインディングのサポートが含まれています。

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

NDK ツールとともに ADT プラグインがインストールされ、NDK パスが正しく設定されている（[Preferences] > [Android] > [NDK]）ことを確認します。
新しいプロジェクトを作成します: [File] > [New] > [Project] > [Android Application Project]。
クローンを作成するか、libwebp を新しいプロジェクトの jni という名前のフォルダに解凍します。
LOCAL_SRC_FILES リストに swig/libwebp_java_wrap.c を追加します。
新しいプロジェクトを右クリックし、[Android Tools] > [Add Native Support ...] を選択して、ビルドにライブラリを含めます。
プロジェクトのプロパティを開き、[C/C++ Build] > [Behaviour] に移動します。Build (Incremental build) セクションに ENABLE_SHARED=1 を追加して、libwebp を共有ライブラリとしてビルドします。

注 NDK_TOOLCHAIN_VERSION=4.8 を設定すると、一般に 32 ビットビルドのパフォーマンスが向上します。
libs/ プロジェクトフォルダに swig/libwebp.jar を追加します。
プロジェクトをビルドします。これにより、libs/<target-arch>/libwebp.so が作成されます。
System.loadLibrary("webp") を使用して、実行時にライブラリを読み込みます。

ライブラリは、ndk-build と含まれている Android.mk を使用して手動でビルドできます。上記の手順の一部は、その場合にも再利用できます。

C# で libwebp を使用するにはどうすればよいですか？

WebP は、libwebp API をエクスポートする DLL としてビルドできます。これらの関数は C# でインポートできます。

libwebp.dll をビルドします。これにより、API 関数をエクスポートするように WEBP_EXTERN が適切に設定されます。
```
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 は 8 ビットのアルファチャンネルを持つ 24 ビットの RGB カラーをサポートしていますが、GIF は 1 ビットのアルファを持つ 8 ビットのカラーをサポートしています。
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 と比較したアニメーション WebP のデメリット

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

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

長期的には、<img> タグ内の動画形式をサポートすることが理にかなっている可能性があります。ただし、<img> の WebM がアニメーション WebP の提案された役割を果たすことを意図して、今すぐそうすることは問題があります。

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

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

² デコード時間は、2013 年 10 月 8 日時点の最新の libwebp + ToT Blink を使用して、ベンチマークツールで計算されました。「シークありのデコード時間」は、「最初の 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 以降が必要です。

よくある質問 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。