ホームページの画像を軽くする方法：WebP・AVIFの使い分けと書き出しの手順

ホームページの表示が遅いと感じたとき、最初に見直したいのが画像です。スマートフォンで撮った写真やデザイナーから受け取った画像をそのままの大きさで載せていると、表示される大きさに対してファイルが大きすぎることがあります。画像を軽くする作業は、専門的なプログラムの知識がなくても社内で進められる部分が多い改善です。

この記事は、自社のホームページの更新を担当する総務・広報の方に向けて、画像を軽くする方法をまとめたものです。画像の形式（JPEG・PNG・WebP・AVIF）の使い分け、書き出す幅の決め方と圧縮の手順、WordPress での扱い、遅延読み込み、alt 属性まで、Google の公式情報（web.dev・Google 検索セントラル）と MDN、WordPress の公式情報で確認した内容をもとに説明します（2026年11月時点）。

結論を先に書くと、画像を軽くする基本は「表示する大きさに合わせて縮小する」「写真は WebP などの圧縮の効率がよい形式で書き出す」「画面の下のほうの画像だけを遅延読み込みにする」の3つです。この3つから始めて、表示速度の数字で効果を確かめながら進めます。

画像が重いと表示速度に何が起きるか

Google 検索セントラルの画像のベストプラクティスでは、画像はページの容量の中で大きな割合を占めることが多く、ページの表示を遅くする原因になると説明されています。同じページでは、画像の最適化とレスポンシブ画像の手法を使うこと、表示速度の分析に PageSpeed Insights を使うことが勧められています。

表示速度の指標のうち、画像と関わりが深いのが LCP（Largest Contentful Paint）です。LCP は、ページを開いてから画面内でいちばん大きな画像や文章のかたまりが表示されるまでの時間です。web.dev の LCP の解説では、ページの読み込みの75パーセンタイルで2.5秒以内を「良好」の目安としています。LCP の対象には img 要素の画像のほか、CSS の url() で読み込む背景画像も含まれます。トップページの大きなメイン画像は、LCP の対象になりやすい要素です。

ただし、画像を軽くするだけで LCP が必ず良くなるわけではありません。web.dev の記事「Common misconceptions about how to optimize LCP」では、多くのページで LCP の要素は画像であるとしたうえで、Chrome の実際の利用データでは、画像のダウンロードそのものより、ダウンロードが始まるまでの待ち時間のほうが長い傾向が示されています。同じ記事は、送るデータ量を減らすことはほぼ常に良い結果につながるとしつつ、読み込みの順番の見直しとあわせて進めるよう勧めています。この記事でも、ファイルを軽くする方法と、読み込みの順番（遅延読み込みと優先度）の両方を説明します。

LCP・INP・CLS の3つの指標の基準と、画像以外も含めた改善の進め方はWebサイトの表示速度の基準は？Core Web Vitalsの目安と改善方法で説明しています。ここからは画像に絞って進めます。

画像の形式の使い分け（JPEG・PNG・WebP・AVIF・SVG）

画像の形式は、写真か、ロゴや図か、透過が必要かで選びます。web.dev の「Choose the right image format」と、MDN の「Image file type and format guide」の内容をもとに、ホームページでよく使う形式を表にまとめました。

MDN は、写真などの画像には WebP か AVIF を優先し、JPEG や PNG をその代替（フォールバック）として使う考え方を示しています。同じページでは、可逆の WebP は同じ画像の PNG より26%ほど小さいとも説明されています。web.dev も、使える場面では WebP や AVIF を使い、JPEG や PNG を代替にするよう勧めています。実際にどれだけ小さくなるかは画像によって変わるため、書き出したあとにファイルサイズを比べて確かめます。

ブラウザの対応について、MDN では AVIF は Chrome 85、Edge 121、Firefox 93、Safari 16.1 以降で使えると記載されています。Google 検索は、img 要素の src 属性で指定された BMP・GIF・JPEG・PNG・WebP・SVG・AVIF の画像に対応しています（Google 検索セントラルの画像のベストプラクティス）。

形式を選ぶ前に、そもそも画像にしなくてよいものがないかも確かめます。web.dev は、文字は画像の中に入れず、Web フォントで表示するよう勧めています。文字を画像にすると、選択・検索・拡大がしにくくなるためです。動きのある画像は、GIF ではなく動画（video 要素）で載せるよう勧めています。

書き出す幅の決め方：表示幅と画面の密度

画像を軽くするうえで効果が大きいのは、表示する大きさに合わせて画像を縮小することです。web.dev の「Image performance」では、幅500ピクセルの枠に1,000ピクセルの画像を表示すると、必要な大きさの2倍になると説明されています。一方で、スマートフォンなど画面の密度が高い端末（デバイスピクセル比が2の端末）では、500ピクセルの枠をきれいに表示するには1,000ピクセルの画像が必要です。

このため、書き出す幅は「ページ上で表示される幅×2」を上限の目安にすると決めやすくなります。デバイスピクセル比が3の端末もありますが、web.dev は、多くの場合は人の目で3倍の細かさの違いを見分けられないとしています。表示される幅は、パソコンとスマートフォンでページを開き、ブラウザの開発者ツールで画像の表示サイズを見ると確かめられます。

計算の例の数値は、考え方を示すためのものです。実際の幅はテーマやデザインによって違うため、自社のページで表示幅を確かめてから決めてください。社内で「本文の画像は幅〇〇pxで書き出す」のように場所ごとの幅を一覧にしておくと、担当者が変わっても同じ大きさで載せられます。

画面の幅によって表示幅が大きく変わる画像は、srcset 属性と sizes 属性で複数の大きさを用意し、ブラウザに選ばせます（レスポンシブ画像）。Google 検索セントラルは、srcset や picture 要素を使う場合も、src 属性で代わりの画像の URL を必ず指定するよう勧めています。スマートフォンでの表示の考え方はスマホサイトの最適なサイズは？レスポンシブデザインの作り方とPCとの違いで説明しています。

書き出しと圧縮の手順

次の手順で画像を書き出すと、作業する人が変わっても同じ画質と軽さを保ちやすくなります。画像編集ソフトでも、ブラウザで使える変換ツールでも、流れは同じです。

1. 元の画像を保管する：撮影したままの画像やデザインのデータを、社内で決めた場所に保管します。書き出した画像で元の画像を上書きしないようにします。
2. トリミングする：必要な部分だけを切り出し、縦横の比率をページの枠に合わせます。人物や商品の端が切れていないかを確かめます。
3. 縮小する：前の章で決めた書き出し幅に縮小します。表示幅の2倍を超えていないかを確かめます。
4. 形式を選ぶ：写真は WebP（または AVIF・JPEG）、図やスクリーンショットは PNG か可逆の WebP、ロゴは SVG にします。透過が必要かどうかも確かめます。
5. 画質を調整する：画質（品質）の数値を何段階か変えて書き出し、見た目とファイルサイズを比べます。文字や輪郭ににじみが出ていないかを見ます。
6. ファイル名を付ける：内容が分かる短い英数字の名前にします（例：factory-laser-cutting.webp）。IMG_0001 のような名前のまま載せないようにします。
7. 載せて確かめる：ページに載せ、パソコンとスマートフォンで表示を確認します。ぼやけていないか、ファイルサイズが想定どおりかを見ます。

画質の設定に、すべての画像に当てはまる正解はありません。web.dev も、非可逆圧縮の画像は品質の基準を満たしているかを必ず確認し、画質の段階を試して品質とファイルサイズの釣り合いを取るよう勧めています。社内で「写真は画質〇〇で書き出す」のように基準を決め、気になる画像だけ個別に調整すると、作業が続けやすくなります。

変換に使うツールの一つに、Google Chrome Labs が公開している Squoosh があります。ブラウザ上で形式の変換と圧縮ができ、画質を変えたときの見た目を並べて比べられます。公開元のGitHub の説明では、画像をサーバーに送らず、手元で処理すると書かれています。社外のサービスで画像を変換する場合は、社内のルールで使ってよいかを先に確かめます。写真そのものの撮り方や素材写真の使い方はホームページの写真撮影と素材写真の使い方を参考にしてください。

WordPress で画像を扱うときの仕組み

WordPress には、画像を軽く表示するための機能がいくつか標準で入っています。主なものを、WordPress 公式の開発者向けの情報で確認できた範囲で表にまとめます（2026年11月時点）。

出典は、Responsive Images（WordPress 開発者向け資料）、5.3 の大きな画像の扱い、5.5 の遅延読み込み、5.8 の WebP 対応、6.3 の画像の表示速度の改善、6.5 の AVIF 対応の各公式記事です。

WebP の対応を告知した5.8の公式記事では、アップロードした画像と同じ形式で小さいサイズの画像を作るのが標準の動きと説明されており、JPEG を自動で WebP に変換するわけではありません。JPEG の写真を WebP で表示したい場合は、書き出しの段階で WebP にするか、変換の機能を持つプラグインやサーバーの機能を使います。プラグインを使う場合は、更新が続いているか、テーマやほかのプラグインとぶつからないかを確かめます。

AVIF は6.5以降でアップロードできますが、使えるかどうかはサーバーの画像処理（Imagick または GD）が AVIF に対応しているかで決まります。管理画面の「ツール」から「サイトヘルス」を開き、「情報」タブの「メディア処理」（Media Handling）の項目で、対応している形式を確かめられます。

これらの機能は、WordPress 本体を更新していることが前提です。古いバージョンのまま止まっているサイトでは使えません。更新が止まっている場合のリスクと手順はWordPressを更新しないとどうなる？で説明しています。

遅延読み込み（loading=”lazy”）の使い方と注意

遅延読み込みは、画面の外にある画像の読み込みを後回しにする仕組みです。MDN の img 要素の解説によると、img 要素に loading=”lazy” を付けると、ブラウザは画像が画面から一定の距離に近づくまで読み込みを待ちます。指定しない場合（eager）は、位置に関係なくすぐに読み込みます。

注意したいのは、ページを開いたときに最初に見える範囲（ファーストビュー）の画像です。web.dev の遅延読み込みの解説は、loading=”lazy” は最初の表示範囲の外にある画像だけに使い、特に LCP の画像には使わないよう勧めています。反対に、LCP になる画像には fetchpriority=”high” を付けて優先して読み込ませる方法が、前に挙げた web.dev の LCP の記事で紹介されています。

• ファーストビューのメイン画像：loading=”lazy” を付けない。fetchpriority=”high” を検討する
• ヘッダーのロゴ：loading=”lazy” を付けない
• スクロールした先の写真・バナー：loading=”lazy” を付ける
• すべての画像：width 属性と height 属性で幅と高さを指定する

幅と高さの指定について、MDN は、width と height があるとブラウザは画像が届く前に縦横比を計算して場所を確保できるため、読み込み中のレイアウトのずれ（CLS）を抑えられると説明しています。遅延読み込みの画像では特に大切だとしています。

検索への影響について、Google 検索セントラルの遅延読み込みの解説は、ブラウザ標準の遅延読み込みを推奨する方法の一つに挙げています。一方で、スクロールやクリックなどの操作をしないと読み込まれない作り方は避けるよう説明しています。Google 検索はページを操作しないためです。画像が読み込まれているかは、Search Console の URL 検査ツールで確かめられます。また、Google 検索セントラルの画像のベストプラクティスでは、Google は CSS で指定した画像をインデックスしないとしているため、検索で見つけてほしい画像は img 要素で載せます。

alt 属性とファイル名の付け方

alt 属性は、画像の内容を文字で表したものです。Google 検索セントラルの画像のベストプラクティスでは、画像のメタデータの中で alt 属性がもっとも重要だとし、スクリーンリーダーを使う人や回線が遅い人にも役立つと説明しています。キーワードを詰め込むのは避け、内容に合った説明を書くよう勧めています。

• よくない例：alt 属性がない。「画像」「写真1」のように中身が分からない。「金属加工 精密加工 板金 溶接 加工会社」のようにキーワードを並べる
• よい例：「工場内のレーザー加工機で鋼板を切断している様子」のように、画像に写っている内容を一文で書く
• 飾りの画像：区切り線や背景の模様など、内容に関係しない画像は alt=”” と空にする

飾りの画像について、MDN は、alt を空にすると、その画像が内容の重要な一部ではないことを示せると説明しています。ファイル名について、Google 検索セントラルは IMG00023.JPG のような名前より、内容を表す短い名前のほうがよいとし、image1.jpg のような汎用的な名前は避けるよう勧めています。日本語などの文字をファイル名に使う場合は URL のエンコードの決まりに従うよう案内されているため、英数字とハイフンで付けておくと扱いやすくなります。alt 属性の書き方と確認方法はalt属性が不要なパターンは？SEO効果と書き方・確認方法で詳しく説明しています。

軽くなったかを確かめる方法

画像を直したら、直す前と後で数字を比べます。Google 検索セントラルが表示速度の分析に勧めている PageSpeed Insights でページの URL を調べ、LCP などの値を記録しておきます。Chrome の開発者ツールや Lighthouse には「Improve image delivery」という分析があり、表示サイズより大きな画像、WebP や AVIF にすると小さくなる画像、圧縮の余地がある画像を指摘します。Chrome の解説では、削減できる量が4KiB未満の画像は指摘されないと説明されています。

• PageSpeed Insights で、直す前と後の LCP の値を比べる
• 画像の配信についての指摘（表示サイズより大きい、形式、圧縮）が残っていないかを見る
• ファーストビューの画像に loading=”lazy” が付いていないかを、ページのソースで確かめる
• スマートフォンとパソコンで、画像がぼやけていないかを目で見る
• Search Console の URL 検査で、画像が読み込まれているかを確かめる

無料で使える公式のツールでのチェックの進め方はホームページを無料で診断する方法にまとめています。

画像の差し替えや軽量化を社内で続けるのが難しい場合は、外部に任せる方法もあります。フェニックスデザインのWEBサイト運用保守では、保守スタンダード（月30,000円〜・税別）の軽微な修正・更新作業（月2時間）に画像の差し替えが含まれ、表示速度を含む稼働レポートもお送りします。まず今の状態を知りたい場合は、URL を入れるだけで表示速度などを100点満点で採点する無料簡易診断（0円）も使えます。

よくあるご質問

WebP にすると、古いブラウザで画像が表示されなくなりますか？

MDN では、WebP は主要なブラウザの最新版で広く使えるとしたうえで、picture 要素などで JPEG や PNG の代替を用意する方法を紹介しています。AVIF はさらに代替を用意するよう勧めています。自社のサイトの閲覧者が使っているブラウザは、GA4 などのアクセス解析で確かめられます。

画像のファイルサイズは何KB以下にすればよいですか？

この記事で確認した Google と MDN の公式情報には、すべてのサイトに当てはまるファイルサイズの上限は書かれていません。表示幅に合わせて縮小し、画質を何段階か試したうえで、PageSpeed Insights や Chrome の分析で指摘が出ないかを確かめる進め方が確実です。社内で場所ごとの目安を決めておくと、判断がそろいます。

画像を軽くすると検索順位は上がりますか？

Google 検索セントラルのCore Web Vitals の解説では、検索での成果のために Core Web Vitals の良好な値を達成することを強く勧めています。ただし、画像を軽くしたことだけで順位が上がるとは限りません。表示が速くなることで、閲覧者がページを読みやすくなることを主な目的として進めます。

すでに載せている画像も軽くできますか？

できます。元の画像から書き出し直して差し替えるのが確実です。WordPress では、メディアライブラリの画像を差し替えたあと、その画像を使っているページで新しい画像が表示されているかを確かめます。まとめて変換するプラグインを使う場合は、事前にバックアップを取ってから進めます。

まとめ

• 画像はページの容量の大きな部分を占めやすく、LCP の対象にもなりやすい要素です。
• 写真は WebP や AVIF、図やスクリーンショットは PNG か可逆の WebP、ロゴは SVG を基本に、JPEG と PNG を代替として使います。
• 書き出す幅は「表示幅×2」を上限の目安にし、自社のページで表示幅を確かめてから決めます。
• 遅延読み込みは画面の外の画像だけに使い、ファーストビューのメイン画像には付けません。すべての画像に幅と高さを指定します。
• alt 属性には画像の内容を一文で書き、直したあとは PageSpeed Insights などで前後の数字を比べます。