Core Web Vitals を画像圧縮で改善する完全ガイド【LCP対策】

なぜ画像が Core Web Vitals を下げるのか

Google が検索ランキングの評価基準に組み込んでいる「Core Web Vitals」は、現在3つの指標で構成されている。

• LCP（Largest Contentful Paint）：ページ内で最も大きなコンテンツが描画されるまでの時間
• INP（Interaction to Next Paint）：ユーザー操作から次の描画までの応答速度
• CLS（Cumulative Layout Shift）：読み込み中に発生するレイアウトのずれ

このうち画像が直撃するのは LCP だ。ファーストビューに置かれたヒーロー画像や記事アイキャッチが LCP 対象要素になるケースは非常に多く、ファイルが重いほど「良好」の合格ライン（2.5秒以内）を超えやすい。Google の Core Web Vitals 技術文書 では、LCP 悪化の主因として「リソースのロード時間」が明示されており、その代表格が最適化されていない画像ファイルだ。

デジタルカメラやスマートフォンが出力する JPEG は、無処理のまま 3〜8 MB に達することが珍しくない。そのファイルをそのまま CMS にアップロードし続けた結果、PageSpeed Insights の LCP が「改善が必要（2.5秒超）」になっているサイトは今でも大量に存在する。

CLS への影響も見落とさない

CLS への影響も軽視できない。画像タグに width・height 属性が設定されていない場合、ブラウザは読み込み完了まで表示領域を確保できず、後からレイアウトがずれる。圧縮によって読み込みを速くしつつ、属性指定でスペースを事前に予約する組み合わせが CLS スコアの維持にも寄与する。

PageSpeed Insights が出す画像関連の警告を読む

PageSpeed Insights で計測した際に以下のいずれかが「改善が必要」として表示されているなら、画像圧縮は費用対効果が最も高い改善アクションになる。

• 「適切なサイズの画像」
• 「効率的な画像エンコード」
• 「次世代フォーマットでの画像の配信」

圧縮前後のスコア変化の目安

ファイルサイズ別の改善期待値を下表に示す。値はページ構成や通信速度によって変動するが、3 MB 超の画像を抱えているページはほぼ例外なく効果を体感できる。

圧縮後は必ず PageSpeed Insights または Chrome DevTools の Lighthouse で再計測し、改善幅を数値で把握する。「やった気になる」だけで終わらせないためにも、計測は必須のステップだ。

画像圧縮の一般的な手順（ツール非依存）

ツールを問わず共通する圧縮の流れを4ステップで整理する。

ステップ 1：LCP 対象要素を特定する

Chrome DevTools を開き、Lighthouse タブで「パフォーマンス」を計測する。レポートの「LCP」セクションをクリックすると、対象要素がハイライト表示される。まずその要素の URL とファイルサイズを確認することが出発点だ。対象要素が思ったものと異なるケースは多い。CMS が自動生成したサムネイルや、CSS の background-image で指定した画像が LCP になっていることもある。

ステップ 2：リサイズと圧縮をセットで行う

「圧縮」と「リサイズ（解像度の変更）」は別の操作だが、セットで考えると効果が大きい。横幅 800 px で表示している領域に対して 3,000 px 幅の画像を使っていれば、まず 800 px 程度にリサイズしてから JPEG 品質を 70〜80 % に落とすだけで、ファイルサイズが元の 10 分の 1 以下になることがある。品質を下げる前にまずリサイズを行うのが、視覚品質を保ちながらサイズを削るコツだ。

ステップ 3：フォーマットを検討する

WebP は JPEG と比較して同等の視覚品質で 20〜30 % 程度ファイルサイズを削減できる。MDN の WebP 解説 によれば、現在の主要ブラウザは広く WebP をサポートしており、モダンな環境では JPEG を WebP に置き換えるだけでも LCP に貢献する。ただし古い CMS 環境やメールマガジンへの埋め込みなど、WebP 未対応の環境が対象に含まれる場合は慎重に判断する。

ステップ 4：HTML の属性を整備する

圧縮後、画像タグに width・height 属性を設定して CLS を防ぐ。ファーストビューの画像には loading="eager"（または属性なし）、スクロール先の画像には loading="lazy" を使い分けると、必要なリソースが優先的に読み込まれる。ファーストビュー画像への loading="lazy" は LCP を悪化させる典型的な誤りなので注意が必要だ。

zerosend を使ったブラウザ内圧縮の手順

zerosend の画像圧縮ツール は、圧縮処理をサーバーではなくブラウザ内で完結させる設計になっている。使用しているライブラリは browser-image-compression（Web Worker） で、メインスレッドをブロックせずにバックグラウンドで処理を走らせる。ファイルの内容は一切外部サーバーに送信されない。

ステップ 1：ツールにアクセスする

https://zerosend.site/tools/image-compress をブラウザで開く。インストール不要、アカウント登録不要。Service Worker によるキャッシュが有効なため、初回ロード後はオフライン環境でも動作する。社内ネットワークでインターネットアクセスが制限されている環境でも、一度ロードさえしておけば継続して使用できる。

ステップ 2：ファイルを選択する

ドラッグ＆ドロップ、またはファイル選択ダイアログで画像を読み込む。JPEG・PNG・WebP に対応している。複数ファイルをまとめて読み込むバッチ処理にも対応しており、複数枚を一度に圧縮できる。

ステップ 3：品質スライダーを調整する

品質 70〜80 % が Web サイト用途のデフォルト推奨値だ。ファーストビューの主要ビジュアルであれば 80 %、背景画像や繰り返し使うアイコン類なら 65〜70 % でも視覚的な劣化はほぼ感じられない。スライダーを動かすたびにプレビューが更新されるため、圧縮前後の見た目を比較しながら数値を決められる。

ステップ 4：Network タブでアップロード通信がゼロであることを確認する

セキュリティポリシーが厳しい環境での利用前や、「本当にサーバーに送っていないか」を確認したい場合は、自分で検証できる。Chrome DevTools を開いて Network タブを選択し、ツールを操作しながらリクエストを監視する。画像ファイルに関するアップロード通信が一切発生しないことをリアルタイムで確認できる。クラウド型のサービスではこの確認を行うとアップロードリクエストが記録されるが、zerosend では何も記録されない。

ステップ 5：ダウンロードして CMS に反映する

圧縮後のファイルをダウンロードし、そのまま CMS やサーバーにアップロードする。元ファイルとのサイズ比較が画面上で確認でき、何 % 削減されたかが数値で表示される。

主要ツールとの比較

圧縮ツールを選ぶ際に重視される観点を整理した。特に「送信先サーバー」列は、機密性の高い画像を扱う場合に見落としがちな観点だ。

Smallpdf・iLovePDF・TinyPNG はいずれもクラウドサーバーでの処理が前提であり、アップロードしたファイルは一時的にでも外部サーバーに送信される。個人写真・社内資料・顧客から提供された素材を扱う場合、そのリスクは無視できない。

Squoosh はブラウザ内処理でプライバシー面に優れているが、1 ファイルずつしか処理できないため、複数枚を日常的に扱うワークフローには向いていない。zerosend は複数ファイルの一括処理に対応している点で、実務的な運用に組み込みやすい。

よくある落とし穴と対処法

圧縮したのに LCP が改善しない

最も多い原因は「圧縮した画像とは別のファイルが実際には LCP に使われている」ケースだ。CMS のプラグインが自動生成したサムネイル画像が LCP 対象になっていたり、CSS の background-image で設定した画像が LCP 要素になっていたりする。Lighthouse のレポートで対象要素の URL を確認し、実際に差し替えたファイルと一致しているかを必ず検証する。

もう一つの原因として、ファーストビュー画像に loading="lazy" が設定されている場合がある。lazy-load は LCP 対象要素には逆効果になるため、ファーストビューの画像には設定しない。

圧縮しすぎてブランドイメージを損ねた

品質を 50 % 以下まで落とすと、JPEG 特有のブロックノイズが目立ち始める。特に人物写真やグラデーションを含む画像では視覚的な劣化が顕著になる。品質は 70〜80 % を下限の目安とし、どうしてもファイルサイズを削りたい場合はリサイズを先に行う方が品質を維持しやすい。

一度だけ対応して終わりにした

新しいページを追加するたびに未最適化の画像が混入すると、サイト全体のスコアは再び悪化する。制作フローに「アップロード前に圧縮ツールを通す」というステップを明示的に組み込むか、CMS の自動最適化機能（WordPress であれば ShortPixel や Imagify 等のプラグイン）を併用することで、属人的な対応をなくすことができる。

100 KB 以下でも警告が出る

ファイルサイズではなく「表示サイズに対して解像度が過剰」と判定されている場合に出る。例えば 100 KB の PNG でも、横幅 2,000 px で書き出されたものを 400 px の領域で表示していれば警告対象になる。リサイズで解像度を表示サイズに合わせることで解消する。

FAQ

Q1. 圧縮すると SEO 的に不利になることはあるか？

ない。Google は表示速度を評価するが、同一 URL で提供される限りファイルサイズの変化それ自体がコンテンツの品質評価に影響することはない。むしろ圧縮によって LCP が改善すれば Core Web Vitals のスコアが向上し、検索順位にプラスに働く可能性がある。

Q2. WebP への変換は必須か？

必須ではないが効果は高い。既存の JPEG を WebP に変換するだけで 20〜30 % のファイル削減が見込めるため、LCP がギリギリ合格ラインにあるページでは変換を検討する価値がある。ただし古い CMS 環境やメールマガジンへの埋め込みなど、WebP 未対応の環境が対象に含まれる場合は注意が必要だ。

Q3. zerosend で PNG を WebP に変換することはできるか？

zerosend の画像変換ツールでは、PNG・JPEG を WebP に変換する機能を提供している。圧縮と変換を組み合わせることで、さらに大きなファイルサイズ削減が期待できる。変換処理もブラウザ内で完結するため、ファイルは外部に送信されない。

Q4. スマートフォン撮影の写真を直接圧縮してもよいか？

問題ない。ただしスマートフォン写真は EXIF データ（GPS 情報・撮影日時等）を含むことが多い。zerosend のブラウザ内処理ではファイルが外部に送信されないため、EXIF データを含む写真でも情報漏洩のリスクなしに圧縮できる。クラウド型サービスでは EXIF 情報ごと外部サーバーに送信される点と対照的だ。

Q5. 画像圧縮以外に LCP を改善する手段はあるか？

ある。CDN の利用、サーバー応答時間の短縮、<link rel="preload"> による画像の事前読み込み指定、フォントの最適化などが代表的な手段だ。ただしこれらは設定変更やインフラ費用を伴うことが多く、即効性という点では画像圧縮が最も着手しやすい。画像圧縮で対処できる改善余地をまず使い切り、それでも目標値に届かない場合に他の手段を検討するのが現実的な順序だ。

まとめ

Core Web Vitals のうちページ表示速度に最も直結する LCP を改善するには、画像圧縮が最も即効性の高い手段だ。対応の手順は「LCP 対象要素の特定 → リサイズ → 圧縮 → HTML 属性の整備 → 再計測」のサイクルを回すだけであり、特別な専門知識は不要だ。

プライバシーが気になる業務用途では、ファイルをサーバーに送信しないブラウザ内処理ツールを選ぶことが重要になる。zerosend の画像圧縮ツールは browser-image-compression を Web Worker で動作させており、Chrome DevTools の Network タブでアップロード通信がゼロであることを誰でも自分で検証できる。初回ロード後は Service Worker のキャッシュによりオフライン環境でも動作するため、ネットワーク制限のある環境でも継続して使用できる。

一度の対応で終わらせず、画像をアップロードする前に圧縮するというステップを制作フローに組み込むことが、Core Web Vitals のスコアを継続的に維持する最も現実的な方法だ。