WebPを正しく取得する

Habrはすでに「新しい」WebP画像形式のトピックに関する記事でいっぱいです（ 説明 、 JPEG2000との比較、BPGとの比較 、サイトでの接続 、 接続 ）。 残念ながら、「すべてが機能する」ようにWebPをサイトに適切に接続する方法や、PNG / JPEGがどれだけ優れている（少ない）かという疑問は未解決のままです。 この記事では、両方の質問に答えます。

あなたはすでに画像を最適化する方法を知っており、WebPに画像を変換し、ウェブサイトでJPEGとPNGを使用することの違いを理解し、 ExifTool 、 jpegtran 、 mozjpeg 、 JPEGrescan 、 optipng 、 pngcrush 、 pngwolf 、 zopflipngおよびTruePNGツールを 知っていると仮定し 、低温殺菌も区別できます牛乳と画像のポスタリゼーション 。

もしそうなら、私たちはポイントに到達します。

WebPの長所

すべてのソースは、WebPにトランスコードされた場合、画像サイズの大幅な縮小、PNG、JPEGに言及しています。 同時に、品質を維持しながらトランスコーディングを実行する必要があります。 3年間、 Air.rfは、損失のない、わずかな損失の画像の自動最適化を使用してきました（2つのモード）。 これにより、すでに最適化されたPNG（TruePNG、pngwolf、およびzopflipngを実行）およびJPEG（ExifTool、mozjpeg、pngへの変換）と比較して、WebPが勝つときとそうでないときを非常に正確に比較できます。

13,000枚の画像のテストサンプルでは、​​WebP はすでに最適化されたPNGおよびJPEGファイルと比較して31％の増加を示しました（580 MB対837 MB）。 WebPファイルは、すでに最適化されたJPEGおよびPNGの対応ファイルよりも約3分の1小さいサイズです。 ここで、PNGからWebPへの変換はロスレスであり、JPEG変換は最小限の損失（品質100）で実行されることを予約する必要があります。これにより、顧客を粉砕します。

ほとんどの場合、すでに最適化されたJPEG（mozjpeg）に比べてWebPのゲインは10％以下でした。 EXIFデータ（特に、パレット）をJPEGファイルから安全に切り出すことができない例外があり、それらをWebPに転送すると大きな利点が得られました。 したがって、「通常の」シナリオに従ってすぐにJPEGを作成する場合、ほとんどの場合、大きなゲインは期待されません。 PNGファイルは、最適化後であっても、WebPに変換すると比較的良好（30％）の「重量を失います」。

さらに重要なことは、最適化されたすべての画像に関して、わずか10％の場合（はい、13,000個の画像のサンプルは最適化されたすべての画像のわずか10％でした） 残りの90％はゲインがありません （そのうち75％はJPEGファイルです）。 損失のない画像を最適化するための厳しいアプローチが原因である可能性があります。「小さな」品質損失でWebPを微調整すると、「同じ結果」が視覚的に得られますが、サイズは小さくなります。 残念ながら、それぞれの場合で非可逆圧縮がどれほど優れているかを理解するために、13万枚すべての画像を自動的に評価することはできません。 画像自体は規則性を表すものではありません。これらは、何百ものサイトの背景画像とギャラリーです。

参考のために、PNGからWebPへの変換

  cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless -q 100 

JPEGをWebPに変換

  cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -q 100 

優れたイラストは、記事の画像です。 元のPNGは15.6 Kbでした。 最適化およびポスタリゼーション後-12.5 Kb。 それからのロスレスwebp-8 Kb。

WebPの実際の使用

画像をWebPに正しく変換または保存する方法を既に学習している場合（別の記事のトピック）、WebPをサイトに接続するという問題が残ります。この問題は既にここで発生しています （Chromeブラウザーは既に市場の2/3以上を占めているため、ゲームは価値があります ）。 ブラウザ側では、JavaScriptを使用したオプションが可能です（noscriptタグymatuhinを使用）：

  <script async src = "simple-webp.min.js">
 <noscript data-webp>
	 <img src = "example.png" alt = "">
 </ noscript> 

そしてHTML5（画像、 pepelsbeyを使用）：

  <写真>
	 <source srcset = "opera.webp" type = "image / webp">
	 <img src = "opera.jpg" alt = "オスロオペラハウス">
 </ picture> 

2番目のオプションは、一般に、より信頼性が高くなります（ただし、より少ないブラウザーをカバーできます）。

ブラウザーのAcceptヘッダーを読み取り、対応する画像（すべてのWebP画像は.webp拡張子でアナログに保存する必要があります）をそれらをサポートするブラウザーにアップロードする「防弾」サーバーバージョンも可能です（クライアントコードの変更は不要です）。 nginxの最も簡単なオプションは次のようになります。

  map $ http_accept $ x_airee_webp {
	 〜* webp '.webp';
	デフォルト '';
 }
 ...
 try_files $ uri $ x_airee_webp @ 404 

より正確なオプション（VaryおよびCache-Controlの適切なサポート）は、webp-detectプロジェクトのIlya Grigorikによって （すべての主要なWebサーバーに対して） 最新に保たれています。

議論のための考え

WebPを使用した実際の経験を要約すると、特にモバイルブラウザの場合、 これを行うのが理にかなっています（画像を「低品質」でアップロードし、ページの読み込み時間で勝つことができます）。 ただし、最初に「通常の」方法でイメージ最適化スタック全体を構成する必要があります。これにより、すべてのユーザーに大きな利益がもたらされます。 その後、プロジェクトのWebPサポートを文字通り「2回のクリックで」実装できます（nginxの構成+最適化中の変換）。

また、私の意見では、WebPを使用すると、特定の種類の画像（JPEGとPNGの両方が不十分）のポイント最適化で「驚異的」に動作します。 また、これらのタイプの画像に対して自動モードで最適化パラメーターを選択すると、非常にクールになります。

ディスク上のイメージのサイズが2倍になることを考えると、それは取るに足りないと考えます。ファイルのサイズが小さく、すべてのイメージを最適化する場合にのみWebPを作成すると、スペースがさらに少なくなります。 また、PNG画像をWebPに変換することは、PNG最適化（圧縮オプションの列挙を伴う）よりも大幅に（少なくとも1桁）リソースを消費しません。

WebP形式の画像を使用して、あなたの考えと応用経験を見てうれしいです。