画像がウェブサイトを遅くする理由と、効果的な高速化の解決策

最終更新日: June 28, 2026

私が監査したほとんどの低速なサイトで共通していた原因は、画像でした。テキスト、フォント、JavaScriptも重要ですが、メディアは典型的なコンテンツページやeコマースページにおいて支配的な重さとなり、チームが最後に最適化する部分です。この記事では、画像をロード速度にどのように影響するかという点に焦点を絞り、私が実環境で測定した修正方法について解説します。より広い全体像については、website speed optimizationガイドでコード、フォント、キャッシングについても取り上げています。

クイックアンサー：画像はどのようにサイトを遅くするのか？

画像は通常、ページ全体の重さの60〜80%を占め、画像が豊富なページでは、ロード時間における単一最大の要因となります。最も効果的に改善できる4つの修正点は、以下の通りです。表示サイズでの最新フォーマットの提供、適切な品質への圧縮、ビューポート外のメディアの遅延読み込み（lazy-loading）、そしてアセットをCDNの背後に配置することです。

私が測定したクライアントのブログでは、これら4つの変更により、ページ全体の重さが3.4 MBから690 KBに、Largest Contentful Paintが4.8秒から1.9秒に改善しました。まず最大の画像から着手し、改善前と改善後の計測を行ってください。

画像はなぜサイトを遅くするのか？

すべての画像は、ネットワークリクエストに加え、ブラウザがダウンロード、デコード、描画しなければならないバイト数を含みます。典型的なページでは、そのバイト数が他のすべてを圧倒します。同じクライアントサイトの重さをカテゴリ別に分解しました。

画像は他のすべてのカテゴリを合わせたものよりも大きいため、画像の最適化作業は他のどの変更よりも早く効果が戻ってきます。同じバイト数はデコード時間も消費します。4 MBの写真は、ダウンロードが完了した後でも、ブラウザがそれを非圧縮する間、メインスレッドをブロックしてしまうのです。

私が最も頻繁に目にする順序で、遅延の原因となる3つのメカニズムがあります。

• 過剰なバイト数 — 4000ピクセルの写真を400ピクセルの枠に入れる場合など。
• 誤ったフォーマット — WebPではなく、写真に対してフルカラーのPNGを使用する場合。
• 最適化されていない配信方法 — CDNがない、キャッシングがない、レスポンシブなバリアントがない。

最初の2つは「何を送信するか」に関することです。3つ目は「どのように送信するか」に関することです。それぞれに明確な修正策があり、以下で解説します。

ページ全体の重さは実際に何秒のコストがかかるのか？

ページ全体の重さはネットワークを通じて秒数に変換されます。大まかですが役立つルールがあります。4G接続の中級程度のスマートフォンは、理論上のピークではなく、実際の世界では毎秒およそ1〜1.5 MBでダウンロードされるということです。したがって、3.4 MBのページをフェッチするだけで約3秒かかります。これはブラウザが何も作業を行う前の時間です。

私は他のすべてを一定に保ち、画像全体の重さだけを変更して、この点をクライアントサイトで直接測定しました。

削減するメガバイトが1MB増えるごとに、一般的なモバイル接続では約1秒の節約になります。これが、CSSやJavaScriptにおけるどんなマイクロ最適化よりも画像全体の重さが重要である理由です。Googleは、ページ全体の重さとロードパフォーマンスの関係をweb.dev fast guideで文書化しており、PageSpeed Insightsでは過剰なサイズの画像をトップの監査失敗要因の一つとして指摘します。

適切なフォーマットとサイズを提供するにはどうすればよいか？

最大の改善点は、JPGやPNGから写真フォーマットを最新のものに変換し、表示サイズに合わせてリサイズすることです。WebPは、同じ知覚品質においてJPGよりも約25〜35%小さいサイズになります。AVIFはさらに進んでいますが、エンコード速度が不安定な場合があります。私は、デコードが速く、2026年現在どこでも機能するため、WebPを標準としています。

1. 表示サイズにリサイズする。 4000ピクセルの写真を400ピクセルの枠に入れるのは、必要とされるサイズの10倍も大きすぎます。コンテンツ画像は、長い辺を1600〜1920ピクセルに制限してください。

2. 品質75〜82でWebPに変換する。 この範囲は、写真の場合、オリジナルとほとんど区別がつかず、最もバイト数を削減できます。これ以上下げると、空やグラデーションにバンディング（色の帯）が現れます。

3. ヒーロー画像のみAVIFバリアントを保持する (サポートしている場合)。なぜなら、AVIFのエンコードは遅く、Largest Contentful Paint要素となる画像でのみ価値があるからです。

ユースケースごとの正確な寸法については、resize image for web guideに数値が記載されています。アーティファクトなしで品質を維持するには、私が使用するWebP設定の手順がcompress images without losing qualityで解説されています。

配信前に圧縮・変換するにはどうすればよいか？

圧縮はブラウザ内ではなく、ビルドプロセスで行うべきです。目標は、最適化されたバリアントを自動的に生成する単一のソース画像を持つことです。

## hero画像をWebP形式で表示サイズに、品質80で変換する例
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

ディレクトリ全体の場合、複数の幅を出力する小さなループを使用します。重要な規律は、生の5 MBの写真をコミットしないことです。

• コンテンツには品質70、製品写真には品質75という最低ラインを設定し、実際の画像で目視調整を行う。
• メタデータ（EXIF、不要なカラープロファイル）を削除する — これらは視覚的なメリットがゼロであるにもかかわらず、数十キロバイトを追加することがあります。
• デバイスごとに巨大な画像を1枚生成するのではなく、ブレークポイントごとにバリアントを生成する。
• CIで自動化し、最適化されていない画像が本番環境に到達しないようにする。

よくある間違いは、アップロード時の圧縮は行うものの、CMSが生成するすべてのサムネイルやレスポンシブなバリアントを忘れることです。パイプラインをオリジナルサイズだけでなく、すべてのサイズに対して実行してください。私がページ全体の重さの最も急激な低下（頻繁にオリジナルから70〜80%）を測定したのがこのステップです。

ビューポート外の画像を遅延読み込みするにはどうすればよいか？

ビューポート外の画像は、最初の描画をブロックすべきではありません。ネイティブの遅延読み込みは、JavaScriptなしで1つの属性によってこれを実現します。

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Product photo in natural light">

人々の認識よりも重要な2つの属性があります。

1. loading="lazy" は、画像がビューポートに近づくまでフェッチを遅延させるため、最初の描画と競合することがありません。
2. width と height は、画像が到着する前にブラウザにボックスを予約させることができ、これによりCumulative Layout Shiftを防ぎます。

ヒーロー画像やLCP画像を遅延読み込みしてはいけません — それはページ上で最も重要な要素の表示を遅らせてしまうからです。私が従うルールは次のとおりです：ビューポート外のすべてを遅延読み込みし、ユーザーが最初に目にする1枚の画像をすぐに読み込む（eager-load）こと。

CDNはどのように画像速度を向上させるのか？

CDNは、訪問者に近いサーバーから画像を提供するため、モバイルや国際的なトラフィックにおける最初の描画を支配するネットワークの往復時間を短縮します。クライアントサイトでは、画像の前段にCDNを追加したことで、オリジン地域外の訪問者にとってLCPがさらに400ミリ秒低下しました。

CDNはまた、オンザフライでの変換機能も提供します：URLで任意の幅やフォーマットをリクエストするだけで、エッジがそれを生成しキャッシュします。これにより、数十種類のバリアントを事前に生成する必要がなくなります。image CDN guideでは、ヘッダーとキャッシュキーについて詳しく解説しています。

フィンガープリント化された画像URLに長い Cache-Control: max-age=31536000, immutable を設定し、再訪問者がそれらを再利用できるようにします。フィンガープリントが変更された場合は、デプロイ時にキャッシュをパージしてください。

レスポンシブ画像はどのように適合するか？

レスポンシブ画像は、現在のビューポートに対してどのバリアントをダウンロードすべきかをブラウザに正確に伝えるため、スマートフォンがデスクトップのヒーロー画像をフェッチすることがなくなります。srcsetとsizes属性は、これを行うためのネイティブで依存性のない方法です。

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hero image of a laptop browser loading a website">

ブラウザは、デバイスのピクセル比率で枠を埋めるのに十分な最小限のバリアントを選択します。640wファイルとなることが多いスマートフォンでは、1920wファイルのわずか4分の1のバイト数になります。LCP画像には fetchpriority="high" を追加し、ブラウザが初期ロード中にそれを優先するようにしてください。

画像の影響を測定するにはどうすればよいか？

測定しないものは改善できません。画像を特定する作業に役立つツールは2つあります。

• PageSpeed Insights — pagespeed.web.devで実行します。実ユーザーからのフィールドデータレポートを行い、過剰なサイズの画像や欠落している次世代フォーマットを直接指摘します。
• Lighthouse — PageSpeed Insightsの背後にあるラボ監査です。ChromeはLighthouse developer guideでその画像チェックについて文書化しています。バイト数を浪費している特定の画像を名前で挙げてくれます。
• Chrome DevTools Network tab — Imgでフィルタリングし、サイズ順にソートして、最も問題のあるものを記録します。これが私が最初に修正すべき1つか2つの画像を見つける方法です。
• WebPageTest — 各画像がいつダウンロードされ、レイアウトをどのようにシフトさせるかを正確に示すウォーターフォールおよびフィルムストリップです。

ラボデータとフィールドデータが矛盾する場合、フィールドデータを信頼してください。Wi-Fi環境の高速なマシンでのクリーンなラボスコアは、4Gを使用する実際のモバイルユーザーがまだ待機している場合、ほとんど意味をなしません。画像はほとんどのページでLargest Contentful Paintを駆動するため、画像の最適化作業もCore Web Vitalsの作業となります — optimizing images for Core Web Vitalsガイドがこの2つを結びつけています。

避けるべきことは何か？

• 完璧なスコアを追い求めること、ユーザーを追うことではない。 ラボで100点でも、フィールドLCPがまだ4秒の場合は価値がありません。
• 過剰圧縮。 品質を下げすぎるとバイト数は節約できますが、製品写真が台無しになります。サンプルではなく、実際の画像でテストしてください。
• モバイルの無視。 ほとんどのトラフィックと最も遅いロードはモバイルからです。開発用ラップトップではなく、4G接続の中級程度のスマートフォン向けに最適化してください。
• 一度きりの最適化。 新しい画像や機能がリリースされるにつれてパフォーマンスは劣化します。すべてのリリース後に再テストを行ってください。
• デバイスごとに巨大な画像を1枚用意すること。 srcsetがない場合、スマートフォンはデスクトップのヒーロー画像をダウンロードしてしまいます。

要点まとめ

画像は、ページ全体の重さにおける最大のシェアであるため、ウェブサイト速度における単一最大の要因です。この4つの修正点 — 表示サイズでの最新フォーマット、圧縮、遅延読み込み、そしてCDN — は華やかではありませんが、私のクライアントサイトを3.4 MBかつ4.8秒のLCPから690 KBおよび1.9秒のLCPに改善させたものです。これらをこの順序で実行し、各ステップを測定し、まず最大の画像を修正してください。

正直な注意点として：上記の正確なバイト数と秒数は、あるクライアントサイトのものであり、あなたのサイトはコンテンツ、トラフィック、CDNによって異なります。PageSpeed Insightsを自身のURLに対して改善前と改善後で実行し、判断基準とするのは整然としたラボスコアではなく、実際のユーザーからのフィールドデータであるべきです。

画像クレジット

• [Modern computer monitor displaying web design work in a creative workspace] — photo by Tranmautritam on Pexels
• [Close-up of a laptop screen showing a search engine page loading] — photo by cottonbro studio on Pexels
• [Developer typing code on a laptop in a focused workspace] — photo by olia danilevich on Pexels