blog

【WordPress高速化⑤】重い画像を一掃|WebP化+遅延読み込みの手順

画像をWebP化し遅延読み込みを正しく設定して、重い画像を一掃する手順を解説します。

WordPressで画像をWebP+遅延読み込みに最適化する完全ガイド

「画像を最適化しろ」とPageSpeed Insightsに言われても、何をどの順番でやればいいのか分からない——そんな声をよく聞きます。WordPressサイトの表示速度を改善するうえで、WebP変換と遅延読み込み(Lazy Load)の組み合わせは最も費用対効果の高い施策の一つです。実際に当社でロゴ画像を71KBから9.7KBまで圧縮した経験も踏まえ、設定手順から見落としやすい落とし穴まで徹底的に解説します。

この記事について

本記事は、自社サイト crystal-method.com(WordPress運用) で実際に表示速度を改善した一次データに基づきます(モバイルLCP 8,144ms→1,700ms を実測。Google Chrome + Puppeteer/モバイル相当スロットル・5回中央値)。
発行:クリスタルメソッド株式会社(代表取締役 河合 継) | 運営会社 | 編集方針

なぜWebP+遅延読み込みが表示速度に直結するのか

Webページの転送量のうち、画像が占める割合は平均50〜60%とされています。この数字を下げることが、LCP(Largest Contentful Paint)やFIDといったCore Web Vitalsの改善に直結します。

WebPと遅延読み込みは、それぞれ別の軸で画像のコストを削減します。

  • WebP変換:同じ視覚品質でJPEGより25〜34%、PNGより最大90%ファイルサイズを削減する
  • 遅延読み込み:初期表示に不要な画像をビューポート外に先送りし、最初のHTTPリクエスト数とデータ転送量を減らす

両者を組み合わせると、「ファイルが軽くなり」かつ「必要になってから取得する」という二段構えになります。結果として初期ページ読み込みに必要なバイト数が大幅に減り、FCP(First Contentful Paint)とLCPが改善します。

元の状態
JPEG/PNG
全画像を一括読み込み
転送量 大 / LCP 遅い

WebP変換後
ファイルサイズ削減
(JPEG比 -25〜34%)
転送量 中

遅延読み込み追加
必要な画像だけ
初期読み込み
初期転送量 最小

最適化完了
LCP改善
Core Web Vitals向上
表示速度 最速

WebP変換の仕組みと対応状況

WebPはGoogleが開発した画像フォーマットで、可逆圧縮・非可逆圧縮の両方に対応し、透過(アルファチャンネル)もサポートします。2025年時点でChrome、Firefox、Safari(macOS 11以降)、Edge、iOS 14以降の主要ブラウザがすべて対応しており、非対応ブラウザへの互換対応が必要なケースはほぼなくなっています。

WordPressでWebP変換を行う方法は大きく2つあります。

方法①:プラグインで自動変換

最も手軽な方法です。アップロード時に自動でWebPに変換し、<picture>タグや.htaccess書き換えで配信します。

プラグイン名 変換タイミング 遅延読み込み 注意点
Imagify アップロード時・一括変換 別途設定 月25MBまで無料
ShortPixel アップロード時・一括変換 別途設定 月100枚まで無料
Smush アップロード時 内蔵あり WebPはPro版のみ
EWWW Image Optimizer アップロード時・一括変換 内蔵あり サーバー処理・無料あり

方法②:サーバーサイドで変換(.htaccessまたはNginx)

Apacheサーバーなら.htaccessに以下を追記することで、WebP対応ブラウザには自動的に.webpファイルを配信できます。事前にWebPファイルを生成しておく必要があります。

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$
  RewriteCond %{REQUEST_FILENAME}\.webp -f
  RewriteRule ^ %{REQUEST_URI}.webp [T=image/webp,E=REQUEST_image_webp:1,L]
</IfModule>
<IfModule mod_headers.c>
  Header append Vary Accept env=REQUEST_image_webp
</IfModule>

Nginxの場合はtry_filesディレクティブで同様の振り分けが可能です。CDNを使用している場合はVary: Acceptヘッダーのキャッシュ設定も必要になるため、サーバー環境に合わせた確認が必要です。

WordPress標準の遅延読み込みと、その限界

WordPress 5.5以降、<img>タグにloading="lazy"属性が自動付与されます。これはブラウザネイティブの遅延読み込みで、JavaScriptが不要という大きな利点があります。

ただし、標準実装にはいくつかの限界があります。

  • CSSのbackground-imageには効かないloading="lazy"はHTMLの<img>要素のみに適用される。CSSで指定した背景画像は対象外。
  • IframeやVideoには別対応が必要:埋め込み動画なども遅延させたい場合はJavaScriptベースのライブラリが必要。
  • LCPヒーロー画像に誤適用されるリスク:ファーストビューに表示される画像にloading="lazy"が付くと、LCPが悪化する(後述)。

fetchpriority=”high” との組み合わせ

WordPress 6.3以降では、LCPの対象となるヒーロー画像などにfetchpriority="high"が自動で付与されるようになりました。これはブラウザに「この画像を優先的に取得してほしい」と指示するヒントです。

遅延読み込みとフェッチ優先度は相互補完の関係にあります。ファーストビューの画像にはfetchpriority="high"を設定し、スクロールしないと見えない画像にはloading="lazy"を設定するのが理想です。

実践:ロゴ画像71KBを9.7KBに圧縮した事例

当社サイト(crystal-method.com)のヘッダーロゴは、もともとPNG形式で71KBありました。ページ上部に常時表示される画像なので、一見「軽そう」に見えますが、実はLCPに直接影響する重要なアセットです。

以下の工程で9.7KBまで削減しました。

  1. WebP変換:Squooshでエンコード品質75に設定してWebP変換 → 約15KBに
  2. サイズ見直し:表示サイズを実際のレンダリングサイズ(300px幅)に合わせて再エクスポート → 9.7KBに
  3. srcset・sizeの指定:Retinaディスプレイ向けに600px版も用意しsrcsetで切り替え

圧縮率は約86%。転送量の削減はもちろんですが、LCPスコアの改善が主目的でした。

ロゴに遅延読み込みを設定してはいけない理由

ここで重要な注意点があります。ロゴはファーストビューに表示されるため、loading="lazy"を設定すると初期描画が遅くなり、LCPを悪化させます

ところが、テーマによっては<img>タグに一律でloading="lazy"を付与するものがあります。また、最適化プラグインの設定によっては、すべての画像に遅延読み込みを適用してしまうケースも。ロゴのような最初から見える画像は、必ずloading="eager"または属性なし(デフォルト)にしてください。

ファーストビューの画像(ロゴ)は即時読み込み、スクロール先の画像は遅延読み込みと使い分けることがLCP改善の鍵
ファーストビューの画像(ロゴ)は即時読み込み、スクロール先の画像は遅延読み込みと使い分けることがLCP改善の鍵

見落としやすい落とし穴:display:none の罠

CSSでdisplay:noneを使ってスマートフォン時にロゴを非表示にしている場合でも、HTMLにimgタグが存在する限りブラウザはリクエストを送信します(遅延読み込みを設定していても、ビューポート内にあると判定されれば読み込まれます)。

具体的には次のような状況で問題が起きます。

  • PCとスマホで別々のロゴを用意し、スマホ版をdisplay:noneで隠している → 両方のファイルが読み込まれる
  • スライダーの2枚目以降の画像をdisplay:noneで隠している → imgタグが存在すれば即時読み込みの対象になりうる

解決策は<picture>タグとメディアクエリを組み合わせるか、JavaScriptで動的にimgタグ自体を生成することです。display:noneだけで「読み込みを防いでいる」と思い込むのは危険です。

<!-- 悪い例:display:noneでも両方読み込まれる -->
<img class="logo-desktop" src="logo-desktop.webp" alt="ロゴ">
<img class="logo-mobile" src="logo-mobile.webp" alt="ロゴ">

<!-- 良い例:pictureタグで条件分岐 -->
<picture>
  <source srcset="logo-mobile.webp" media="(max-width: 767px)">
  <img src="logo-desktop.webp" alt="ロゴ" fetchpriority="high">
</picture>

WordPressでの具体的な設定手順

Step 1:サーバーのImageMagick/GD対応を確認する

WebPプラグインを使う前に、サーバーがWebPの処理に対応しているかを確認します。WordPressの管理画面「ツール → サイトヘルス → 情報 → メディア処理」でImageMagickまたはGDのWebPサポートが有効になっているかチェックできます。

Step 2:WebP変換プラグインを導入・設定する

ここでは代表的なEWWW Image Optimizerを例に説明します。

  1. 「プラグイン → 新規追加」からEWWW Image Optimizerをインストール・有効化
  2. 「設定 → EWWW Image Optimizer」を開く
  3. 「WebP変換を有効化」にチェックを入れる
  4. 配信方法(.htaccess書き換えまたはピクチャタグ)を選択。Apache環境なら.htaccessリダイレクト方式が手軽
  5. 「既存画像の一括最適化」でアップロード済み画像を変換する

Step 3:遅延読み込みの設定を確認・最適化する

WordPress標準のloading="lazy"はデフォルトで有効ですが、以下を確認してください。

  1. テーマがヒーロー画像・ロゴにloading="lazy"を付けていないかソースコードで確認(ブラウザのデベロッパーツールで<img要素を検索)
  2. PageSpeed Insightsの「スクリーン外の画像を遅延させてください」の指摘がなくなっているか確認
  3. 「LCPの改善が必要」の指摘が出ている場合、LCP対象画像にloading="lazy"が付いていないかチェック

Step 4:srcsetとsizesを正しく設定する

WordPressはメディアサイズ設定(サムネイル、中サイズ、大サイズ)に基づいて自動的にsrcsetを生成します。しかし、テーマのCSSで実際の表示幅と異なるサイズが指定されていると、ブラウザが適切な画像を選べません。

特に注意すべきは中サイズ(デフォルト300px)の設定です。アイキャッチ画像をブログ一覧で表示する際、実際には400px幅で表示しているのにWordPressが300px版を配信してしまう——というケースは意外と多いです。「設定 → メディア」でサイズ設定を実際のレイアウトに合わせるか、sizes属性を明示的に指定します。

<!-- sizesを明示して適切なファイルサイズを選ばせる -->
<img
  src="thumbnail-400.webp"
  srcset="thumbnail-300.webp 300w, thumbnail-400.webp 400w, thumbnail-800.webp 800w"
  sizes="(max-width: 767px) 100vw, 400px"
  alt="記事サムネイル"
  loading="lazy"
>

Step 5:キャッシュプラグインとの連携を確認する

WP RocketやW3 Total Cacheなどのキャッシュプラグインには、独自の遅延読み込み実装が含まれているものがあります。EWWW Image OptimizerとWP Rocketを同時に使う場合は、どちらか一方の遅延読み込みを無効化して二重適用を防ぎます。

WebP変換と遅延読み込みの組み合わせでページ読み込みが高速化される概念図
WebP変換と遅延読み込みの組み合わせでページ読み込みが高速化される概念図

WebP変換・遅延読み込みの効果測定

施策を実施したら、必ず効果を数値で確認します。以下のツールと指標を使います。

ツール 確認すべき指標 目標値の目安
PageSpeed Insights LCP、FCP、スコア LCP 2.5秒未満(グリーン)
Chrome DevTools Network 画像ファイルサイズ・Content-Type image/webp で配信されているか確認
Google Search Console Core Web Vitals レポート 「良好」判定のURL数の推移
WebPageTest Waterfall(画像のロードタイミング) スクロール外画像がビューポート外で読み込まれているか確認

WebPが正しく配信されているかは、Chrome DevToolsの「Network」タブで画像リソースを選択し、「Response Headers」のContent-Type: image/webpを確認するのが確実です。

よくある質問と回答

Q. 既存の画像を一括でWebPに変換するとオリジナルファイルは消えますか?

EWWW Image Optimizerなど主要プラグインは、元のJPEGやPNGを保持したうえで.webpファイルを別途生成します。WebP非対応の古いブラウザへのフォールバックとして元ファイルを残しておく設計ですが、現在は非対応ブラウザを考慮する必要性がほぼないため、容量削減を優先するなら元ファイルを削除するオプションもあります(削除前にバックアップ必須)。

Q. Cloudflareを使っている場合、WebP変換は不要ですか?

CloudflareのPolishまたはImage Resizingを使うと、CDNエッジでオンザフライにWebP変換が可能です。ただしPolishはPro以上のプランが必要で、ブラウザ対応の自動判定はキャッシュとVaryヘッダーの挙動確認が必要です。プラグインによるオリジンサーバーでの変換と組み合わせる場合は二重変換にならないよう調整します。

Q. WebPはSEOに影響しますか?

Googlebotは問題なくWebPをクロール・インデックスできます。Google画像検索でのインデックスも可能です。ただしalt属性の設定はフォーマットに関係なく必須です。

Q. アニメーションGIFをWebPに変換できますか?

アニメーションWebPとして変換可能ですが、ファイルサイズの削減効果はケースバイケースです。現在はアニメーション表現に<video>タグを使う方が圧縮率・パフォーマンスともに優れているケースが多く、Googleもその方法を推奨しています。

まとめ

WordPressで画像のWebP変換と遅延読み込みを適切に組み合わせることで、ページ転送量を大幅に削減しCore Web Vitalsを改善できます。当社でもロゴ画像を71KBから9.7KBに削減した実績があるように、適切なフォーマット選択と実際の表示サイズへの最適化は効果が高い施策です。

実施時の重要ポイントを整理します。

  • WebP変換はプラグインかサーバー設定で自動化し、既存画像も一括変換する
  • ファーストビューの画像(ロゴ・ヒーローバナー)にはloading="lazy"を設定せず、fetchpriority="high"を検討する
  • display:noneで画像を隠してもリクエストは発生する——<picture>タグで適切に条件分岐する
  • srcsetsizesを正しく設定し、実際の表示サイズに合った画像を配信する
  • 施策後はPageSpeed InsightsとChrome DevToolsで効果を数値で確認する

画像最適化は一度設定すれば継続的に効果が続く施策です。新たにアップロードする画像も自動でWebP変換されるよう仕組みを整えておくことで、サイトの表示速度を長期的に維持できます。

関連記事

AIブログ購読

 
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • Claude Code 公式ドキュメント完全読解ガイド|導入判断から運用まで

    Claude Code 公式ドキュメント完全読解ガイド|導入判断から運用まで

    監修 河合 継(クリスタルメソッド株式会社 代表取締役) AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code ベストプラクティス完全解説|実装現場で使える設計指針2026

    Claude Code ベストプラクティス完全解説|実装現場で使える設計指針2026

    監修 河合 継(クリスタルメソッド株式会社 代表取締役) AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    監修 河合 継(クリスタルメソッド株式会社 代表取締役) AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

View more