表示速度の改善を仕事にしていますが、クライアントとは秘密保持契約を結んでいるので、社名を出した実績はお見せできません。ずっと引っかかっていた点でした。
それで、自分で両方作ることにしました。表示内容・写真の枚数・文章をまったく同じにして、実装だけを変えたサイトを2つ。結果はモバイルスコアが 57点 と 93点、LCP が 22.2秒 と 2.8秒でした。
どちらも公開しています。数値はご自身で計測して確かめられます。
なぜ2つ作ったのか
「表示速度を改善しました」という報告には、外から検証しにくい部分が残ります。改善後のサイトだけを見せられても、写真を減らしたんじゃないか、機能を削ったんじゃないか、という疑いが消えない。
そして実際、内容を削れば数値は簡単に良くなります。だから疑われるのは当然だと思っています。
この疑いを消すには、比較対象の側も自分で用意して、内容が同一であることを見せられる状態にするしかない。2つのデモは、写真の枚数もキャッチコピーも施工事例の件数も同じです。違うのは実装だけです。
2つの数値
| 指標 | 改善前 | 改善後 |
|---|---|---|
| モバイルスコア | 57 | 93 |
| LCP（主要素の表示） | 22.2 秒 | 2.8 秒 |
| 転送量 | 6.55 MB | 0.35 MB |
計測条件：PageSpeed Insights（モバイル）。低速4G 相当・CPU 4倍低速。2026-09-01 に5回×4セット（計20回）計測。改善後のスコアは中央値94・幅91〜96で、ここには控えめに93を載せています。同じURLを続けて投げると前回の結果が返るため、URLに使い捨てのクエリを付けて毎回測り直しています。
計測条件をいちいち書いているのは、この数値が条件で動くからです。回線も時間帯も端末も違えば、結果は変わります。あとから同じ条件で測り直せない数値は、比較の材料になりません。
1回だけ測っても分からない
改善前の5回分、生の数値です。
| 回 | スコア | FCP | LCP | CLS | 転送量 |
|---|---|---|---|---|---|
| 1回目 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
| 2回目 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
| 3回目 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
| 4回目 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
| 5回目 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
| 中央値 | 57 | 8.5 秒 | 22.2 秒 | 0 | 6.55 MB |
改善前のトップページ。同一条件で5回計測（2026-09-01）。
スコアは 56〜57 で落ち着いていますが、LCP は 1回目だけ 15.9秒 と、他の4回から6秒以上離れています。この1回目を引いて「16秒でした」と言うこともできてしまう。中央値を採るのはそのためです。
ぶれた原因は、この改善前サイトが jQuery・スライダー・Webフォントをそれぞれ別の外部サーバーから読んでいたことでした。接続先が増えるほど、名前解決と接続確立をやり直す機会も増えます。
何を変えたのか
直した箇所は3つですが、点数を動かしたのはほぼ1つです。先に書いておきます。残り2つは、やらないよりはやったほうがいい、くらいの重みでした。
メインビジュアルを原寸のまま配信していた
LCP の対象になっていたのはメインビジュアルの img。実体は原寸の JPEG でした。スマートフォンの画面幅は 400px 前後ですが、そこへ元のサイズのまま送っていたことになります。
LCP 22.2秒のほぼ全部と、転送量 6.55MB の大半がここに集中していました。他をどれだけ直しても、ここを触らない限り数値は動きません。
WebP に変換して、画面幅ごとに書き出して、先読みを指定しました。
<link rel="preload" as="image"
href="/img/mainvisual-1600.webp"
imagesrcset="/img/mainvisual-800.webp 800w,
/img/mainvisual-1600.webp 1600w,
/img/mainvisual-2400.webp 2400w"
imagesizes="100vw"
fetchpriority="high">
<!-- loading="lazy" は付けない。ファーストビューの画像に付けると逆に遅れる -->jQuery とスライダーを表示より先に読んでいた
jQuery と Splide が、defer も async も付かずに head に置かれていました。この2つを読んで実行し終えるまで、ブラウザは表示の処理を止めます。計測中、156ミリ秒と73ミリ秒の長時間タスクが毎回出ていました。
<!-- 改善前。head で同期読み込み -->
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/@splidejs/splide@4.1.4/dist/js/splide.min.js"></script>
<!-- 改善後。defer を付け、jQuery 依存をやめて自前の 3KB に置き換えた -->
<script src="/js/demo-fast.js" defer></script>部品を3つの外部サーバーから取り寄せていた
jQuery を code.jquery.com、スライダーを cdn.jsdelivr.net、Webフォントを fonts.googleapis.com から。3つとも別のサーバーです。自前で持てるものは自前に寄せ、残りには preconnect を置きました。
内容を減らして軽くしたわけではない
ここが今回いちばん書きたかったところです。2つのデモは、表示される内容が同一です。写真は同じ枚数、文章も同じ、施工事例の件数もスライダーの動きも同じ。
ただ、作っている途中で気になることがありました。改善後のほうが、写真が粗く見える箇所があったんです。
調べてみたら、原因は思っていたのと逆でした。改善後のほうが、実際に解像度不足だったのです。メインビジュアルは画面幅いっぱいに出るので、必要な画素数は「表示幅 × 端末のピクセル比」で決まります。DPR 2 の端末だと 2765px。ところが当初の srcset の最大候補は 1600px しかなく、0.58倍しかない画像を 1.7倍に引き伸ばして表示していました。やっかいなのは、転送量の数字だけを見ていると、これがまったく見つからないことです。候補を削れば削るほど数値は良くなるので、むしろうまくいっているように見える。2400px の候補を足して解消しました。
重要
「軽くする」と「解像度を落とす」は別の作業です。見た目を変えないという約束を守るなら、srcset の上限候補は必要な実寸から決めるしかありません。転送量だけを見て候補を削ると、画質が落ちたことに気づかないまま納品することになります。
ご自身で確かめられます
2つのデモはどちらも公開しています。改善前のデモと改善後のデモの URL を PageSpeed Insights に入れれば、この記事の数値が再現できるか確認できます。
数値は回線と時間帯で動くので、記事の値と小数点まで揃うことはありません。見ていただきたいのは、2つの差がどれくらいの大きさで出るか、のほうです。