WordPressの表示速度というと、LCPの改善や画像の軽量化が話題になりがちですが、その手前にあるTTFB(Time To First Byte=ブラウザが最初の1バイトを受け取るまでの時間)は、実際の数字で語られることが少ない指標です。TTFBが遅いと、その後のすべての指標が後ろにずれ込むので、サーバー・CDN側の速さは土台になります。
TTFBの意味や改善方法はTTFBとは?にまとめました。この記事では、実際に運営している日本語のWordPressサイトで、QUIC.cloud(LiteSpeedのCDN/キャッシュ)経由のTTFBを測った実測の結果だけを紹介します。
📏 測定のやり方
- 各ページに
curlで8回アクセスし、time_starttransfer(TTFB)の中央値を採用 - 測定は筆者のMacから、日本国内の回線で実施
- キャッシュに当たったか(HIT)外れたか(MISS)は、レスポンスヘッダーの
x-qc-cacheで確認
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/⏱ 測定結果(8回の中央値)
| サイト | 経路 | TTFB | キャッシュ |
|---|---|---|---|
| デジタル通貨.club(トップページ) | QUIC.cloud | 46ms | HIT |
| デジタル通貨.club(個別の記事) | QUIC.cloud | 174ms | MISS(サーバーまで取りに行った) |
| arigato.news | QUIC.cloud | 48ms | HIT |
| wpspeedmaster.com(このサイト) | QUIC.cloud | 47ms | HIT |
| wordpresser.quest | Cloudflare → QUIC.cloud | 65ms | Cloudflareが前段に入っている |
🔍 読み取れること
- QUIC.cloudのキャッシュに当たれば、約46〜48ms。Googleが示すTTFBの目安は「0.8秒(800ms)以下が良好」なので、その20分の1ほどです。
- キャッシュに外れても約174ms。それでも目安に十分収まります。サーバー本体側でも、LiteSpeedのキャッシュが効いているためと考えられます。
- Cloudflareを前に置いたサイトは約65msで、QUIC.cloudだけの構成より15〜20msほど遅い結果でした。経路が1つ増えるぶんと見られます。ただし、サイトが違うので厳密な比較ではありません。
日本の読者向けのサイトなら、QUIC.cloudだけの構成で十分速い。少なくとも今回の5サイトでは、Cloudflareを前に重ねる理由は見当たりませんでした。
⚠️ 注意点と限界
- 測定地点は日本国内の1か所だけです。海外からの速さは測れていません。遠い地域の読者がいる場合は、WebPageTestなど、複数の地点から測れるツールを使ってください。
- 外れ値が1回ありました。トップページの8回のうち1回だけ2.4秒(最大2,474ms)かかっています。キャッシュが切れた直後の再生成か、一時的な遅れと見られます。中央値を使うのは、こうした1回のブレに引きずられないためです。
- サイトごとにテーマ・プラグイン・記事数が違うので、数字は「この構成ならこのくらい出た」という実例であり、保証ではありません。
✅ 自分のサイトで確かめるには
- 上の
curlコマンドを、トップページと個別記事のそれぞれで、8回程度繰り返す - 中央値を取る(1回だけ極端に遅い値は無視してよい)
- 次のコマンドで、キャッシュのHIT/MISSを確認する(
x-qc-popには、応答したQUIC.cloudの拠点が出ます。今回の5サイトは、すべて東京(HND)でした) - MISSのページが多い場合は、キャッシュプラグインの有効期限やパージの設定を見直す
curl -sI https://example.com/ | grep -i -E "x-qc-cache|x-qc-pop"TTFBは、LCPのようにコアウェブバイタルとして直接評価される指標ではありませんが、すべての表示の「土台」です。まずは自分のサイトの数字を一度測っておくと、改善の優先順位が付けやすくなります。