適切な画像サイズ：800pxの枠に4000pxの写真を配信するのをやめる

画像がレンダリングされる最大の幅を測定し、高密度ディスプレイ用にそれを2倍にして、ライブラリをその数値にリサイズします。 800ピクセルの枠に4000ピクセルの写真を配信すると、ブラウザは表示できる量の約25倍のピクセルデータをダウンロードし、残りを破棄することになります。

スマートフォンの接続環境では、訪問者はそのすべての時間とデータ通信量に対してコストを支払うことになります。画像を適切にリサイズすることは、通常、サイトで利用可能な単一のページ軽量化対策として最も効果が大きく、デザインを刷新するのではなく、1回の一括処理で済みます。

サイズ超過の画像が大きなコストを伴う理由

ファイルサイズはピクセル数に比例するため、幅と高さを半分にすると、データの約75パーセントが削減されます。 この関係は線形ではなく二次関数的であるため、無駄が急速に膨らむことになります。

最初の行は、編集者がカメラから直接アップロードするサイトでよく見られるケースです。ブラウザは4.2 MBをダウンロードし、縮小して、180 KB相当のファイルを表示します。

実際の表示サイズを測定する方法

公開されているページ上の画像を右クリックして「検証」を選択し、元のサイズではなく、表示されている寸法を確認します。 ブラウザは両方の数値を報告し、その差が無駄になります。

一般的なケースではなく、最も幅が広くなるケースを確認してください。記事カラム内の画像は、デスクトップでは700ピクセル、スマートフォンでは380ピクセルでレンダリングされる可能性があるため、重要なのは700という数値です。全幅のバナーはビューポートに合わせて拡大し、異なる計算が必要になるため、訪問者が現実的に使用する最も広いブラウザウィンドウでテストしてください。

高密度ディスプレイ用の「2倍ルール」

表示幅に2を掛け、それ以上は増やさないでください。その密度を超えるディスプレイでは、誰も気づくような画質の向上は見られないからです。 700ピクセルで表示される画像は、1400ピクセルで書き出す必要があります。

3倍にすることが提案されることもありますが、それが正当化されることはほとんどありません。通常の視聴距離では、2倍と3倍の密度の違いは判別できない一方で、ファイルサイズは半分以上増加します。余分なピクセルが圧縮ノイズを目立たなくさせるため、3倍の密度で軽く圧縮するよりも、2倍の密度で強めに圧縮する方が良い結果をもたらします。

リサイズ対象となる一般的な表示幅

• 記事本文の画像： 表示は約700 px、書き出しは1400 px。
• 全幅のヒーロー画像： 表示は最大1920 px、書き出しは1920 pxにして強めに圧縮。
• 半分幅のフィーチャー画像： 表示は約600 px、書き出しは1200 px。
• 製品グリッドのサムネイル： 表示は約300 px、書き出しは600 px。
• 著者またはプロフィールの写真： 表示は約80 px、書き出しは160 px。
• ヘッダー内のロゴ： 表示は約180 px、書き出しは360 pxにするか、ベクターグラフィックスを使用。

全幅画像が例外である理由

全幅のバナーには固定の表示サイズがないため、2倍にするのではなく、1920ピクセルを上限として強めに圧縮します。 全幅画像を2倍の3840ピクセルにすると、どのページでも正当化できないファイルサイズになってしまいます。

バナーは通常、離れて見られるものであり、製品写真ほど細かいディテールを持たないため、アグレッシブな圧縮を行っても目立ちにくいです。WebPの品質70で作成した1920ピクセルのバナーは、通常200 KB未満に収まり、すべての画面で適切に表示されますが、3840ピクセルのバージョンは4倍の重さになりながら、目に見えるメリットはありません。

ライブラリ全体を修正する方法

既存のサイトを正しくリサイズするには、以下の6つのステップに従ってください。

1. デザイン内の画像枠をリストアップします。通常、数十種類ではなく、4〜6種類の異なるサイズに収まります。
2. 公開されているページでブラウザの検証ツールを使用し、各枠の表示幅を測定します。
3. 各幅を2倍にして、書き出しサイズを決定します。
4. 一括処理ではフォルダ内のすべてのファイルに1つのサイズが適用されるため、ライブラリを枠ごとのフォルダに分類します。
5. 各フォルダをターゲットの幅にリサイズし、同じパスで圧縮と変換を行います。
6. 既存のページが引き続き機能するように、同じファイル名を維持してファイルを置き換えます。

フォルダへの分類は、この作業を一括処理に変えるステップです。ほとんどのサイトでは、想定しているよりもはるかに少ない種類の画像サイズしか使用しておらず、枠ごとにグループ化することで、ファイルを個別に処理する必要がなくなります。

レスポンシブ画像とsrcset属性

srcsetを使用して複数のサイズを提供し、デバイスごとに最適なサイズをブラウザに選択させます。 これにより、同じマークアップから、スマートフォンは400ピクセルのファイルをダウンロードし、デスクトップは1400ピクセルのファイルをダウンロードするようになります。

画像ごとに3つの幅（一般的には400、800、1600ピクセル）を生成し、ブラウザが選択できるようにピクセル幅とともにリストします。ほとんどのコンテンツ管理システムはアップロード時にこれを自動的に生成するため、お使いのプラットフォームの既存の機能を確認してください。自動生成される場合でも、適切にサイズ調整されたオリジナルをアップロードすることで、生成されるすべてのバリアントが向上します。

圧縮する前に、必ずリサイズする

最初にリサイズすることで、圧縮処理の負荷が減り、ファイルを小さく保ちながら高品質を維持できます。 最初に圧縮してからリサイズすると、残したディテールを再び捨てることになります。

この順序は、結果の見た目にも影響します。フルサイズで圧縮された画像には、縮小されたときに目立ちやすくなるノイズが含まれます。ノイズも一緒に縮小されるためです。最初にリサイズすることで、エンコーダーにとってよりクリーンなソースが作成され、同じファイルサイズで著しく優れた結果が得られます。

ページ速度への影響

画像を適切にリサイズすることで、これまで対策を行っていなかったサイトでは、通常、画像重量の60〜90パーセントが削減されます。 この改善効果は、フォーマットの変更よりも大きく、通常、他のすべての最適化を組み合わせたものよりも大きくなります。

この効果は、接続が遅くデータ通信にコストがかかるモバイル訪問者に集中します。Largest Contentful Paint（LCP）は通常、1つの大きな画像によって決定されるため、直接的に改善されます。Lighthouseの「適切なサイズの画像」の監査をクリアすると、多くの場合、関連する2〜3の警告も同時に解消されます。

枠に合わせるために画像を拡大しない

拡大すると、カメラが捉えていないピクセルが追加されるため、結果がぼやけ、メリットがないのにファイルサイズだけが大きくなります。 縮小は常に安全ですが、拡大は確実に見た目が悪くなる唯一の操作です。

元の画像が埋めるべき枠よりも小さい場合、適切な選択肢は、自然なサイズで使用するか、その周囲のレイアウトを切り取るか、画像を差し替えることです。600ピクセルの写真を1600ピクセルに拡大すると、元の4倍の重さのぼやけたファイルが作成され、品質と速度の両方で同時に失敗することになります。

ページ内のサイズ超過画像の確認

開発者ツールを開き、「ネットワーク」タブに切り替え、画像でフィルタリングしてページを再読み込みします。 リストには、転送サイズが大きい順に並べ替えられたすべての画像が表示されます。

500 KBを超える単一の画像は調査する価値があり、画像の合計が2 MBを超えるページには問題があります。「要素」パネルで画像の上にホバーすると、元のサイズと表示サイズが並んで表示されます。これら2つの数値の間に大きな差があることが、不適切なサイズ設定の定義であり、数秒で確認できます。

ライブラリを1回で一括リサイズする

画像を個別にリサイズするのではなく、ターゲットの幅を一度設定して、フォルダ内のすべてのファイルに適用します。 数百枚の画像があるライブラリでも、作業を一括処理すれば数分でリサイズが完了します。

最大500個のファイルを一度にドロップするか、ZIPアーカイブを直接ドラッグインして、セット全体の幅、フォーマット、圧縮ターゲットを設定します。すべてがご自身のプロセッサ上のブラウザ内で実行されるため、クライアントのサイト、ステージングアセット、未公開のギャラリーがサーバーに送信されることはありません。何もアップロードされないため、ネットワークを介してファイルを1つも送信することなく、ライブラリ全体のリサイズが完了します。