画像圧縮でWeb表示速度は変わる?Lighthouseで圧縮前後を同一条件で実測した結果

著者: Photrim編集部 公開日: 更新日:

ブログ記事と商品一覧の検証ページで、画像の圧縮前後をLighthouse(模擬Slow 4G)で7回ずつ測定。標準でLCPはブログ5.10秒→1.95秒、商品一覧7.13秒→1.95秒に。一方、ネットワーク制限なしでは差が出ず、FCPやCLSも変わりませんでした。

検証方法: 同じ内容の検証ページを、画像だけ圧縮前・Photrim高画質・標準・高圧縮の4通り用意し(圧縮はApp\Domain\ImageCompression\Service\CompressServiceで実施)、Lighthouse 13.5.0で同一条件・複数回測定した実測値です(backend/scripts/speed-case-study/、全測定値はbackend/scripts/speed-case-study/results/2026-10-04.jsonとresults/2026-10-04-provided.json、詳細は本文「測定条件」参照)。

この記事で分かること

「画像を圧縮すると、Webページの表示は速くなるのか」を、一般論ではなく同じ条件で測った数値で確認します。画像を軽くすると、ページに載せる画像の合計容量が減ることは別の記事で確かめました。この記事では、その容量の違いが表示にかかる時間にどう表れるのかを、Lighthouseで測定しました。

先にお伝えしておくと、結果は「圧縮すれば必ず速くなる」というものではありません。回線が細い条件では大きく改善しましたが、ネットワークの制限がない条件では差が測れず、最初の表示(FCP)やレイアウトのずれ(CLS)は変わりませんでした。良い結果だけでなく、変化が出なかった条件も含めて掲載します。

  • 同じページで、画像だけ圧縮前・Photrim高画質・標準・高圧縮の4通りを比べた結果
  • 変化が大きかった指標と、変わらなかった指標
  • 画像以外に表示速度を左右する要因
  • 再現する手順と、この測定の限界

測定したページ

画像以外のすべて(文章・スタイル・画像の寸法・読み込み方)を同一にした、2種類の検証ページを用意しました。

  • ブログ記事ページ: アイキャッチ、本文の写真(JPEG・WebP)、スクリーンショット(PNG)の4枚。圧縮前の合計は771.8KBです(ブログ・ECの画像を軽くする実例と同じ画像)。
  • 商品一覧ページ: 商品写真(1200×1200px)12点を2列で並べたページ。圧縮前の合計は2,111.4KBです。ボトルと化粧箱の色味を変えた12種類の別々の画像を使っています。

画像は、このプロジェクトで生成した画像で、実写真ではありません(実写真では結果が変わります)。各ページは、HTMLとCSSをファイル内に含め、JavaScriptや外部のフォント・計測タグは使っていません。画像にはwidth・height属性を指定しています。圧縮はPhotrimの圧縮処理(CompressService)へ、高画質・標準・高圧縮のそれぞれで実際に画像を渡して行いました。

測定条件

  • 実行日: 2026年10月4日
  • 測定ツール: Lighthouse 13.5.0(Chrome 154のヘッドレスモード)
  • 測定した環境: Apple M6搭載のMac(メモリ24GB、macOS 27.0.1)
  • Photrimのコミット: 27b312b
  • メインの測定(模擬Slow 4G): Lighthouse既定のモバイル条件で、ネットワークを模擬的に制限しました(通信の往復遅延150ms、スループット1,638.4Kbps、リクエスト遅延562.5ms、CPUは4倍遅く)。--throttling-method=simulateです。
  • 比較用の測定(制限なし): ネットワークとCPUを制限しない条件(--throttling-method=provided)でも測定しました。
  • ページは同じマシン上のPHP組み込みサーバーから配信しました。実際のネットワークの遅延は含まず、模擬条件ではLighthouseのシミュレーションが回線の遅さを再現します。
  • 回数: 模擬Slow 4Gは各条件7回、制限なしは各条件5回。測定の順序は、条件ごとに偏りが出ないよう、1巡ごとにずらしました。
  • 表の値はすべて中央値です。かっこ内は最小〜最大です。

測定の途中で、私の操作ミスで検証用サーバーを止めてしまい、その時点で失敗した2回分を、同じ条件で測り直しています(2回のやり直しを除き、すべて有効な測定結果です)。

結果1:模擬Slow 4Gでは、表示が大きく速くなった

ブログ記事ページの結果です。

画像 画像の転送量 LCP Lighthouseのスコア
圧縮前 772.4KB 5.10秒 81
高画質 293.7KB 2.55秒 97
標準 162.2KB 1.95秒 99
高圧縮 123.9KB 1.80秒(1.65〜1.80秒) 100

商品一覧ページの結果です。

画像 画像の転送量 LCP Lighthouseのスコア
圧縮前 2,113.1KB 7.13秒(7.13〜7.88秒) 76
高画質 762.2KB 3.30秒(3.23〜3.30秒) 92(92〜93)
標準 411.8KB 1.95秒 99
高圧縮 347.6KB 1.80秒(1.80〜1.95秒) 100(99〜100)

LCP(Largest Contentful Paint)は、画面内でいちばん大きな要素が表示されるまでの時間です。このページでは、ブログ記事は本文の写真1、商品一覧は商品5の画像がLCPの対象でした。画像の転送量は、圧縮前から標準で、ブログは約79%減(772.4KB→162.2KB)、商品一覧は約80%減(2,113.1KB→411.8KB)です。

  • ブログ記事: 標準でLCPが5.10秒から1.95秒になりました(約3.2秒短縮)。
  • 商品一覧: 標準でLCPが7.13秒から1.95秒になりました(約5.2秒短縮)。画像の枚数が多く、圧縮前の容量が大きいほど、短縮の幅が大きくなりました。
  • 効果は逓減します: 標準から高圧縮へ進めても、画像の転送量は38KB(ブログ)減りましたが、LCPの短縮は0.15秒にとどまりました。画像を小さくしても、通信の往復遅延など、画像の容量とは関係ない時間(下限)があるためです。

結果2:変わらなかった指標と、差が出なかった条件

変わらなかった指標: 同じ測定で、次の指標は圧縮前後でほとんど変わりませんでした。

指標 圧縮前 標準
FCP(最初の表示までの時間、ブログ) 0.62秒 0.62秒
FCP(商品一覧) 0.62秒 0.62秒
TBT(操作できない時間)・CLS(レイアウトのずれ) 0ms・0 0ms・0

FCP(First Contentful Paint)は、最初の文字や画像が表示されるまでの時間です。このページでは、文章はHTMLの中にあり、画像の読み込みを待たずに表示されるため、画像の容量が影響しませんでした。CLSが0なのは、画像にwidth・heightを指定しているためで、画像の容量とは関係ありません。画像の圧縮が改善するのは、画像の読み込みに左右される指標(LCPなど)で、すべての指標ではありません。

ネットワークを制限しない条件では、差が出ませんでした。 同じページを、ネットワークとCPUを制限せずに測定した結果です(各5回)。

ページ 圧縮前のLCP 標準のLCP スコア
ブログ記事 34ミリ秒 29ミリ秒 どちらも100
商品一覧 30ミリ秒 28ミリ秒 どちらも100

同じマシン内の通信では、画像を受け取る時間がほとんどかからないため、圧縮の効果は測れません。つまり、画像圧縮の効果は、回線が遅いほど大きく、十分に速い回線ではほとんど表れません。

画像以外に、表示速度を左右するもの

この測定は、画像以外の要因を意図的に取り除いたページで行いました。実際のサイトでは、次のような要因も表示速度を左右します。

  • JavaScript・CSS・フォント: 読み込みや実行に時間がかかると、FCPやTBT、INPなどに影響します。
  • サーバーの応答時間・キャッシュ・CDN: 画像の容量とは別に、最初のバイトが届くまでの時間や、2回目以降の表示に影響します。
  • 広告・計測タグなどの外部スクリプト: 実際のページに追加されると、LCPや操作の反応に影響することがあります。
  • 画像の寸法: 圧縮は容量を減らしますが、画像の幅・高さは変えません。商品一覧ページの商品写真は、画面上では約184pxの大きさで表示されるのに、1200px四方の画像を使っています。Lighthouseの「画像配信」の診断では、圧縮後でも、標準で381KB分の削減余地があると指摘されました(圧縮前は1,959KB)。画像を表示サイズに合わせて小さくする(リサイズする)ことも、圧縮とは別に有効ですが、Photrimにはその機能がないため、別のツールで行う必要があります。

そのため、この記事の数値は「画像の容量が違うだけの、単純なページでの効果」であり、実際のサイトで同じだけ速くなることを示すものではありません。

この測定の限界

  • 模擬条件であり、実際のネットワークではありません。 模擬Slow 4Gは、Lighthouseのシミュレーションが回線の遅さを再現する方法です。実際の回線の速度や遅延のばらつき、端末の性能は反映されていません。
  • ばらつきがとても小さいのは、模擬条件の性質のためです。 模擬Slow 4Gの結果は、7回の最小と最大の差がごくわずかでした。これは、シミュレーションが毎回ほぼ同じ計算をするためで、実際のネットワークでの測定が同じように安定することを意味しません。実際の回線では、もっとばらつきます。
  • 1台のマシン・1日・2つのページの結果です。 実写真や、別の構成のページでは、結果が変わります。
  • 速度や検索順位の保証ではありません。 この記事は、検索順位の上昇や売上の改善を主張するものではありません。

再現する手順

次の手順で、同じ条件で測定できます(Chromeが必要です)。すべてのコマンドはbackendディレクトリで実行します。

  1. 検証ページと、圧縮前・Photrimの3段階の画像を作ります。
php scripts/speed-case-study/build.php
  1. Lighthouseを用意します(この記事の測定ではバージョン13.5.0)。リポジトリの外の、任意のディレクトリで実行してください。
npm install [email protected]
  1. 測定します(LIGHTHOUSE_BINには、手順2でインストールしたlighthouseの実行ファイルのパスを指定します。RUNSは回数、THROTTLING_METHOD=providedを付けると制限なしの測定になります)。
LIGHTHOUSE_BIN=/path/to/node_modules/.bin/lighthouse \
CHROME_PATH="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
RUNS=7 bash scripts/speed-case-study/measure.sh
  1. 結果を集計します。
php scripts/speed-case-study/aggregate.php

この記事の全ての測定値は、リポジトリのbackend/scripts/speed-case-study/results/に、1回ごとの値で保存しています。

専門用語の補足

  • LCP(Largest Contentful Paint): 画面内でいちばん大きな要素が表示されるまでの時間。ページの「主な内容が見えた」目安になります。
  • FCP(First Contentful Paint): 最初の文字や画像が表示されるまでの時間。
  • TBT(Total Blocking Time): ページの読み込み中に、操作を受け付けられない状態が続いた時間。
  • CLS(Cumulative Layout Shift): 表示中にレイアウトがずれた量。
  • Lighthouse: Googleが提供する、Webページの品質を測定するツール。

実際に圧縮してみる

ご自身のページの画像が、どのくらい軽くなるかは、画像を今すぐ圧縮するから実際に試して確認できます。標準と高画質を切り替えて、見た目と容量の変化を比べてみてください。

関連記事