クラウドフレア× SWELL × WebP で LCP 良好 90% に到達した設定判断 —
はじめに
本記事では、Core Web Vitals（特に LCP）を安定させた最終設定と、
**「あえて有効にしなかった設定」**について、その理由を技術的に解説します。
結論から言うと、
速くするためにやらなかったことが、
結果的に RUM（実ユーザー指標）を最も改善しました。
公開する最終設定（スクリーンショット参照）
公開する最終設定（スクリーンショット参照） SWELL 高速化とEWWW Image Optimizer
EWWW Image Optimizer
この設定で、Search Console（CrUX）上の LCP は良好 90% に到達しています。
重要なのは
「何をONにしたか」より
**「なぜOFFにしたか」**です。
❌ チェックしなかった設定と、その理由
❌ ヘッダー・サイドバー・メニューのキャッシュ
理由：HTML構造がページごとに異なり、LCP要素がブレるため
- ページごとに
- 表示要素
- 高さ
- 読み込み順
が変わると、LCP候補が変動します。
これは Lighthouse では見えませんが、
RUMでは75パーセンタイルを確実に悪化させます。
「速い人は速いが、遅い人が増える」典型パターン
❌ トップページコンテンツの強制キャッシュ
理由：LCP画像の描画順がキャッシュ条件で変わるため
トップページは：
- メインビジュアル
- 記事一覧
- ブログカード
など、LCP候補が複数あります。
これを強制キャッシュすると：
- キャッシュヒット時
- キャッシュミス時
で LCPが別要素になる。
👉
RUMが荒れる原因になるためOFF。
❌ 内部リンクのブログカードキャッシュ
理由：ページ遷移後の描画順が不安定になるため
ブログカードは見た目以上に：
- 画像
- 外部CSS
- JS
を含みます。
内部リンクでこれをキャッシュすると：
- 遷移直後に差し込まれる
- LCP候補に割り込む
👉
「一部ユーザーだけ異常に遅い」原因になりやすい
❌ CSSのインライン読み込み
理由：初回描画は速く見えるが、RUMでは不安定になるため
インラインCSSは：
- Lighthouseでは高評価
- 初回体感は「ピカッ」
しかし実際は：
- HTML肥大化
- キャッシュ分離不可
- 条件分岐が増える
👉
遅い端末・遅い回線ほど不利
結果：
- 平均は速い
- 75%が改善しない
❌ WebP の JS リライト
理由：LCP画像に JavaScript が介入するため
JS WebP リライトは：
- LCP画像が JS 後に確定
- eager が効かない
- 1フレーム遅延が起きる
SWELL は元々：
- <picture>
- srcset
- eager 制御
が完成しているため、
JS介入は完全に蛇足。
速い人は気づかないが、遅い人が致命的に遅くなる
なぜこの「引き算設定」で LCP 90% になったのか
今回の設定思想は一貫しています。
✔ 主導権を整理した
- 表示制御 → SWELL
- 画像形式 → WebP（変換のみ）
- 配信経路 → Cloudflare（盛らない）
✔ 排除したもの
- JSによる後出し最適化
- HTMLの書き換え
- 条件分岐による描画順の差
その結果：
- CPU性能に比例した素直なLCP分布
- 異常に遅いユーザーが減少
- RUMで良好90%
Lighthouseではなく、RUMを信じる
この設定は：
Lighthouseで満点を取る設定ではない
実ユーザーで負けない設定
です。
日本ではあまり語られませんが、
海外（Web.dev / Chromeチーム周辺）では
**「最終的にRUMがすべて」**という考え方が主流です。
まとめ
- LCP改善は「足す」より「引く」
- 遅い人を消そうとすると全体が壊れる
- ヌルッと安定する挙動が完成形
- LCP 良好 90% は偶然では出ない
