【実録】LCP100秒のサイトを改善したら、犯人は画像ではなくフォントだった

「サイトが重い。たぶん画像が原因だよね」——最初はそう思っていました。

これは、僕の会社（株式会社U.ai）のサイトで実際に行った表示速度改善の記録です。

なぜ急にサイトの速度を測り始めたのか、先に背景を書いておきます。僕は切り抜き制作やコミュニティ運営などの事業を、これまで主にSNS経由で知ってもらってきました。ただ、SNSの投稿は流れて消えていくのに対し、検索は「探している人」が向こうから来てくれます。

入り口をSNSだけに依存しない体制を作るため、うちはSEO（検索経由の集客）の土台整備を始めました。その第一歩として、Googleがサイト評価に使う「表示速度」を計測したのがこの記事の始まりです。

**この記事の結論：**最初の仮説は外れました。画像を95%軽くしてもスコアはほぼ動かず、本当の犯人は画像ではなくフォントでした。同じ思い込みをしている方は多いはずなので、失敗の過程ごと公開します。

この記事で分かること：

• Lighthouseの数字をどう読み、どこから手を付けるべきか
• 「画像が重い」という仮説がなぜ外れたか（と、外れたことにどう気づいたか）
• 日本語サイト特有の「フォント問題」と、その削減方法

1. 改善前の状態

先に用語をひとつだけ。LCP（Largest Contentful Paint）とは、ページの中で最も大きな要素（メインの見出しや画像）が表示されるまでの時間のことで、Googleの基準では2.5秒以下が理想とされています。表示速度の指標の中で、体感の「遅い」に一番近い数字です。

Chrome DevToolsのLighthouseで全ページを計測したところ、次の状態でした。

理想2.5秒に対して54〜100秒は論外の数字です（Lighthouseの低速回線シミュレーション上の値で、実際の体感より誇張されますが、それでも遅い）。

ここで一つ目のポイント。全ページが同じように悪い場合、個別ページのミスではなく、サイト全体で共通の何かが原因です。共通のもの——つまり全ページで読み込む画像、フォント、CSSのどれかに犯人がいます。

2. 最初の仮説「画像が犯人」— 対策したが、外れた

サイトには2MB超のPNG写真が2枚ありました。写真をPNGで配信するのは典型的なアンチパターンなので、まずここから直しました。

• 2,073KBのPNG → 88KBのWebP
• 2,200KBのPNG → 120KBのWebP

約95%の削減です。画質はPSNR（画像の劣化を測る客観指標）で40.9〜41.2dBを確認し、拡大比較でも見分けがつかないレベルを維持しました。

ところが——再計測してもスコアはほぼ動きませんでした。転送量も19.5MB前後のまま。画像対策そのものは正しい改善でしたが、ボトルネックは別にあったのです。

3. 内訳を実測したら、真犯人はフォントだった

ここで反省しました。「合計19.7MBが重い」という情報だけで動き、内訳を測っていなかったのです。ページから参照される全アセットを取得して種類別に集計すると（数値は計測時点の概算で、ページによって多少前後します）：

犯人はフォントでした。日本語フォントは漢字数千文字を含むため、1ウェイト（太さ）あたり数MBになります。僕のサイトは明朝体とゴシック体を合わせて日本語フォントを9ウェイト読み込んでいて、これだけで19MBに達していました。

仮説が外れてから真犯人にたどり着くまでの流れです。

LCPが54〜100秒だった理由も同じです。大きな見出しのフォントが最後に届いたときの「描き直し」がLCPとして記録されるため、フォントの読み込み完了までLCPが伸びていました。

4. 対策：使っていない太さを削る

コードベース全体を調査したところ、実際に使われている太さは300・400・500の3種類だけでした。太字用の700や800は、どのページでも一度も使われていないのに読み込まれていた——つまり削っても見た目は1ピクセルも変わりません。

未使用ウェイトを削除した結果：

• フォント総量：19MB → 11.3MB
• 見た目の変化：ゼロ（使用中の太さはすべて維持）

あわせて読みたい日本語Webフォントはなぜ重いのか — 19MBを実測して分かった美しさとの付き合い方

5. 結果（Before / After）

LCPはまだ理想値には遠いですが、これは日本語Webフォントの美しさを優先する限り、Lighthouseの超低速シミュレーション上では構造的に残る数字です。実際のユーザー環境（4G/5G/光回線）では問題のない速度で表示されており、以降はGoogle Search Consoleに蓄積される実ユーザーデータで評価する方針にしました。

実測値で見る改善前後の比較です。

6. 補足：この作業はAIと一緒に進めた

正直に書くと、この改善作業の実務はほぼAI（Claude Code）にやらせています。アセット内訳の計測スクリプト作成、フォントの使用状況の全ファイル調査、WebP変換と画質検証（PSNR算出）——人間がやったのは「何を疑うか」「どの対策を採るか」の判断と最終確認だけです。手を動かす部分をAIに任せると、この規模の調査・改善が1日で終わります。僕が事業でAI活用を勧めているのは、こういう実感があるからです。

7. この改善から学んだ3つのこと

1. 内訳を測ってから直す。 「合計が重い」だけで手を打つと、今回のように正しいが的外れな対策から始めてしまう。犯人を特定してから撃つ。
2. Lighthouseのスコアは同じページでも±10点ほどブレる。 1回の点数に一喜一憂せず、複数回の計測と個別指標（LCP・転送量）で判断する。
3. 日本語サイトはフォントを疑う。 画像最適化の情報は世に溢れていますが、日本語フォントの重さ（1ウェイト数MB）は見落とされがち。未使用ウェイトの削除は、見た目を一切変えずに数MB削れる数少ない改善です。

よくある質問

WebP化で画質は落ちませんか？

適切な品質設定（うちはquality 85）なら、実用上は見分けがつきません。うちの場合、客観指標PSNRで40dB超（「人間の目では区別困難」とされる水準）を確認したうえで採用しました。

何のツールで計測すればいいですか？

Chrome DevToolsのLighthouse（無料・Chrome内蔵）で十分です。F12 → Lighthouseタブ → 計測実行。モバイル基準で測ることをおすすめします（Googleはモバイル版を基準に評価するため）。

ReactやNext.jsのサイトでも速くできますか？

できます。今回のサイトもNext.js製です。静的生成（SSG）・next/imageによる画像最適化・フォントの取捨選択を組み合わせれば、フレームワークが原因で遅いということは基本的にありません。

まとめ

• 全ページが同じように遅い＝サイト共通の原因（画像・フォント・共通コード）を疑う
• 対策の前に内訳を実測する。今回の真犯人は画像ではなくフォント（19MB）だった
• 未使用フォントウェイトの削除は「見た目を変えずに数MB削れる」確実な一手

うちでは、こうした計測に基づくサイト改善やAIを活用した業務自動化に取り組んでいます。自社サイトの診断・改善のご相談はお問い合わせからどうぞ。僕についての詳細は物語のページをどうぞ。