【実測】Cloudflare × SWELL × WebP で LCP 90% 良好に到達したが、最初は「失敗した」と感じた話

2026年1月31日

結論を先に

Lighthouse や PageSpeed のスコアは 信用しない

RUM（CrUX / GSC）で LCP 良好 90% は、
構成が正しいときにしか出ない
Cloudflare・WebP・高機能テーマは
「主導権」を整理しないと必ず地雷を踏む

背景

WordPress（テーマ：SWELL）で運用中のサイトに対し、
Core Web Vitals（特に LCP）の安定化を目的として Cloudflare を導入。

導入前から：

Lighthouse：ほぼ 90〜100
体感：十分速い
しかし RUMでは LCP が不安定 最速0.4　ばらばら

という状態だった。

Cloudflare 導入直後に起きた「違和感」

現象

高性能PC・良回線
→ LCP 0.5〜0.8 秒（爆速）最終0.3
しかし
→ 一部ユーザーで異常に遅い（4〜6秒）

結果：

LCP 良好率が伸びない
むしろ 「遅い人が増えた」感覚

この時点で
「これは嫌なパターンだ」と感じた。

なぜ Cloudflare で「遅い人」が増えるのか（推測ではなく構造）

Cloudflare は 平均を速くする CDN であり、

DNS
TLS
PoP 自動選択
キャッシュヒット前提

という仕組み上、

もともと遅い環境のユーザーほど
“初回オーバーヘッド”をフルで食らう

導入初期は特に：

キャッシュ未温存
PoP 選択の揺れ
初回 TLS

が重なり、
RUMでは「異常値」が顕在化する。

WebP × SWELL の地雷

WebP × SWELL の地雷

ここでさらに問題だったのが WebP。

SWELL は元々：

<picture> 構造
srcset / sizes
eager / lazy 制御
LCP画像の優先描画

を テーマ側で完成させている。

しかし WebP プラグイン側で：

HTML 書き換え
JS リライト
強制 lazy
picture 再構築

が入ると、LCP 画像の描画経路が壊れる

LCP 画像の描画経路が壊れる

👉 LCP 画像の描画経路が壊れる

結果：

速い人：さらに速い
遅い人：異常に遅い
Core Web Vitals：不安定

「ピカッ」から「ヌルッ」へ（体感の変化）

「ピカッ」から「ヌルッ」へ（体感の変化）

設定を整理し、

WebP：形式変換のみ
表示制御：SWELL に完全委任
Cloudflare：盛らない

に戻した直後、体感は：

変更前：ピカッ（瞬間最大風速）
変更後：ヌルッ（安定描画）

正直、最初は
「失敗したかも」と感じた。

しかし RUM が語った真実

数日後の Search Console（CrUX）：

LCP 良好：90%
要改善：8%
悪い：3%

これは
今まで一度も見たことのない数値だった。

さらに実測：

Ryzen 1700：LCP 0.6 秒前後
i5-4460：1.0 秒前後
i5-6300U（古ノート）：1.5 秒前後

👉 CPU性能に比例した極めて素直な分布

＝
構成が正しいときの挙動

なぜ「ヌルッ」が正解なのか

Core Web Vitals が評価するのは：

瞬間最大風速ではない
派手さでもない
75パーセンタイルの安定性

「ピカッ」は記憶に残るが、
「ヌルッ」は 何も起きない。

しかし UX と SEO にとっては
何も起きないことが最強。

技術的結論（ガチ）　SWELLの高速化+Webp+クロードフレア　設定

1️⃣ WebP は「変換だけ」

HTML 書き換え禁止
JS 介入禁止
表示制御はテーマに任せる

2️⃣ CDN は盛らない

初期は特に触らない
異常値が出ても 削らない

3️⃣ Lighthouse を捨てる

見るのは RUM
見るのは分布
見るのは 75%

4️⃣ 遅い人を“消そう”としない

その人たちは必ず存在する
消そうとすると 全体が壊れる

日本ではなぜ語られていないか（海外のネットを参照しました。）

日本ではなぜ語られていないか

Lighthouse 信仰が強い
RUM の読み方が共有されていない
「速く見せる」話ばかりで
「遅い人を増やさない」視点がない

これは
海外（Web.dev / Chrome チーム寄り）の思想に近い。

まとめ

LCP 良好 90% は偶然では出ない
正解は「やらないこと」
体感とデータがズレたら データを信じる
「ヌルッ」は完成のサイン