先に数字を出す。エックスサーバーで動かしているCocoonのブログを、モバイルのPageSpeed Insightsで60から96まで上げた。使ったのは自作のキャッシュプラグイン、Prime Cache一本だ。ただ、上がり方には偏りがあって、劇的に効いた指標もあれば、何をしても動かなかった指標もある。この記事は、その内訳の話をする。何を入れたら何点になった、という結果だけでなく、どの設定がどの指標を動かして、どこで頭打ちになったのか。そこまで踏み込む。
夜中の2時すぎ、計測を回しながらメモを取っていた。同じサイトを設定だけ変えて三通り測る。素の状態、無料版で自動設定にしただけの状態、有料版で手を入れた状態。数字が出るたびに、どこが動いてどこが動かないかがはっきりしてきて、面白くて手が止まらなくなった。その晩わかったことを、順番に並べていく。
計測した環境
まず前提を書いておく。ここがずれると数字の意味も変わるので。
- サーバー: エックスサーバー（共用プラン）
- テーマ: Cocoon
- 計測: PageSpeed Insights、モバイル
- 対象: 記事が並ぶ実運用のブログ
- 計測日: 2026年7月18日（60）、7月20日（82）、8月4日（96）
端末エミュレーションは3回とも同じで、Moto G Power、低速4Gのスロットリング。ただしLighthouseのバージョンは最初の2回が13.4.0、最後の1回が13.4.1で、そこにぶら下がるChromeも149と150に分かれている。厳密に同一条件の比較ではない点は、先に断っておく。
PageSpeed Insightsのモバイルは、低速回線と非力な端末をエミュレートして測る。つまり、そこそこのスマホで4G回線、くらいの厳しい条件で採点される。デスクトップだと90台が普通に出るサイトでも、モバイルだと60前後に沈むのはよくある話で、今回の素の状態がまさにそれだった。
キャッシュが効いていない状態は60だった
キャッシュを効かせていない状態で、スコアは60。内訳を見ると、犯人ははっきりしていた。
出発点。低速4G・Moto G Powerのエミュレーションで、LCPが14.8秒。
LCPが14.8秒。これはページの主要な部分が表示されるまでの時間で、14.8秒というのは、はっきり言って遅い。読者は待たない。Speed Indexが6.0秒。これは表示の埋まっていく速さの指標だ。この二つが大きく足を引っ張って、60まで落ちていた。
共用サーバーのWordPressで、キャッシュを何も入れていないと、リクエストのたびにPHPが動いてデータベースを引いてHTMLを組み立てる。その一連が、非力な端末・遅い回線という条件で増幅されて、LCP14.8秒という数字になる。ここに手を入れる余地しかない、という状態だった。
無料版を入れて、自動設定を押しただけで82
Prime Cacheを有効化して、Autoプリセットを押した。設定はそれだけ。個別の項目は一切触っていない。
スコアは82になった。60から82。プラス22を、ボタンひとつで得たことになる。
無料版に自動設定を当てただけ。Total Blocking Timeはこの時点で0ミリ秒になっている。
内訳の変化が興味深い。
- LCP: 14.8秒 → 4.4秒
- Speed Index: 6.0秒 → 3.9秒
- TBT: 70ms → 0ms
LCPが14.8秒から4.4秒へ、三分の一以下に落ちた。ページキャッシュが効いて、PHPとデータベースの往復が消えた分がそのまま出ている。静的なHTMLを返すだけになれば、共用サーバーでもここまで速くなる。
なぜここまで落ちるのか、少し仕組みを書いておく。キャッシュが無いWordPressは、アクセスのたびにPHPを起動し、データベースに何度も問い合わせ、テーマのテンプレートを評価してHTMLを組み立てる。共用サーバーはCPUもメモリも他のユーザーと分け合っているので、この処理が混雑時にいっそう遅れる。ページキャッシュは、一度組み立てたHTMLをファイルに保存して、次からはそれを返す。組み立ての工程がまるごと消えるから、非力な端末・遅い回線という不利な計測条件でも、LCPがここまで縮む。共用サーバーだからこそ、キャッシュの効き幅が大きい、とも言える。
そしてTBTが70msから0msになった。TBTはメインスレッドが操作をブロックする時間で、これがゼロというのは、読み込み中に操作を邪魔するJavaScriptの詰まりが無くなったということだ。ここで一つ、意外だったことがある。TBTは、この時点で、つまり無料版の自動設定だけで、すでにゼロになっていた。あとから有料版で何をしても、これ以上良くはならない。ゼロが下限だからだ。
Autoプリセットが何をしているかというと、ページキャッシュ、Gzip、ブラウザキャッシュ、HTML/CSS/JSの圧縮、画像のWebP化、遅延読み込みあたりを一括で有効にする。難しい判断は要らない。押すだけで82まで来る。共用サーバーで手軽に、というならここで十分かもしれない、とも思う。
有料版で手を入れて96。でも一直線ではなかった
ここから有料版に切り替えて、手動でチューニングした。最終的にスコアは96。82から96、プラス14を積んだ。
96。オレンジで残っているのはSpeed Indexだけで、数字は82のときと同じ3.9秒。なおSEOの69は検証用サイトをnoindexにしているためで、公開サイトの設定ではない。
ただ、この14は素直な積み上げではなかった。手を入れた項目と、実際に動いた指標を突き合わせると、噛み合っていない部分がある。
LCPは効いた。4.4秒から2.4秒へ。ここは有料版の機能がはっきり仕事をした。Critical CSSや未使用CSSの削除、オブジェクトキャッシュといった、無料版には無い攻めた最適化が、表示の主要部分をもう一段前倒しした。96まで来た原動力は、ほぼこのLCPの改善だ。
問題はSpeed Indexだった。3.9秒から、3.9秒。表示される数字が一度も変わらなかった。何度か設定を変えて計測し直したが、この指標だけは頑固だった。5つある指標のうち、これだけが最後までオレンジ（要改善）の色で残っている。
なぜSpeed Indexだけ動かないのか。しばらく考えて、腑に落ちたのはこういうことだ。Speed Indexは、画面がどれだけ速く「埋まっていくか」を測る。ページの主要部分が出るタイミング（LCP）とは違って、上から下まで、視覚的に埋まっていく過程の速さを見ている。キャッシュはHTMLを速く返すが、返したあとにブラウザが描画していく速さそのものは、テーマの構造やフォントの読み込み、画像の並び方に左右される。CocoonはCocoonなりの描画の順序があって、そこはキャッシュプラグインの管轄外だ。つまりSpeed Indexは、サーバーやキャッシュの話ではなく、テーマとコンテンツの描画の話で、プラグインを入れ替えても動きにくい。3.9秒で止まったのは、Prime Cacheの限界というより、この計測環境のこのテーマの、描画そのものの速さがそこにある、ということだった。ここを詰めるなら、次はテーマ側、フォントや画像の見せ方に手を入れることになる。それはキャッシュの仕事ではない。
ただし、96の天井をSpeed Indexのせいにするのは正しくなかった。公開する前に確かめておこうと思って、スコアを手元で計算し直した。Lighthouseのパフォーマンススコアは5つの指標に重みをかけて足したもので、Speed Indexの重みは10%しかない。重みをかけた失点を出してみると、96で落としている4点のうち、Speed Indexの分は1.7点ほど。いちばん多く落としていたのは、緑で表示されているLCPの2.0点だった。色は指標ごとの点数の帯を示しているだけで、全体の失点の大きさとは関係がない。オレンジがひとつだけ残っていると、そこが原因に見えてしまう。ちなみに両方を満点にしても98点台までで、100には届かない計算になる。
手動チューニングの中身自体は、実はそれほど多くない。無料版のAutoで大半は片づいていて、追加で触ったのはオブジェクトキャッシュを有効にすることと、Brotli圧縮を入れること、それとファイル結合を切ること、くらいだ。ファイル結合はHTTP/2の環境ではむしろ利点が無いので、あえてオフにする。派手に何十項目もいじったわけではない。
攻めた設定には、代償の可能性がある
ひとつ、正直に書いておきたいことがある。
有料版の攻めた最適化、たとえばJavaScriptの遅延や未使用CSSの削除は、速さと引き換えにリスクを抱えている。未使用と判定したCSSを消した結果、実は必要だったスタイルまで巻き込んで、レイアウトが崩れることがある。JavaScriptを遅延させれば、メニューやスライダーやフォームの動き出しが一瞬遅れる。
Prime Cacheは、こういう踏み込んだ設定を有効にすると、管理画面に警告バーを出すようにしてある。「メニュー・スライダー・フォームを入念にテストしてください」と。実際、最大まで遅延を効かせたときは、自分でも各パーツを一通り触って確認した。速さを取りにいくほど、壊れていないかの確認はセットになる。ここは自動化しきれない部分で、押すだけ、とはいかない領域だ。
効いたもの、効かなかったものの整理
その晩わかったことを、指標ごとにまとめておく。
- LCP: 14.8秒 → 4.4秒 → 2.4秒。ページキャッシュで一気に、有料版でもう一段。ここが全体を牽引した
- TBT: 70ms → 0ms → 0ms。無料版の自動設定だけでゼロに到達。以降は下げようがない
- Speed Index: 6.0秒 → 3.9秒 → 3.9秒。無料版で下がりきり、そこから先は表示が一度も変わらなかった
こうして並べると、スコアの伸びが「何をしたか」ときれいに対応していないのがわかる。Autoを押した時点で、TBTとSpeed Indexの二つはもう決着していた。片方は下限に到達したから、もう片方は動く余地がキャッシュの側に無かったから。理由は逆だが、どちらもそこから先は手の届かないところにあった。実際に手を入れて報われたのはLCPだけで、60から96という数字の中身は、ほぼLCPの物語だったと言っていい。
共用サーバーのCocoonで、まず無料の自動設定で82まで来る。そこから先の14は、ほぼLCPを削るための手作業だった。そして96で止まったのは、動かなかったSpeed Indexと、緑になったあともまだ2点を残していたLCPが、半分ずつ持っていったからだ。もし今、同じ環境で高速化に取り組んでいるなら、まずAutoで82を取り、伸び悩んだらどの指標が残っているかを見てほしい。ただし色で決めないほうがいい。あなたのサイトの天井を決めているのが何かは、重みをかけた失点が教えてくれる。
コメント