PageSpeed Insightsの「画像配信を改善する」を解決するには

1. 01PageSpeed InsightsまたはLighthouseで該当ページを開きます。モバイルかパソコンのレポートを選び、「画像配信を改善する」を展開して画像URLと修正案を記録します。
2. 02ページ上で画像を探します。ブラウザの開発者ツールで、画面密度を考慮しつつダウンロード画像と表示寸法を比較します。メディアライブラリの原本だけでなく、選択された画像を確認してください。
3. 03配信画像の画素が多すぎる場合、まずレスポンシブな寸法やテーマ設定を修正します。寸法が適切なら、圧縮や対応する別形式を比べます。
4. 04画像編集ソフトで必要な寸法のコピーを用意します。適切なファイルをBitinz画像圧縮ツールで処理し、差し替え前に文字、輪郭、透明度、グラデーションを確認します。
5. 05新しい画像やテンプレート変更を公開します。古いキャッシュではなく新しい画像を要求していることを確認し、同じ端末設定で再測定します。

Chromeはダウンロード容量と、その形式に適したバイト数・画素数の比率から節約量を推定します。推定節約量が4 KiB未満の画像は指摘しません。これはレポート上のしきい値であり、推奨する最大画像容量ではありません。

Lighthouse 13では旧来の画像監査がこの分析に置き換わり、Lighthouse 12では既に分析が標準表示でした。形式、過大な寸法、重いアニメーションでは対処が異なります。公開全体の流れはサイト向け画像の圧縮方法をご覧ください。

• WordPress: ブロックやテーマで選んだ画像サイズと、実際のsrcset、sizesを確認します。WordPressはレスポンシブな候補を生成しますが、独自テンプレートや不正確なレイアウト指定で不適切なサイズが配信されることもあります。原本だけ直しても生成済みのコピーが使われ続ける場合があります。
• Shopify: ストアの画像は形式選択を含めてShopifyのCDNが既に最適化しています。Shopifyはアップロード前の手動圧縮は不要と説明しています。警告が出たら元画像を繰り返し劣化させず、テーマが要求する幅とレスポンシブな記述を確認しましょう。開発者はimage_urlとimage_tagを確認できます。
• Next.js: Imageコンポーネントのレスポンシブ設定を使い、sizesを実際のレイアウトに合わせます。特にfill使用時は注意してください。適切な値がないと幅の狭い画像も画面全幅とみなされ、大きな候補がダウンロードされることがあります。画質だけ変えても、この不一致は直りません。

編集可能な原本を保管します。独立して配信する画像は容量と見た目を比較し、JPG・PNG・WebPの比較を参考に選びましょう。Bitinzは寸法を変更しません。WebP変換で大きくなる場合もあるので、ページに合う版を残してください。

繰り返し公開する場合、開発者APIで適切なファイルを処理できます。アカウントと月間利用枠が必要で、テーマの記述やレスポンシブレイアウトを直す機能ではありません。自動化後も公開ページを確認してください。

• 指摘されたURLが、変更した画像と版に一致している。
• スマートフォンと広い画面の両方で、適切な画像が選ばれる。
• 圧縮後も必要な細部、透明度、滑らかなグラデーションが残っている。
• 不適切な遅延読み込み設定が、最初に見える主画像を遅らせていない。
• 同じ端末設定で再測定し、実際の表示と読み込みも確認した。