「WebPにすると表示速度はどれだけ速くなるのか」「SEOに効くのか」を知りたい方に向けて、Googleが公表しているデータと、当社サイトで測った数字だけを使って答えます。
WebPにすると画像の容量は確かに小さくなります。ただし、表示速度の指標LCPのうち、容量で縮むのは画像をダウンロードする区間だけです。この記事では「どれだけ軽くなるか」と「どれだけ速くなるか」を分けて示し、変換と配信の手順までまとめます。
この記事でわかること
- 容量はどれだけ減るか: Google公式では、同じ画質のJPEGより25〜34%小さくなります。当社のアイキャッチ47枚でも、47枚すべてでWebPのほうが小さくなりました。
- 速度はどれだけ変わるか: LCPが縮むのは画像のダウンロード時間の分だけです。Googleの集計では、LCPが遅いサイトの大半はこの区間にLCP時間の10%も使っていません。
- SEOへの効き方: Googleは「ページエクスペリエンスという単一のシグナルは無い」と説明しており、WebPに変えて順位が上がったという公式データもありません。
- PageSpeed Insightsの変更: 「次世代フォーマットでの画像の配信」の項目は2025年10月に廃止され、いまは「画像配信を改善する」で画像を見ています。
WebPとは?次世代フォーマットの基本と読み方
WebP(ウェッピー)はGoogleが開発した画像形式で、拡張子は「.webp」です。JPEGやPNGより小さく保存できます。
【公式仕様】Googleの公式ページは、WebPをWeb上の画像向けに可逆圧縮と非可逆圧縮の両方を備えた形式として紹介しています。写真に向く非可逆と、図版やロゴに向く可逆のどちらでも保存でき、PNGのような透過と、GIFのようなアニメーションも扱えます(Google for Developers「An image format for the Web」)。
「次世代フォーマット」は、JPEG・PNG・GIFより新しく圧縮率の高い画像形式をまとめた呼び方で、WebPとAVIFがその代表です。PageSpeed Insightsの旧項目「次世代フォーマットでの画像の配信」でも、この2つが挙げられていました(この項目は2025年10月に廃止。後述します)。
ブラウザの対応は96.82%、Web上の画像ではまだ12%
Can I useの集計で、WebPは96.82%の環境で表示でき、Web上の画像に占める割合はまだ12%です。
ブラウザの対応状況をまとめているCan I useの集計(2026年9月19日取得)では、WebPを完全に表示できる環境が96.74%、一部だけ対応している環境が0.08%で、合わせて96.82%です。iPhoneやMacのSafariは16.0以降で完全に対応しています(Can I use「WebP image format」)。
一方、Web上の画像の形式別の割合を調べたHTTP Archiveの年次報告「Web Almanac 2024」では、モバイルのページで使われている画像のうちWebPは12%です。JPEGが32.4%、PNGが28.4%、GIFが16.8%で、AVIFは1.0%でした。2022年から2024年にかけてJPEGは約8ポイント減り、WebPは約3ポイント増えています(HTTP Archive「Web Almanac 2024 Media」)。表示できる環境はそろっていても、配信する側の切り替えはまだ途中です。
WebPはSEOに効果がある?表示速度との関係
WebP化を順位要因とする公式の説明は無く、GoogleはCore Web Vitalsを使いつつ関連性を優先します。
画像を軽くするとLCPが縮む場合があり、LCPはCore Web Vitalsの指標の1つです。公式の説明から言えるのは、WebPは「Core Web Vitalsを通じて間接的に関わる可能性がある」というところまでです。
Googleの公式の立場は「単一のシグナルは無い」
Googleは、ページエクスペリエンスという単一の順位シグナルは無く、関連性の高いページが優先されると説明しています。
【公式仕様】Google検索セントラルのページ エクスペリエンスの解説には、順位との関係について次の3点が書かれています(Google検索セントラル「Understanding page experience in Google Search results」)。
- Core Web Vitalsは、Googleのランキングシステムで使われている
- ページエクスペリエンスという単一のシグナルは無く、コアランキングシステムは複数のシグナルを見ている
- ページの体験が劣っていても、Google検索は最も関連性の高いコンテンツを表示しようとする
(当社の読み方)表示速度は、関連性で並んだページの間で差がつく場面がある要素です。検索意図に答える中身が足りないページを、WebPで補うことはできません。
画像検索ではWebPもAVIFも扱われる
Google検索はimgタグのWebPとAVIFに対応しているため、形式を変えても画像検索の対象から外れません。
【公式仕様】Googleの画像SEOのガイドは、imgタグのsrc属性で指定された画像について、BMP・GIF・JPEG・PNG・WebP・SVG・AVIFに対応すると明記しています(Google検索セントラル「Google画像検索のSEOに関するベスト プラクティス」)。AVIFは2024年8月30日に対応形式へ加わりました(Google検索セントラル ブログ(2024年8月30日))。
画像のalt属性・ファイル名・画像サイトマップなど、形式以外の画像SEOは「画像SEOとは?Google画像検索で上位表示する7つの対策と手順」で解説しています。
WebPで順位が上がったという公式データは無い
WebPに変えて検索順位が上がったことを示すGoogleの公式データは、2026年9月時点で見つかりません。
当社はGoogleの公式ヘルプと検索セントラルのブログを確認しましたが、画像の形式を変えたことと順位の変化を結びつけたデータはありませんでした。X(旧Twitter)の投稿も2026年9月19日にAI検索のGrokで調べましたが、WebP化で順位が上がった、あるいは変わらなかったという数字付きの事後報告は見つかりませんでした。
【自社経験】当社サイトも画像はWebPで配信していますが、最初からWebPで運用しているため、変える前と後を比べたデータは持っていません。この記事で示す当社の数字は、容量の実測と、いまの表示速度の実測です。
WebPにすると表示速度はどれだけ変わるか
容量はGoogle公式で同じ画質のJPEGより25〜34%減ります。LCPが縮むのは画像のダウンロード時間の分だけです。
まず「どれだけ軽くなるか」を、Google公式の数字と当社の変換実測で並べます。
| 比較 | Google公式(同じ画質で比較) | 当社の実測(アイキャッチ47枚の中央値) |
|---|---|---|
| 非可逆WebPとJPEG | WebPが25〜34%小さい | WebPが約52%小さい(0.48倍) |
| 可逆WebPとPNG | WebPが26%小さい | WebPが約23%小さい(0.77倍) |
| AVIFとWebP | 公式ページに比較の数字なし | AVIFがさらに約27%小さい(0.73倍) |
| 透過のある画像 | 可逆WebPは22%増で透過を持てる。非可逆ならPNGの約3分の1 | 測っていない |
| 比べた条件 | 画質の指標SSIMをそろえて比較 | 品質の数値を固定(JPEG 85・WebP 80・AVIF 60)。画質はそろえていない |
Google公式の削減率
非可逆WebPは同じ画質のJPEGより25〜34%、可逆WebPはPNGより26%小さいと、Googleは公表しています。
【公式仕様】Googleの公式ページには、非可逆WebPは同等のSSIM(元画像との見た目の近さを表す指標)でJPEGより25〜34%小さく、可逆WebPはPNGより26%小さいと書かれています。透過については、可逆WebPなら22%の増加で透過を持たせられ、非可逆で透過を使う場合はPNGの約3分の1の容量になるとしています(Google for Developers「An image format for the Web」)。
【公式仕様】この数字の元になった比較研究では、定番の評価用画像(Lenna、Kodakの24枚、Tecnickの100枚)に加えて、Webから集めた約11,000枚の画像で容量を比べています(Google for Developers「WebP Compression Study」)。「同じくらいきれいに見える状態で、平均してこれだけ小さい」という意味の数字です。
当社のアイキャッチ47枚で測った結果
当社のアイキャッチ47枚では、WebPの容量はJPEGの中央値0.48倍で、47枚すべてでWebPが小さくなりました。
【実測】2026年9月19日、当社のアイキャッチの原本(PNG・1200×675〜1680×945)47枚を、画像処理ライブラリのPillowで各形式に変換しました。容量の中央値は、PNGが約1.56MB、JPEG(品質85)が約223KB、WebP(品質80)が約105KB、AVIF(品質60)が約77KB、可逆WebPが約1.21MBです。
1枚ごとの比率の範囲は、JPEGに対するWebPが0.36〜0.54倍、WebPに対するAVIFが0.47〜0.77倍でした。PNGに対する可逆WebPの中央値0.77倍は、公式の「26%小さい」に近い結果です。
この比較は品質の数値を固定しただけで、画質の指標SSIMはそろえていません。(当社の読み方)WebPの「約52%減」が公式の「25〜34%減」より大きく出たのは条件が違うためで、WebPの性能が公式の数字を上回ったという意味ではありません。自社の画像で試すときも、品質の数値だけで比べず、変換後の見た目を並べて確かめてください。
WebPにしても表示速度が変わらないことがある理由
LCPの4区間のうち、容量で縮むのは画像の読み込み時間だけで、遅いサイトの大半は別の区間で時間を使っています。
容量が半分になっても、表示速度が半分になるわけではありません。理由は、LCP(ページの主要な画像や文字が表示されるまでの時間)がいくつかの区間の合計だからです。
LCPは4つの区間に分かれる
LCPは、サーバーの応答、読み込み開始までの遅延、画像の読み込み時間、描画の遅延という4区間の合計です。
【公式仕様】web.devは、LCPを次の4区間に分けて説明しています(web.dev「Optimize Largest Contentful Paint」)。
- TTFB: ページのHTMLの最初の1バイトが届くまでの時間
- 読み込みの遅延: HTMLが届いてから、ブラウザがLCPの画像を読み込み始めるまでの時間
- 読み込み時間: LCPの画像そのものをダウンロードする時間
- 描画の遅延: 画像が届いてから、画面に描かれるまでの時間
WebPで容量を減らして縮むのは、3つ目の「読み込み時間」です。web.devも、読み込み時間を縮める手段として、圧縮を強めることや、AVIFやWebPのようなより適した形式に切り替えることを挙げています。
遅いサイトの大半は、画像のダウンロードに10%も使っていない
Googleの集計では、LCPが「不良」のサイトの大半は、LCP時間の10%未満しか画像のダウンロードに使っていません。
【公式仕様】web.devの記事(2024年8月20日公開)は、Chromeの実ユーザーのデータ(CrUX)でLCPが「不良」と判定されたオリジン(サイト単位)を対象に、区間ごとに各オリジンの75パーセンタイル(p75)の値を取り、その中央値を示しています。TTFBが2,270ミリ秒、読み込みの遅延が1,290ミリ秒、読み込み時間が350ミリ秒、描画の遅延が360ミリ秒でした(web.dev「Common misconceptions about how to optimize LCP」)。
同じ記事は、LCPが不良のオリジンの大半は、p75のLCP時間のうち10%未満しかLCP画像のダウンロードに使っていない、と結論づけています。
(当社の読み方)遅いサイトで時間がかかっているのは、サーバーの応答と、画像を読み込み始めるまでの待ち時間です。WebP化はこの2つの区間には効きません。
当社サイトは実ユーザーの値で合格。そのうえで画像のダウンロードは内訳の約11%
当社サイトは実ユーザー値で合格しており、この記事のLCP画像のダウンロードは内訳の約11%でした。

【実測】当社サイト全体の実ユーザー値(過去28日・デスクトップ)は、LCPが1.2秒、INPが36ミリ秒、CLSが0.01で、「ウェブに関する主な指標の評価」は合格です。FCPは1.2秒、TTFBは0.5秒でした。この記事のページ単体でも、モバイルの実ユーザー値でLCPは1.6秒で、評価は合格です(いずれも2026年9月19日にPageSpeed Insightsで取得)。
【実測】そのうえで、この記事のページのLCP要素(アイキャッチ画像。WebP・約54KB)の内訳を、PageSpeed Insightsの「LCP の内訳」で見ました。画像のダウンロードにあたる読み込み時間は全体の約11%で、約80%は描画の遅延でした。
| 区間 | web.devが示す理想の配分 | LCP不良サイトの中央値 | 当社の記事ページの比率 |
|---|---|---|---|
| TTFB | 約40% | 2,270ミリ秒 | 1%未満 |
| 読み込みの遅延 | 10%未満 | 1,290ミリ秒 | 約8% |
| 読み込み時間(WebPで縮む区間) | 約40% | 350ミリ秒 | 約11% |
| 描画の遅延 | 10%未満 | 360ミリ秒 | 約80% |
出典:理想の配分はweb.dev「Optimize Largest Contentful Paint」、不良サイトの中央値はweb.dev「Common misconceptions about how to optimize LCP」、当社の比率は2026年9月19日のPageSpeed Insights「LCP の内訳」。
(当社の読み方)この記事のアイキャッチは、すでにWebPで約54KBまで軽くなっています。ここからAVIFに変えても、縮むのは約11%の区間の一部だけです。実ユーザー値で合格しているため、この表は「どこに時間を使っているか」を示すもので、遅さの指摘ではありません。
画像を直しても1秒も動かなかった案件
当社が検収したサイトでは、画像を次世代形式にしてもモバイルのLCPが1秒も動かず、原因は日本語Webフォントでした。
【自社経験】2026年9月、当社が検収に入ったBtoB企業のサイトで、画像への幅と高さの指定と次世代フォーマット化を済ませた3日後に再計測したところ、モバイルのLCPは9.5秒のままでした。描画を止めていたのは、日本語Webフォントの同期読み込みです。経緯と切り分けの手順は「ページの読み込み速度とSEO|目安2.5秒と改善しない原因【2026】」で解説しています。
Googleが推奨する次世代フォーマット(WebPとAVIF)
Googleの計測ツールが挙げる形式はWebPとAVIFで、2025年10月からは「画像配信を改善する」の項目で見ています。
「次世代フォーマットでの画像の配信」は2025年10月に廃止された
2025年10月のLighthouse 13で旧項目は廃止され、画像の4項目が「画像配信を改善する」に統合されました。
【公式仕様】Chromeチームは、2025年10月10日に公開したLighthouse 13で、旧来の監査項目をレポートとJSONの両方から削除しました。画像については、形式(次世代フォーマットでの画像の配信)、圧縮、アニメーション、表示サイズを別々に見ていた4つの項目が、1つのインサイトにまとめられています。パフォーマンスのスコアは指標から計算しているため、スコアの計算方法は変わっていません(Chrome for Developers「Lighthouse 13」)。
【実測】当社が2026年9月19日にPageSpeed Insightsで確認した画面でも、項目名は「画像配信を改善する」でした。PageSpeed Insightsの画面の見方そのものは「pagespeed insights(ページスピードインサイト) 改善方法をSEOのプロが解説!」で解説しています。
「画像配信を改善する」が見ている4つ
この項目は、画像の形式、圧縮の強さ、表示サイズとの差、アニメーションGIFの4点で減らせる容量を見積もります。
【公式仕様】Chrome for Developersの解説によると、「画像配信を改善する」は次の4点を見ています(Chrome for Developers「Improve image delivery」)。
- 形式: WebPやAVIFなど、より小さく保存できる形式を使っているか
- 圧縮: 画質に対して圧縮が弱すぎないか
- 表示サイズ: 画面に表示する大きさより大きな画像を配っていないか
- アニメーション: 大きなアニメーションGIFを動画形式に置き換えられないか
【実測】当社のこの記事ページで出た指摘は、メニューのバナー画像1枚だけでした。577×346で表示している画像を700×420で配っていたという表示サイズの指摘で、推定の削減量は12KiBです。形式の指摘ではありません。WebPで配信していても、表示サイズより大きな画像を配れば、この項目で指摘されます。
AVIFはWebPよりさらに軽いが、一斉に変えるのは勧められていない
AVIFは当社の実測でWebPより約27%軽くなりましたが、Googleはサイト全体の画像を一斉に変えることを勧めていません。
| 項目 | WebP | AVIF |
|---|---|---|
| 表示できる環境(Can I use) | 96.82%(Safariは16.0以降) | 95.36%(Safariは16.4以降、Edgeは121以降) |
| Web上の画像に占める割合(2024年) | 12% | 1.0% |
| 1画素あたりのビット数の中央値(Web上の実物) | 1.3 | 1.4 |
| 当社の実測(47枚の中央値) | 基準(品質80) | WebPの0.73倍(品質60) |
| Google検索での扱い | 対応 | 2024年8月30日から対応 |
| WordPressへのアップロード | 5.8以降 | 6.5以降 |
出典:Can I use「WebP」・Can I use「AVIF」・HTTP Archive「Web Almanac 2024 Media」・当社の変換実測(2026年9月19日)。
【公式仕様】GoogleはAVIFへの対応を発表した記事で、サイト全体の画像をやみくもに一斉に変えることは勧めず、自分の用途にどの形式が合うかを時間をかけて評価するよう書いています(Google検索セントラル ブログ(2024年8月30日))。
(当社の読み方)当社の実測ではAVIFのほうが軽く出ましたが、Web上で実際に配信されている画像の1画素あたりのビット数は、WebPが1.3、AVIFが1.4で、差は0.1しかありません。品質の設定しだいで差は縮むため、WebPで配信できているサイトが急いでAVIFへ移す理由は弱いと考えます。AVIFとWebPの選び方は「次世代画像フォーマットの選び方|AVIFとWebPの違いを比較」で比較しています。
WebPへの変換方法(ツールとWordPress自動変換)
1枚ずつならブラウザで使える変換ツール、WordPressならアップロード時に自動で変換するプラグインが手軽です。
1枚ずつ変換する(Squoosh・サルワカ道具箱)
数枚だけなら、ブラウザ上で動く変換ツールを使い、画質を見ながらWebPに書き出すのが手早い方法です。
Google Chrome Labsが公開している「Squoosh」は、変換前と変換後を左右に並べて見比べながら品質を決められます。
- Squooshを開き、変換したい画像をドラッグ&ドロップする
- 右側の設定で形式をWebPにし、品質の数値を動かしながら左右の見た目を比べる
- 容量の表示を確かめてから、ダウンロードする
複数の画像をまとめて変換したいときは、サルワカ道具箱のWebP変換のような一括変換のツールもあります。社外秘の画像を扱う場合は、画像がどこで処理されるかをツールの説明で確かめてから使ってください。
WordPressで自動変換する
WordPress本体はWebPを扱えますが、標準ではJPEGをWebPにしないため、変換はプラグインかコードの追加で行います。
【公式仕様】WordPressは5.8以降でWebPを、6.5以降でAVIFを、JPEGやPNGと同じようにアップロードして使えます。どちらも、サーバー側がその形式に対応していることが条件です(Make WordPress Core「WordPress 5.8 adds WebP support」、Make WordPress Core「WordPress 6.5 adds AVIF support」)。
【公式仕様】WordPressのパフォーマンスチームが公開しているプラグイン「Modern Image Formats」は、新しくアップロードした画像を、サーバーが対応していればAVIFで、対応していなければWebPで生成します。対象は新規のアップロードだけで、既存の画像には再生成が必要です。WordPress 6.9以上が条件です(WordPress.org「Modern Image Formats」)。
【公式仕様】コードで変える方法もあります。WordPress 5.8で追加されたフィルター「image_editor_output_format」を使うと、画像を保存するときの形式の対応づけ(JPEGをWebPで保存する、など)を変えられます(WordPress Developer Resources「image_editor_output_format」)。テーマやプラグインにコードを足す作業になるため、コードを触らない場合はプラグインを使います。
ほかにも、既存の画像をまとめて変換できるプラグインがあります(Converter for Media、EWWW Image Optimizerなど)。機能と料金はプラグインごとに違い、変わることもあるため、導入前に各プラグインの公式ページで確かめてください。
【公式仕様】既存の画像を変換してファイル名や拡張子が変わる場合、Googleはサーバー側でリダイレクトを設定するよう求めています(Google検索セントラル ブログ(2024年8月30日))。(当社の読み方)画像検索に表示されていた画像のURLが切れないようにするためです。
変換は速度対策のどこに効くのか
WebPへの変換は、LCPの4区間のうち画像の「読み込み時間」を縮める対策で、遅延や描画の遅れには効きません。
「webp 変換」でサイトの速度対策を調べている場合は、変換がどの区間に効くのかを先に押さえておくと、施策の順番を間違えません。web.devが区間ごとに挙げている対策を、当社で整理すると次のとおりです(web.dev「Optimize Largest Contentful Paint」)。
- TTFBが長い: サーバーの応答やキャッシュの見直し。WebP化は効かない
- 読み込みの遅延が長い: LCPの画像をブラウザに早く見つけさせる(遅延読み込みを外す、優先度を上げる)。WebP化は効かない
- 読み込み時間が長い: 画像の圧縮、表示サイズに合わせた縮小、WebPやAVIFへの変換。WebP化が効くのはここ
- 描画の遅延が長い: 描画を止めているCSS・JavaScript・Webフォントの見直し。WebP化は効かない
どの区間が長いかは、PageSpeed Insightsの「LCP の内訳」で確認できます。
<picture>タグでWebP・AVIFを出し分ける実装
AVIF、WebP、JPEGの順に並べると、ブラウザは対応している最初の形式を選ぶため、古い環境でも画像が欠けません。
HTMLの<picture>タグの中に、<source>でAVIFとWebPを優先したい順に書き、最後に<img>でJPEGかPNGを書きます。
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="画像の説明" width="1200" height="675">
</picture>サーバー側で出し分ける場合は、ブラウザが送るAcceptヘッダーを見て返す形式を切り替え、レスポンスに「Vary: Accept」を付けます。(当社の読み方)WebPを表示できる環境は96.82%あるので、AVIFを使わないなら「WebP+JPEG」の2段でも足ります。
LCP画像は遅延読み込みにせず fetchpriority=high を付ける
ページで最初に大きく表示される画像は、遅延読み込みを外し、fetchpriority=”high”で先に読み込ませます。
【公式仕様】web.devは、LCPの画像に遅延読み込み(loading=”lazy”)を付けないことと、fetchpriority=”high”で読み込みの優先度を上げることを、読み込みの遅延を縮める方法として挙げています(web.dev「Optimize Largest Contentful Paint」)。WebPにして軽くした画像でも、読み込み始めるのが遅ければLCPは縮みません。
【実測】当社のこの記事ページも、PageSpeed Insightsの「LCP リクエストの検出」で、アイキャッチに「fetchpriority=high」を付けるよう指摘されました。アイキャッチはテーマが出力しているため記事の本文からは直せず、テーマ側の設定で直す対象として記録しています。
WebPのメリット・デメリット
メリットは同じ画質で容量が減ることで、デメリットは表示できない環境が約3%残ることと、ファビコンに使えないことなどです。
メリットは次の2つです。
- 容量が減る: 同じ画質のJPEGより25〜34%小さくなり(Google公式)、通信量とサーバーの負荷が下がります
- 1つの形式で用途をまかなえる: 写真向きの非可逆、図版向きの可逆、透過、アニメーションを1つの形式で扱えます
デメリットは次の3つです。
- 表示できない環境が残る: Can I useの集計で、WebPを表示できない環境が約3%あります。<picture>タグでJPEGを残せば画像は欠けません
- 受け取る側の扱いにくさ: X(旧Twitter)には、保存した画像が開けない、印刷に使えないという投稿があります(次の見出しで扱います)
- ファビコンには使えない: 【公式仕様】Google検索が検索結果に表示するファビコンの対応形式は、BMP・GIF・ICO・PNG・JPEG・PPM・TIFFで、WebPは入っていません(Google検索セントラル「検索結果に表示されるファビコンを定義する」)。サイト全体をWebPに一括変換するプラグインを使うときは、ファビコンが対象に入っていないかを確かめてください
見る人の側には保存や印刷で困ったという投稿がある
X(旧Twitter)には、保存したWebPの画像が開けない、印刷や資料に使いにくいという投稿があります。
2026年9月19日にAI検索のGrokで調べたところ、保存できない、印刷に使えない、編集ソフトで開くと色が変わる、といった個人の投稿がありました。個人の投稿のため件数は数えておらず、どの環境で起きたかも確かめていません。
(当社の読み方)配信する側には容量の利点があり、受け取る側には手間が残ります。資料として配る画像や、ダウンロードしてもらう前提の画像は、JPEGやPNGのまま置くほうが親切です。
WebPと表示速度についてよくある質問
Q. WebPの欠点は何ですか?
A. 当社が一次情報で確かめられた欠点は、Can I useの集計でWebPを表示できない環境が約3%残ること、Google検索のファビコンに使えないことの2つです。これに加えて、X(旧Twitter)には保存や印刷で困ったという閲覧者の投稿があります。表示できない環境には<picture>タグでJPEGを残す出し分けで、ファビコンはPNGやICOのまま置くことで対処できます。
Q. WebPとJPEGのどちらがいいですか?
A. Webページで表示する写真やイラストの容量を減らしたいなら、WebPが候補になります。Google公式では同じ画質でJPEGより25〜34%小さくなり、透過が要る画像も非可逆のWebPならPNGの約3分の1の容量になります。一方、メールに添付する画像、印刷用の画像、ダウンロードして使ってもらう画像は、受け取る側の環境を選ばないJPEGのほうが扱いやすい場合があります。Safariは16.0より前の版ではWebPに完全には対応していないため、古い端末の利用者が多いサイトでは<picture>タグでJPEGを残しておきます。
Q. WebPに変換すると画質は落ちますか?
A. 非可逆のWebPは情報を間引いて保存するため、数値の上では画質が落ちます。ただしGoogle公式の比較は、見た目の近さを表す指標SSIMをそろえた状態で25〜34%小さいという結果です。気をつけたいのは、すでに圧縮されたJPEGをWebPにするなど、非可逆の変換を重ねることです。劣化が積み重なるため、元の高画質な画像から1回で変換してください。
Q. なぜWebサイトの表示が遅いのでしょうか?
A. Googleが示したLCP不良サイトの中央値では、サーバーの応答(TTFB)と、画像を読み込み始めるまでの遅延に時間がかかっていました。画像の容量が原因の中心とは限りません。また、PageSpeed Insightsの点数は回線を絞ったテスト環境の値で、Googleが評価に使うのは実際の利用者の値です。点数が低くても実ユーザー値が合格していることがあります。原因の切り分け方は「ページの読み込み速度とSEO|目安2.5秒と改善しない原因【2026】」で解説しています。
Q. WebPに変換するだけで検索順位は上がりますか?
A. 上がることを示すGoogleの公式データはありません。Googleは、ページエクスペリエンスという単一のシグナルは無く、体験が劣っていても関連性の高いページを表示すると説明しています。Core Web Vitalsの各指標は「良好」「改善が必要」「不良」の3段階で評価されるため、すでに「良好」のページをさらに速くしても、評価の段階は変わりません。
Q. WordPressで自動的にWebPに変換するには?
A. WordPressは標準ではJPEGをWebPに変換しないため、コードを書かない場合はプラグインを使います。パフォーマンスチームの「Modern Image Formats」は、新しくアップロードした画像をAVIFかWebPで生成します。既存の画像は再生成が必要です。変換はサーバーの画像処理ライブラリで行われるため、サーバーがWebPに対応していないと生成されません。導入したら、PageSpeed Insightsの「画像配信を改善する」で形式の指摘が消えたかを確かめてください。
まとめ:まずWebP、次に測る
WebPは容量を確実に減らしますが、表示速度が変わるかは、LCPのどの区間で時間を使っているかで決まります。
- 容量: 同じ画質のJPEGより25〜34%小さくなります(Google公式)。当社のアイキャッチ47枚では、47枚すべてでWebPのほうが小さくなりました。
- 速度: WebPで縮むのはLCPのうち画像の読み込み時間だけです。LCPが不良のサイトの大半は、この区間にLCP時間の10%も使っていません。
- SEO: WebP化で順位が上がったという公式データはありません。Core Web Vitalsは順位に使われますが、関連性が優先されます。
- 確認の順番: 変換したら、PageSpeed Insightsの「LCP の内訳」と「画像配信を改善する」で、どの区間が縮んだかを確かめます。
画像の形式以外も含めた画像SEOの全体像は「画像SEOとは?Google画像検索で上位表示する7つの対策と手順」をご覧ください。
参考情報
- Google for Developers「An image format for the Web」
- Google for Developers「WebP Compression Study」
- Google検索セントラル「Understanding page experience in Google Search results」
- Google検索セントラル「Google画像検索のSEOに関するベスト プラクティス」
- Google検索セントラル「検索結果に表示されるファビコンを定義する」
- Google検索セントラル ブログ(2024年8月30日・AVIF対応)
- web.dev「Common misconceptions about how to optimize LCP」
- web.dev「Optimize Largest Contentful Paint」
- Chrome for Developers「Lighthouse 13」
- Chrome for Developers「Improve image delivery」
- Make WordPress Core「WordPress 5.8 adds WebP support」
- Make WordPress Core「WordPress 6.5 adds AVIF support」
- WordPress.org「Modern Image Formats」
- WordPress Developer Resources「image_editor_output_format」
- Can I use「WebP image format」
- Can I use「AVIF image format」
- HTTP Archive「Web Almanac 2024 Media」

