Webサイトの画像は、表示に必要な大きさへ縮小し、見た目を保てる範囲で圧縮すると軽くできます。写真にはJPEG・WebP・AVIF、ロゴや図にはSVGやPNGなど、内容に合った形式を選ぶと効果的です。
さらに、画面の下にある画像を後から読み込むと、最初に必要な画像へ通信を回しやすくなります。ただし、最初から見える主画像まで遅延読み込みにすると、かえって表示が遅れる場合があります。
画像の役割と表示寸法から着手する
最初にPageSpeed Insightsを使い、改善候補と利用者環境での表示を確認します。大きなファイルから機械的に直すのではなく、最初に見える主画像や繰り返し表示される画像を優先します。装飾だけの画像は、削除やCSSへの置き換えが可能かも検討します。
元画像のピクセル数と、画面上で表示される幅を比べます。小さな枠へ極端に大きい写真を配信しても、ブラウザ側で縮小されるだけです。例えば幅400pxの枠へ幅4,000pxの写真を出すと、多くのデータが表示に生かされません。高密度画面向けに幅800pxの候補を用意するなど、表示幅と解像度に合わせて配信する方法があります。
形式は写真・透過・図形の性質で選ぶ
写真の色のなめらかさと、文字や図の輪郭では、圧縮したときに気になる部分が違います。用途ごとの候補は次のとおりです。
| 画像の用途 | 候補となる形式 | 見たいところ |
|---|---|---|
| 写真 | JPEG・WebP・AVIF | 容量、色、細部の劣化 |
| 文字入りの画面画像 | PNG・WebPなど | 細い文字がつぶれないか |
| 透過が必要な画像 | PNG・WebP・AVIF | 背景の透過と輪郭 |
| ロゴ・単純な図形 | SVG | 拡大時の鮮明さ、ファイルの安全性 |
外部から受け取ったSVGにはスクリプトなどが含まれる可能性があるため、安全性も確認します。WordPressへ無条件にアップロードできる設定へ変えるのは避けます。
新しい形式が常に最小になるとは限らず、画像内容と変換設定で結果が変わります。形式名だけで採用せず、実ファイルの容量と表示品質を見ます。対応環境に幅があるサイトではpicture要素などで代替形式を用意し、配信後の応答形式も確認します。
圧縮は文字と輪郭が読める範囲で調整する
圧縮率は一律の数値にせず、写真・商品画像・スクリーンショットごとに見本を作ります。人物の髪や商品の境界、細い文字など劣化が見えやすい箇所を等倍で確認します。元データは公開ファイルと分けて保管し、再編集のたびに圧縮を重ねません。
ブラウザ上の変換サービスを使う場合は、機密情報や位置情報を含む画像を外部へ送ってよいか確認します。自動化ツールでは変換後の上書き条件と除外対象を決めます。変換によって色、透過、縦横の向きが変わる場合もあるため、容量と見た目の両方を確認します。
レスポンシブ配信で端末ごとの無駄を減らす
srcsetには幅の異なる画像候補を示し、sizesにはレイアウト上の表示幅を伝えます。ブラウザは画面や解像度に応じて候補を選びます。候補だけ増やしてもsizesが実際のレイアウトと違えば、必要以上に大きい画像が選ばれる場合があります。
背景画像や独自の表示部品では、本文画像と異なるサイズが必要な場合があります。候補画像を追加した後は、ブラウザが実際に選んだ画像も確認すると効果を判断しやすくなります。
遅延読み込みは画面外の画像に限定する
遅延読み込みは、最初の画面に不要な画像の取得を後へ回す方法です。記事下部の画像には役立ちますが、主画像まで遅らせるとLargest Contentful Paintを悪化させる場合があります。画面内の重要画像には遅延指定を使わず、必要に応じて優先度を調整します。
画像の幅と高さをHTMLへ示すと、読み込み前に表示領域を確保できます。遅延読み込みだけを追加しても、画像表示時にレイアウトが動けば読みやすさを損ねます。PCとスマートフォンでスクロールし、表示直前に画像が間に合うかも確認します。
WordPressでは、元画像と自動生成画像を分けて考える
WordPressはアップロードした画像から複数のサイズを生成します。ただし、テーマが常に原寸画像を表示している場合は、候補があっても軽い画像が使われません。テーマやブロックの出力も関係します。
過去の画像を一括変換する場合は、まず少量で表示を確かめ、元データを残しておくとやり直せます。未使用に見える画像も、CSSや別ページから参照されている場合があるため、容量を減らす目的で無条件に削除するのは避けます。
画像を軽くした後は、スマートフォンでも文字や商品写真が見やすいかが大切です。圧縮率を限界まで上げるより、読者が必要な情報を読み取れる範囲で容量を減らす方が、サイトの目的に合います。