なぜ画像がページの重さを支配するのか
CSS と JavaScript を伴う典型的な HTML 文書は 200〜500 KB を転送するかもしれません。最適化されていない 1 枚の写真は 5〜15 MB になりえます。平均 10〜20 Mbps のモバイル接続では、10 MB の画像のダウンロードに 4〜8 秒かかります。ほとんどの訪問者は待ちません。
画像は Core Web Vitals——検索順位に影響するページ体験についての Google の指標——にも影響します。Largest Contentful Paint（LCP）は、最大の可視要素がレンダリングされるまでの時間を測ります。その要素がヒーロー画像なら、そのダウンロード時間が LCP スコアを直接決めます。遅い LCP はユーザー体験と検索順位の両方を損ないます。
よくある容疑者と、それぞれの直し方
画像の遅い読み込みは、ほぼ常にこれらのいずれかに行き着きます。それぞれに素早い直し方と意味のある見返りがあります：
| 原因 | 直し方 | 典型的な節約 |
|---|---|---|
| 間違った形式（PNG 写真） | WebP か JPG に変換 | 80% 以上 |
| フル解像度のアップロード | 表示幅の約 2 倍にサイズ変更 | 70〜80% |
| 弱いまたは省略された圧縮 | 品質 75〜85 で書き出す | 品質 95 比で 3〜5 倍 |
| 遅延読み込みなし | 折り返し下に loading=lazy を追加 | 初回読み込みのデータが減る |
| HEIC を未変換で配信 | まず WebP か JPG に変換 | 壊れた画像を避ける |
内容タイプに間違った形式
写真に PNG を使うのは、ウェブで最もよくある画像の間違いの 1 つです。PNG は可逆ですべてのピクセルを保ち、それはロゴやスクリーンショットには重要ですが写真にはそうではありません。PNG として保存した写真は 15〜25 MB になりえます。同じ写真を高品質 JPEG にすると 2〜5 MB です。WebP なら、同一の見える品質で 2 MB 未満になりえます。
逆もまた間違いです：スクリーンショット、図、テキストのある画像に JPEG を使うこと。JPEG は硬いエッジと平坦な色の領域に見えるアーティファクトを入れ、大きなファイルを生む高い品質設定を要します。PNG や WebP はこの内容をより小さくきれいに扱います。
フルカメラ解像度で画像をアップロードする
現代のスマホの写真は 12〜50 メガピクセルで幅 3000〜8000 ピクセルです。ほとんどのウェブページは内容画像を幅 600〜1600 ピクセルで表示します。フル解像度のカメラファイルをサイトにアップロードすると、ブラウザは 8000 ピクセルすべてをダウンロードし、表示用に 800 ピクセルにスケールします。必要の 10 倍のデータを転送しているのです。
画像を、表示される最大の幅——高密度画面では CSS 表示幅の約 2 倍——にアップロード前にサイズ変更することは、しばしば利用可能な唯一の最大のサイズ削減です。4000 ピクセルの画像を 1600 ピクセルにサイズ変更すると、品質圧縮を適用する前に通常 70〜80% 小さくなります。
圧縮を省略する、または間違った品質設定を使う
多くのコンテンツ管理システムは、アップロードされた画像を圧縮せずに受け入れ保存します。WordPress、Squarespace、Shopify や類似のプラットフォームは既定で多少の圧縮を適用するかもしれませんが、設定はさまざまでしばしば保守的です。アップロードされた元画像は必要よりずっと大きいことがあります。
JPEG と WebP には、ウェブページに表示されるほとんどの写真に品質 75〜85 が適切です。75 未満では圧縮アーティファクトが見えます。85 を超えると、ファイルサイズが大きく増える一方で視覚的改善は減ります。多くの開発者は既定で品質 95 か 100 にし、それは品質 80 比で 3〜5 倍大きいファイルを、通常の表示サイズで見える違いなく生みます。
折り返しより下の画像に遅延読み込みがない
既定では、ブラウザは最初のレンダリング中にページのすべての画像を読み込もうとし、可視領域（折り返し）よりずっと下の画像も含みます。10 枚の画像のある長い記事ページでは、読者がほとんどを見るまでスクロールしないかもしれなくても、ブラウザは 10 枚すべてを同時にダウンロードしようとします。
<img> タグの loading="lazy" 属性は、画像がビューポートに入る直前まで読み込みを遅らせるようブラウザに指示し、初回ページ読み込みで転送されるデータを大きく減らします。最初のビューポートに見えないすべての画像に適用してください。ヒーロー画像や折り返しより上の画像には適用しないでください——それらは良い LCP スコアのためにできるだけ速く読み込む必要があります。
ヒーロー画像には特に fetchpriority="high" を追加し、ブラウザがスクリプトや他の画像より先に取得するようにします。1 ページにつき 1 つの画像——LCP 要素——にだけ使い、残りは既定のままにします。
<img src="photo.webp" loading="lazy" alt="description" /><img src="hero.webp" fetchpriority="high" width="1200" height="675" alt="hero" />
width と height 属性の欠如
ブラウザがページのレンダリングを始めるとき、まだダウンロードしていない画像の寸法をまだ知りません。HTML に明示的な width と height 属性がないと、ブラウザは正しいスペースを確保できず、画像が読み込まれるにつれてページのレイアウトがずれます——Cumulative Layout Shift（CLS）として知られる不快な視覚的ジャンプです。明示的な寸法を加えるとレイアウトのずれを防ぎ、ブラウザが画像のダウンロードを待たずにレイアウトを始められます：
<img src="photo.webp" width="800" height="533" alt="description" />
HEIC や珍しい形式を直接アップロード
iPhone は既定で HEIC で撮影します。HEIC ファイルがウェブサイトにアップロードされ変換なしで配信されると、Chrome、Firefox、Edge で表示に失敗します。Windows と Android の訪問者は壊れた画像アイコンを見ます。公開前に常に HEIC を JPEG か WebP に変換してください。
実用的な最適化チェックリスト
PhotoTools は、何もサーバーにアップロードせず、ブラウザ内で形式変換、サイズ変更、圧縮のステップを扱います。ページを速く保つためアップロード前に画像を処理し、このチェックリストを通してください：
- 写真とほとんどのウェブ画像には WebP を使う。テキストや透明度のあるグラフィックには PNG を使う。
- 画像を実際に表示される最大の幅——Retina 画面では CSS 表示幅の約 2 倍——にサイズ変更する。
- 標準のウェブ画像には JPEG と WebP を品質 75〜85 で圧縮する。
- 折り返しより下のすべての画像に loading="lazy" を追加する。
- すべての画像に明示的な width と height 属性を追加する。
- アップロード前に HEIC ファイルを JPEG か WebP に変換する。
- 最終的なファイルサイズを確認する：800 CSS ピクセル幅で表示されるウェブ画像は、ほとんどの場合 200 KB 未満であるべき。