高速ページのためのモバイル画像最適化ガイド：パフォーマンス向上戦略

最終更新日: July 12, 2026

モバイルの画像最適化は、一つの制約から始まります。それは、スマートフォンが表示できないピクセルをダウンロードしてはいけないということです。ソース画像をリサイズし、レスポンシブなバリアントを提供し、最大のabove-the-fold画像をlazy loadingから外し、CDNを通じてクローリング可能なWebPまたはAVIFファイルを公開する必要があります。

クイックアンサー：モバイルの画像最適化はどのように行うべきか？

この順序を使用してください：まずリサイズ、次にエンコード、その後に配信、最後に測定です。4000 pxの商品写真が390 px幅で表示される場合、圧縮されていても無駄です。ブラウザは、ページが準備完了だと感じる前に、それでもフェッチし、デコードし、スケーリングしなければなりません。

ほとんどのモバイルページでは、幅を400、800、1200 px程度とするWebPまたはAVIFのソースセットを提供してください。オーディエンスに古いブラウザ、メールクライアント、またはパートナーフィードが含まれる場合は、JPEGフォールバックを残しておくと良いでしょう。より深いフォーマットの決定を行うには、AVIF vs WebP comparison を使用してください。

GoogleのLCPガイダンスによると、ページは75パーセンタイルで2.5秒以下でのLargest Contentful Paintを目指すべきです。これはモバイルとデスクトップに分けて考慮する必要があります。画像はしばしばLCP要素となるため、ヒーロー画像には特別な取り扱いが必要です。プリロードするか優先度を高く設定し、実際の寸法を設定し、lazy-loadしてはいけません。

実際にスマートフォンで変わることは何ですか？

スマートフォンは一度に3つのことを変更します：ビューポートの幅、ネットワーク品質、およびレイアウト密度です。デスクトップ用の画像がモバイルで失敗することがよくあるのは、ページが同じ1600 pxのアセットを維持したり、被写体を不適切に切り取ったり、ヒーロー画像をJavaScriptの背後に遅延させたりするためです。

私は1600 x 1000のソースグラフィックを生成し、3つの幅でWebP q82としてエンコードしました。この結果は、なぜリサイズが品質調整よりも優れているかを示しています：

これらの数値は例示的なものであり、普遍的なものではありません。詳細な写真はこれほどクリーンなグラフィックよりも大きくなり、平らなロゴはより小さくなります。役立つルールは安定しています：ブラウザに、単一のオーバーサイズのファイルではなく、実際の幅の候補から選択させるようにすることです。

どのようなモバイル画像サイズを作成すべきですか？

カメラファイルから始めるのではなく、レンダリングされるスロットから始めます。一般的なブレークポイントでテンプレートを検証し、各画像タイプについて最大のCSS幅を記録してください。

レイアウト幅が変更される場合は、幅記述子を使用してください：

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Reusable water bottle on a kitchen counter"
>

MDNのresponsive images guideは、srcsetとsizesの選択モデルを説明しています。要するに：srcsetが候補をリストし、sizesがレイアウトが完了する前にレンダリングされるスロットの幅をブラウザに伝えます。

バッチワークフローの場合、同じマスターファイルから幅を生成してください。batch resize guideはコマンドラインパターンを網羅しており、image compression deep diveはなぜ最終圧縮の前にリサイズを行うべきかを説明しています。

モバイルクロップにを使用すべきなのはいつですか？

モバイル画像が単に小さいファイルであるだけでなく、異なるクロップを必要とする場合に<picture>を使用します。広いデスクトップヒーロー画像は、被写体が左端にある場合やテキストエリアが製品を覆う場合、スマートフォンでは役に立たなくなります。

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Trail running shoe with the sole tread visible"
  >
</picture>

アートディレクションを使用すべきケース：

1. モバイルで製品が小さくなりすぎる製品のヒーロー画像。
2. 顔やオブジェクトが中央に留まらなければならない編集バナー。
3. 正方形のサムネイルと広い詳細画像が必要なマーケットプレイスのリスト。
4. 両方の側面が読みやすいままである必要があるビフォー/アフター画像。
5. 小さなテキストがあり、よりタイトなクロップが必要なスクリーンショット。

通常のレスポンシブ幅の代替として<picture>を使用しないでください。構成が同じ場合は、srcsetとsizesの方がシンプルです。

WebP、AVIF、JPEGはモバイルパフォーマンスにどのように適合しますか？

広く機能する単一のモダンファイルが必要な場合はWebPをベースラインのモバイルフォーマットとして使用してください。パイプラインで生成でき、WebPまたはJPEGフォールバックを残せる場合はAVIFを使用してください。メール、古いパートナーシステム、および他のツールが開く必要があるソースアーカイブのためにJPEGを残しておいてください。

complete image optimization checklistは、より広範なパブリッシングシーケンスを網羅しています。WebPとAVIFを出力するツールを比較する必要がある場合は、TinyPNG alternativesを参照してください。

<picture>スタックを使用できる場合：

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Blue ceramic mug beside a notebook">
</picture>

モバイルでのlazy loadingはどのように機能すべきですか？

最初のビューポートの下から始まる画像をlazy-loadします。LCP画像をlazy-loadしてはいけません。ブラウザレベルのlazy loadingは有用ですが、それ自体がパフォーマンス計画ではありません。

Googleのbrowser-level lazy loading guideは、オフスクリーン画像にネイティブなloading="lazy"を推奨しています。同じガイダンスは、すぐに表示される画像をlazy-loadすることに対して警告しており、これはユーザーが待っているコンテンツを遅延させる可能性があるためです。

このチェックリストを使用してください：

1. ヒーロー画像にはloading="eager"を与えるか、loading属性を省略する。
2. 最も可能性の高いLCP画像にfetchpriority="high"を追加する。
3. 最初の画面以降の画像にはloading="lazy"を追加する。
4. すべての画像にwidthとheightを設定する。
5. ブレークポイントによってレンダリング比率が変更される場合は、CSS aspect-ratioを使用する。
6. ヒーロー画像に対してJavaScriptのみによる画像インジェクションを避ける。
7. CDNの画像URLに長いキャッシュヘッダーが含まれていることを確認する。
8. デスクトップWi-Fiだけでなく、制限されたモバイルプロファイルでテストする。
9. PageSpeed InsightsでLCP要素を監視する。
10. デザイン変更後には再実行する。なぜなら、LCP要素は変わる可能性があるからです。

GoogleのLCP documentationは、画像要素、ビデオポスター、および背景画像を可能なLCP候補として挙げています。そのため、背景ヒーローであっても<img>ではない場合でも、LCPを損なう可能性があります。

画像CDNは何をするべきですか？

画像CDNは、反復的な手動作業を取り除く必要があります：エッジでのリサイズ、フォーマットの交渉、バリアントのキャッシュ、そしてパブリックURLの安定化です。CDNはソース衛生状態に取って代わるものではありません。ぼやけた900 pxの商品写真を画像CDNにアップロードしても、実際の1600 pxの詳細が生成されるわけではありません。

以下のコントロールを探してください：

• 一般的なモバイルおよびデスクトップのスロットのための幅変換（Width transforms）。
• 正しいContent-Typeを持つWebPとAVIFの出力。
• 幅、品質、フォーマットを含むキャッシュキー。
• 元のアップロードをパブリックな派生ファイルから分離して保持する方法。
• Google Imagesがクローリングできる安定したパブリックURL。
• デプロイや移行後の404エラーの監視。

検索のために、Googleのimage SEO best practicesは、関連テキストの近くにある有用で目に見える画像、説明的なファイル名とalt text、クローリング可能な画像URLを強調しています。CDN URLは、インデックス可能で、安定しており、ページから参照されている場合に問題ありません。

公開前に何をテストすべきですか？

モバイル訪問者が受け取る方法と同じようにページをテストしてください。Lighthouseの実行は役立ちますが、実際のテンプレートでのみ現れるCDNの欠陥、オーバーサイズのレスポンシブ候補、レイアウトシフトを見逃す可能性があります。

ローカル監査のための実用的なコマンド：

curl -I https://cdn.example.com/images/product-card-480.webp

次に、狭いビューポートでレンダリングされたページを確認してください。テーブルや画像が画面からはみ出す場合は、バイト節約を祝う前にレイアウトを修正してください。

モバイル画像SEOとGEOチェックリスト

検索

よくある質問

モバイル画像最適化における最大の単独の失敗は何ですか？

実際のリサイズ候補の srcset を使わず、1つの大きなマスター画像をすべてのビューポートに配信してしまうことです。

モバイル画像にはWebPとAVIFのどちらを使うべきですか？

WebPを安全なデフォルトとし、パイプラインで生成可能になった時点でAVIFを追加し、WebPまたはJPEGのフォールバックを残してください。

モバイルのヒーロー画像にはどの幅を生成すべきですか？

少なくとも480、768、1200 pxのWebPまたはAVIF候補を生成し、ブラウザが最も近いものを選べるようにしてください。

ヒーロー画像をモバイルで遅延読み込みすべきですか？

いいえ。ヒーローやLCPになり得る画像は fetchpriority="high" で即時読み込みにし、loading="lazy" にはしないでください。

srcsetの代わりにpictureを使うのはモバイルではいつですか？

製品写真が狭いビューポートで消えてしまうように、モバイル用の切り抜きを変える必要がある場合にだけ <picture> を使ってください。

400 pxのWebP画像は1600 pxのソースよりどれくらい小さくなりますか？

このガイドで計測した例では、同じソースが1600 pxの44 KBから400 px WebP q82では8 KBまで小さくなりました。

画像CDNで低解像度のソース写真を修正できますか？

いいえ。CDNはエッジでリサイズと再エンコードを行いますが、元のアップロード時に撮影されなかったディテールを再現することはできません。

モバイル画像を公開する前に何を確認すべきですか？

スマホが適切な幅の候補をダウンロードしていること、ヒーローが遅延読み込みされていないこと、すべての画像に説明的なaltテキストがあることを確認してください。

関連記事：画像SEO最適化：実用的な2026年チェックリスト

関連ツール：画像圧縮ツール

関連ツール：フォーマット変換ツール

関連ツール：画像リサイズツール