静的サイトでLiteSpeed Cache時代に匹敵する速さを取り戻した話

WordPress をやめて静的サイトにすれば、勝手に速くなる。俺もそう思っていました。

前回の記事（WordPress から静的サイトへ移した記録）で、mlabo.org を見た目も URL も変えずに Cloudflare の静的サイトへ移しました。サーバーで PHP を動かさず、出来上がった HTML を配るだけ。速くならないわけがない。

ところが、移した直後に PageSpeed Insights（以下 PSI）で測ったら 67点。オレンジでした。

WordPress（SWELL）に LiteSpeed Cache を載せていたロリポップ時代は、スマホでも 4 項目すべて 100 点が出ていたのにです。この記事は、そこから LiteSpeed Cache 時代に匹敵する点数 まで戻した記録です。やったことを一言で言うと、静的ファイルと遅延読み込みを正しく使っただけ。途中で、画像やフォントが増えて Cloudflare Pages の上限が見えてきたので、配信先を Workers に止めずに移しています。

あなたが WordPress をキャッシュ系プラグインで速くしてきて、静的サイトへの移行を考えているなら、「静的にすると何が消えるのか」と「それをどう組み直すか」の順番が分かるように書きます。作業の大半は Claude（Claude Code）に頼み、判断と最後の確認は俺がしています。

静的サイトにしたのに67点だった

静的サイトは、サーバーがその場でページを組み立てません。だから最初の 1 バイトが返ってくるまでは確かに速い。でも PSI の点数は、それだけでは決まりません。ページを開いてから、何がどの順番で読まれ、いつ画面に出て、いつ操作できるようになるか。点数を決めているのはそこです。

LiteSpeed Cache 時代は全部100点だった

比べる相手ははっきりしています。俺が前に書いた LiteSpeed Cache＋Cloudflare の記事 に、当時のトップページ（スマホ）の結果が残っていました。

項目	LiteSpeed Cache 時代（トップ、スマホ）
パフォーマンス	100
ユーザー補助	100
おすすめの方法	100
SEO	100
FCP（最初に何か出るまで）	1.2秒
LCP（最大の画像や文字が出るまで）	1.7秒
TBT（操作できない時間の合計）	0ミリ秒

これを Claude に見せて、目標を伝えました。

そして、静的にした直後の現実です。

その調整の途中、10月26日の本番の記事ページ（スマホ、1回）は、パフォーマンス 90、ユーザー補助 86、おすすめの方法 100、SEO 92 でした。速さだけでなく、ユーザー補助と SEO も落ちていたんです。指摘されていたのは、画像に alt（説明文）がない、iframe に title がない、名前のないリンクがある、文字と背景のコントラストが足りない、の 4 つでした。

Claude は最初、元の記事の「モバイル：75〜100点」という一文を読んで、スマホの 100 点は良いときの値だったんでしょう、と言いました。これは訂正しておきます。

たまたまではないぞ。大事なことなので、記事でももう一回言っておきます。

合格は「何回測っても90以上」

とはいえ、いきなり 100 点を必須にするのは無茶です。そこで線を引きました。

4 項目とも、何回測っても 90 点以上が合格。100 点が目標。合否は、何回か測った中の一番低い点で決めます。この基準が、後のすべての判断のものさしになりました。

PSI は1回では信じない

最低値で見るのには理由があります。PSI は、同じページでも回によって大きくぶれるんです。

10月24日に画像のキャッシュ設定を直したあと、3 回続けて測ったら 59点、94点、93点。59 点の回も、実際の通信の時間はほかの回とほぼ同じで、Lighthouse（PSI の中で動いている計測の道具）の見積もりだけが大きく違っていました。1 回だけ測って「上がった」「下がった」と喜ぶのは、サイコロを 1 回振って当たりの目を決めるようなものです。

そこで、この記事の数字は次のように取っています。

• 手元で、変更前と変更後のサイトを別々に作り、それぞれ手元の Cloudflare の環境で動かす
• 測るページだけ「mlabo.org のときだけ広告と解析を読む」条件を外して、GA や広告も本番と同じに読ませる
• Lighthouse（12.8.2、スマホ）で、変更前と変更後を 交互に 5 回ずつ 測り、中央値と最低〜最高を並べる
• 本番は PSI の画面で、ページごとに 3 回

交互に測るのは、回線やパソコンの調子のぶれが片方だけに乗らないようにするためです。これで「差がある」と言えるのは、両方の幅が重ならないときだけになります。

LiteSpeed Cacheが裏でやっていたことを掘り起こす

67 点と 100 点の差はどこから来たのか。サーバーの速さではありません。静的サイトのほうが、HTML を返すまでは速いくらいです。

答えは、移行前に保存しておいた当時のページの記録にありました。WordPress を止める前に、公開中のページをまるごと保存してあったんです。

24本の JS が読者の操作を待っていた

保存してあった記事ページの HTML を Claude に調べてもらうと、type="litespeed/javascript" という見慣れない書き方のスクリプトが、1 ページに 24 個 ありました。

中身は、GA（Google アナリティクス）、AdSense、ブログ村、Pinterest、ValueCommerce。外部のスクリプトがほぼ全部です。LiteSpeed Cache の「JS の遅延読み込み」は、これらを普通の <script> ではなくブラウザが実行しない形に書き換えておき、読者が最初に操作するまで（マウスを動かす、スクロールする、タップする）動かさない 仕組みでした。

PSI はページを開くだけで、マウスもスクロールも使いません。だから測定中、重い外部スクリプトはほぼ一本も動かない。TBT 0 ミリ秒、パフォーマンス 100 点の主な理由はこれだったわけです。

アイキャッチまで最初は透明な画像だった

「画像出してないような動き」。この記憶も当たっていました。

同じページの <img> は 80 個。そのうち 48 個は、本物の画像の場所を data-src という別の欄に入れ、表示する場所（src）には透明な小さい PNG を入れてありました。記事のいちばん上のアイキャッチもです。画像最適化プラグインの EWWW と LiteSpeed Cache の組み合わせで、本物の画像は JS が後から差し替えていました。

PSI の LCP は、中身のほとんどない画像を数えません。アイキャッチが透明なダミーなら、いちばん大きい要素は見出しの文字になる。以前の LCP 1.7 秒が速かったのは、これで説明がつきます。

まとめると、以前の 100 点はこうして出ていました。

1. 外部のスクリプトは、ほぼ全部を最初の操作まで動かさない
2. 画像は、アイキャッチも含めて最初は透明なダミー
3. CSS は LiteSpeed Cache がまとめた 1 つのファイル

静的サイトにすると、このプラグインの仕事がまるごと消えます。67 点は、消えた仕事の分の点数でした。

ちなみに LiteSpeed Cache の書き換えは、移行の作業中にも一度顔を出しています。JS の読み込み完了のイベント名まで独自の名前に書き換えていて、取り込んだ JS をそのまま使ったら目次が空になったんです。元の名前に戻して直しました。それくらい、裏で HTML と JS を書き換えるプラグインだったということです。

「GA は遅らせない」が記録で覆った

ここで、話がひっくり返ります。

実は前日、Claude は「GA を操作のあとまで遅らせると、ページを読んだだけで帰った訪問が記録されなくなるので、やらない」と判断していました。もっともらしい理屈です。でも記録を見たら、以前のサイトがもともとそうだった。

以前と同じ動きに戻すだけなら、新しく失うものはありません。

LiteSpeed Cache の設定画面で入れていた「JS を遅らせる」「画像を遅らせる」のスイッチ。静的サイトでは、そのスイッチの中身を、自分のページの作り方に最初から書き込んでおけばいい。方針はこれで決まりました。

外部のJSは読者が触るまで動かさない

まず 1 つ目の「外部のスクリプトを最初の操作まで動かさない」を作り直します。静的サイトでは、プラグインが後から書き換えてくれません。ページを作る段階で、最初からそう書いておきます。

最初の操作まで待つ20行の仕掛け

作ったのは、ページの head に置く 20 行ほどの JS です。mlaboOnFirstUse という小さな関数で、やっていることは単純です。

• mouseover、click、keydown、wheel、touchmove、touchstart、pointerup、pointerdown のどれかが最初に起きるのを待つ
• 起きたら待つのをやめて、ためておいた読み込みを順に実行する
• 時間切れはなし（何秒たったら勝手に読む、ということはしない）

この関数に、GA、AdSense、同意メッセージ、Clarity、ValueCommerce、ブログ村、Pinterest の読み込みを預けました。イベントの種類は、LiteSpeed Cache が待っていたものに合わせています。お店にたとえると、開店した瞬間に説明係を全員呼ぶのをやめて、お客さんが商品に手を伸ばしたら呼ぶ、という形です。

preconnect は外した

もう 1 つ、外したものがあります。preconnect です。

preconnect は「この相手とは後で通信するから、先に接続を始めておいて」とブラウザに伝える指定で、速くするつもりで、ブログ村と ValueCommerce の接続先 4 つに付けていました。ところが Cloudflare Pages は、これをページの返事にも自動で書き足していたんです。その話を Claude から聞いたとき、思わず言いました。

PSI は毎回「4 つ以上の preconnect 接続が見つかりました」と警告していました。どれも最初の表示に欠かせない相手ではありません。早くつなぐと、CSS や画像と回線を取り合うだけです。

preconnect 4 つは消して、ブログ村と ValueCommerce は、ほかの外部スクリプトと一緒に最初の操作のあとへ回しました。

広告もポチップも壊れていないか確かめる

遅らせて広告が出なくなったり、商品リンクが壊れたりしたら意味がありません。手元で Claude に確かめてもらったのは次のとおりです。

• 操作する前は、広告バナーの画像以外の外部との通信がない
• スクロールしたあとに、GA の送信、AdSense の 2 枠、Clarity、ブログ村の枠、ValueCommerce、Pinterest が動く
• 商品紹介の箱（ポチップ）のボタン 9 個が、変更前と同じに出る。Yahoo のリンクは変更前と同じく ValueCommerce の送客リンクに置き換わる

ついでに、ユーザー補助の指摘も片付けました。記事の下やサイドバーにある広告の箱のバナー（SWELL、ロリポップレンタルサーバーなど）と、本文に出る広告の箱 10 件のバナーに alt を付け、計測用の 1 ピクセルの画像には空の alt を入れました。作り直したサイトで、広告の箱に alt のない画像は 0 件です。

TBT は0になったが、性能の点は動かなかった

さて、結果です。交互に 5 回ずつ、中央値（最低〜最高）、変更前 → 変更後。

ページ	性能	ユーザー補助	おすすめの方法	SEO	TBT
トップ	96（96〜96）→ 96（94〜97）	100 → 100	57 → 96	100 → 100	73 → 0ms
記事 14292	94（91〜97）→ 93（92〜99）	85 → 96	57 → 75	92 → 100	71 → 0ms
記事 14099	82（77〜90）→ 83（80〜90）	86 → 97	57 → 75	92 → 100	197 → 59ms
カテゴリ一覧	94（92〜97）→ 93（92〜97）	96 → 100	57 → 96	100 → 100	49 → 0ms

TBT はほぼ 0 になりました。ユーザー補助、おすすめの方法、SEO も上がっています。

ところが、肝心の 性能の点は差なし でした。変化は、毎回のぶれの範囲に収まっています。

そのとおりで、性能の点を決めていたのは LCP、つまり最大の画像がいつ出るかでした。特に記事 14099 は、性能の最低が 80 で、合格ラインの 90 に届きません。止めていたのはアイキャッチで、出るまでに 3.6〜4.5 秒かかっていました。

JS を遅らせただけでは、LiteSpeed Cache の 100 点の半分しか取り戻せない。残りの半分は画像です。

画像とフォントは必要なときに必要な大きさで

ここで、LiteSpeed Cache の 2 つ目の手、「画像を最初は透明なダミーにする」を真似る手もありました。でも、それは最後の手段に取っておきました。点数は確実に上がりますが、読者から見るとアイキャッチが少し遅れて出る仕組みです。先に、画像そのものを軽くして、読む順番を整えることにしました。

見た目はSWELLのまま、読み方だけ変える

実はこちらは、JS の遅延より前に手を付けていました。CSS の読み方を変えてよいかを聞かれたとき、俺はこう答えています。

見た目（SWELL の HTML の構造とクラス名）は引き継ぐ。でも、CSS や画像をどう読むかまで元と同じにする必要はない。この線引きで、次のことを入れました。

• ページごとに、そのページで使う CSS の規則だけを HTML に直接書き込み、CSS ファイル本体は表示を止めずに後から読む
• アイキャッチには「最優先で読んで」という指定（fetchpriority="high"）を付ける
• 本文の画像、スマホのメニュー、サイドバーのプロフィール画像は loading="lazy"（画面に近づいてから読む）にする

それまで記事ページでは、本文の H2 の大きな画像（1536px）が全部先に読まれて、肝心のアイキャッチが後回しになっていました。並べ直した結果がこちらです（交互に 5 回ずつの中央値）。

• トップ：94 → 97
• 記事 14292：80 → 97（最大の画像が出るまで 5.1 → 2.4 秒）
• 記事 14099：73 → 88（10.1 → 3.7 秒）

ページに書き込んだ CSS だけで表示した版を変更前と画面で比べ、目次などに違いがないことも確かめています。

画面に合った大きさの画像を配る

次は画像の大きさです。トップの記事カードは、表示が数百ピクセルなのに、もっと大きい JPEG を読んでいました。

カードの画像は WebP の縮小版にして、幅を 400／600／700／800／900 の 5 種類用意しました。ブラウザが画面に合った幅を選べるように、srcset（候補の一覧）と sizes（実際に表示する幅）を書きます。たとえばある記事のカード画像は、800px の JPEG で 85KB だったのが、700px の WebP で 30KB になりました。

本文の画像（約 1,665 枚）にも同じく WebP の縮小版を作り、sizes は mlabo.org で実際に測った本文の幅に合わせています。スマホは画面の幅から 30px 引いた値、パソコンは最大 812px です。縮小版は一度作ればキャッシュに残るので、次からのビルドは数秒で終わります。

ただし、副作用がありました。配るファイルが、約 6,000 から約 13,400 に増えたんです。これが次の章の Workers 移行につながります。

lazy を足しても動かなかった回

記事 14099 では、本文の YouTube の埋め込み（iframe）と、記事下の広告のバナーが、最初からアイキャッチと回線を取り合っていました。そこで、本文の iframe（サイト全体で 37 か所）に、ビルドのときに loading="lazy" を自動で付けるようにしました。記事下とサイドバーの広告画像 8 枚も lazy にしています。

結果、記事 14099 の性能は 91（82〜93）→ 90（89〜96）。差なし です。おすすめの方法は 75 → 96 に上がりましたが、これは計測中に、http で書かれた広告画像と第三者の Cookie が読まれなくなったからでした。

5 回ずつ交互に測っているから、こういう「効いたように見えるけど言い切れない」回を、そのまま記録に残せます。効かなかったことも分かるのが、測って決めるいいところです。

80pxのアイコンに75KB、フォントはTTF

では、14099 で最初に何が読まれているのか。並べてみたら、犯人はアイキャッチの隣にいました。

• 吹き出しのアイコン 2 枚：表示は 80px なのに、元の画像のまま 75KB と 84KB
• 文字のフォント（Quicksand）：TTF 形式で、1 本 78KB

吹き出しのアイコンには 160px と 240px の WebP 版を作り、sizes="80px" で出すようにしました。74KB だったものが 5KB／9KB に、83KB だったものが 6KB／10KB になります。フォントは TTF から、圧縮の効く WOFF2 に変換しました（1 本約 30KB）。変換の前と後で、収録されている文字が同じことも確かめています。

ページ	性能（変更前 → 変更後）
記事 14099	90（89〜90）→ 92（92〜97）、LCP 3.54 → 3.23 秒
記事 14292	94（94〜96）→ 96（96〜97）
カテゴリ一覧	93（92〜96）→ 95（93〜98）
トップ	95（94〜98）→ 94（94〜96）

今度は 14099 の範囲が重なりません。はっきり速くなりました。アイキャッチと同時に読まれていたアイコンとフォントが、約 250KB から約 80KB に減ったからです。手元では、4 ページすべてが最低 92 以上になりました。

そして、ここが地味にうれしいところです。最後の手段に取っておいた「アイキャッチを最初は透明なダミーにする」は、使わずに済みました。LCP の計測をごまかす手を使わずに、本物の画像で 90 を超えられたわけです。

ファイルが増えたのでPagesからWorkersへ止めずに移した

画像の縮小版を作ったおかげで、配るファイルは約 13,500 になりました。ここで Cloudflare Pages の上限が見えてきます。

2万ファイルの壁と、Proの25ドル

Cloudflare の公式の制限表を Claude に調べてもらうと、こうでした（2026年10月26日時点）。

• Pages：無料で 1 サイト 2 万ファイルまで。10 万にするには、ドメインを Pro（月 25 ドル）にする
• Workers の静的ファイル配信：無料で 1 つの Worker に 2 万ファイルまで。Workers Paid（月 5 ドル）で 10 万
• 静的ファイルの配信そのものは、どちらも無料で回数の制限なし

この話、Claude の返事の後ろのほうに、さらっと書いてあったんですよ。

何だよ、こっちの方がいいじゃんか。移すだけなら無料のまま。2 万に近づいたら月 5 ドルにすればいい。

Pro の 25 ドルには、実は別の話でも一度ぶつかっていました。俺の家の固定回線（NTT の OCN）から mlabo.org を開くと、Cloudflare の日本の拠点ではなく、米国西海岸の拠点で受けられていたんです。接続だけで 0.12 秒ほど。同じ回線で www.cloudflare.com は大阪の拠点で 0.02 秒前後でした。スマホの 4G から開くと、mlabo.org も日本の拠点でした。これは俺の回線で確かめた範囲の話で、ほかの回線の読者にどう届いているかは分かっていません。Pro にすると日本の拠点になる、という公式の保証も見つかりませんでした。うちの読者はパソコンからの人がほとんどなので、Pro を 1 か月試す方向で、切り替えの画面まで開いたんですが……。

保留です。お金で速さを買うのは、作りで取り戻せる速さを全部詰めてからでいい。結果的に、それで正解でした。

Pagesと同じ動きにそろえる

Workers に移すといっても、検索エンジンから見た動きが変わっては困ります。Pages が黙ってやってくれていたことを、Workers の設定で書き出しました。

• ない URL には 404 のページを返す（not_found_handling: "404-page"）
• /14292 のような末尾の / がない URL を、/14292/ にそろえる（html_handling: "auto-trailing-slash"）
• お問い合わせや検索など、プログラムが答える道（/、/contact、/search/*、/page/*）だけ Worker を動かし、ほかは Worker を通さずにファイルを配る
• お問い合わせのプログラムは、Pages 用に書いていたものをそのまま 1 つの Worker にまとめる

そのうえで、Pages 版と Workers 版の両方に、同じ 54 通りの要求を送って比べてもらいました。ページ、古い URL の転送、検索、お問い合わせ、フィード、キャッシュの指定などです。

違いは少しだけ出ました。いちばん大きいのは、末尾 / なしの転送が、Workers では 307 になること。Pages は 308 でした。どちらも「こっちへ移動して」という返事ですが、308 は「ずっと移動した」、307 は「今だけ移動した」という意味になります。Workers の静的ファイル配信では、この 307 は変えられません。

そこで、Cloudflare のゾーン（ドメイン全体）の転送ルールを 1 つ足しました。末尾が / でなく、. を含まない URL を、/ を付けた URL へ 308 で転送するルールです。クエリ（? の後ろ）も残します。これで、検索エンジンから見た返事は Pages のときと同じになりました。

routeで切り替えれば止まらない

最後に切り替えです。Worker を mlabo.org に付ける方法は 2 つあります。

1. Worker のカスタムドメインにする：先に Pages から mlabo.org を外して DNS の設定を消す必要があり、その間はつながらない
2. Worker の route（mlabo.org/* に来た要求をこの Worker で受ける、という指定）を足す

選んだのは 2 です。Worker の route は、同じホスト名の Pages のカスタムドメインより先に動きます。だから DNS にも Pages にも触らず、route を足した瞬間に Workers が答え始める。引っ越しで、住所はそのままに郵便の転送先だけを切り替えるようなものです。戻すときは route を外すだけで、Pages がまた答えます。Pages のプロジェクトは、その戻し道として残してあります。

手順は、Claude が 1 段階ずつ確認を取りながら進めました。設定を Workers 向けに変える、route なしで Worker を一度出す（どこからも見えない）、お問い合わせのスパム対策の秘密の鍵を Worker に入れる（これは俺が自分で貼りました）、308 の転送ルールを足す、最後に route を足して出す。

2026年10月27日の朝 6 時に切り替わり、つながらない時間はありませんでした。切り替えたあとに、トップ、記事、カテゴリ、フィード、サイトマップ、古い URL の転送、検索が今までどおり返ることと、ない URL の 404 の返事が Workers のものに変わったこと（Worker が答えている印）を確かめています。

LiteSpeed Cache時代に匹敵し、最適化は今のほうがやりやすい

外部 JS の遅延、アイコンとフォントの軽量化、lazy の追加を本番に出したのは、Workers に切り替える少し前、10月27日の朝 5 時半ごろです。Claude が PSI を測っている最中に、俺は本番を開いて、思わず送っていました。

点数より先に、体が分かった瞬間でした。

本番のPSIは4ページとも90以上

本番の PSI（スマホ、ページごとに 3 回）です。

ページ	性能	ユーザー補助	おすすめの方法	SEO
トップ	98・95・95	100	100	100
記事 14292	97・93・95	97	100	100
記事 14099	93・94・96	97	100	100
カテゴリ一覧	94・94・95	100	100	100

FCP は 1.8〜2.0 秒、LCP は 2.1〜3.0 秒、TBT は 0〜30 ミリ秒、CLS は 0。4 ページ × 3 回、すべての項目が 90 以上で、いちばん低いのは性能の 93 でした。前日の記事 14292（90／86／100／92）から、4 項目すべてが上がっています。

合格ラインの「何回測っても 4 項目とも 90 以上」は、満たしました。

では、これをどう言うか。点数だけ見れば、以前の 100 点にはまだ数点届いていません。だから「WordPress より点数が上がった」とは書けない。そう言ったら、こう返されました。

そう、匹敵です。LiteSpeed Cache で固めていたロリポップ時代と、点数では数点の差、体感では今のほうが速い。盛らずに言うなら、これがいちばん正確です。あなたが自分で mlabo.org を PSI で測っても、この言い方とは食い違わないはずです。

まさにそれです。静的ファイルで、ページを組み立てる時間をなくす。遅延読み込みで、読者が触れる前に要らないものを後ろへ回す。どちらも新しい技術ではありません。LiteSpeed Cache がやっていたことを、正しい順番で組み直しただけです。

まだ届いていないところ

正直に残しておきます。

• 100 点にはまだ届いていない。 以前の LiteSpeed Cache 時代は FCP 1.2 秒、LCP 1.7 秒でした。今は FCP が 1.8 秒より下がりません。理由はまだ調べていません。
• 以前の 100 点の記録はトップページの値で、当時の記事ページの点数は残っていません。
• 解析は、以前と同じく、操作しないまま帰った訪問は記録されません。以前の運用で困っていなかったので受け入れていますが、影響の大きさを数字で比べたわけではありません。

FCP の 1.8 秒の壁は、次の宿題です。

スイッチを探すより、数行足して確かめるほうが早い

最後に、この作業を通して一番感じたことです。

WordPress 時代、ページはテーマとプラグインが組み立て、遅延や圧縮は LiteSpeed Cache が後から書き換えていました。どこで何が変わったのかは見えにくく、設定同士がぶつかったら、スイッチを切り替えて PSI を測り直すしかない。目次が空になったイベント名の書き換えも、記録を掘るまでは誰も気づいていませんでした。

今は、HTML を作っているのは自分のビルドの道具（Rust で書いた mlabo-site）です。loading="lazy" を足すのも、JS を最初の操作まで遅らせるのも、ソースの数行。出来上がった HTML を見ればそのまま確かめられて、変更の前と後を交互に測って比べられる。効かなければ、その数行を戻すだけです。

そしてもう 1 つ。作業の途中で、俺はこう聞いていました。

答えは、そのとおりです。最適化はビルドの道具とテーマのファイルに入っていて、編集用の WordPress から新しい記事を公開するボタンも、同じ道具を通ります。この記事も、公開した瞬間から、外部 JS の遅延も画像の縮小版も WOFF2 のフォントも全部入った状態で配られます。プラグインのスイッチの中身を、自分の手元に移した。速くなったのは結果で、本当に手に入れたのは、速くし続けられる作りのほうでした。

あなたが静的サイトへの移行で点数が落ちて困っているなら、まず以前のキャッシュプラグインが何を書き換えていたかを、保存したページで確かめてみてください。消えた仕事が分かれば、組み直す順番は自然に決まります。