画像は圧縮した。JavaScriptも減らした。それでも、最初のページが出るまでが遅いと言われる。表示速度の改善では、施策がフロントエンドに寄り切っていることがあります。手を入れた場所は正しいのに、残っている遅さの置き場所が違うケースです。
Cloudflareが2026年9月に公開した計測は、その置き場所の一つを具体的な数字で示しています。見落とされやすいのは、ページの中身ではなく、通信が始まる最初の一往復です。
鍵交換を外すと、往復が1回増える
HTTPS（TLS 1.3）の接続では、通信を始める前に、接続する側とサーバーが暗号の鍵交換の方式を合わせます。このとき接続する側は「たぶんこれに対応しているだろう」という方式を推測して、その鍵の材料を先に送ります。外れると、サーバーが選び直しを求め、往復がもう1回増えます。この選び直しがHelloRetryRequestです。
Cloudflareのブログによると、CloudflareはCDNから各オリジンサーバーへの接続でこの推測をやめ、オリジンごとに対応方式を測って最初からそれを使う方式（Automatic Key Exchange）へ切り替えています。この展開に伴って、HelloRetryRequestの発生率はおよそ52%から3.7%へ下がり、接続のハンドシェイクにかかる時間はp90で150ミリ秒以上短くなったと説明されています。対象は1日あたり450億接続規模です。あわせて、耐量子暗号で結ばれるオリジン接続のうち、選び直しなしの1往復で完了する割合は0%から99.2%へ上がりました。ただし、耐量子暗号の鍵交換に対応しているオリジンは全体の12.8%にとどまるとされています。
つまり、CDNの側で測って当てにいくようにしたら、これまでおよそ半分の接続が1往復を余分に使っていたことが分かった、という話です。
その区間は、自分の計測では切り分けられない
ここで大事なのは、数字の大きさよりも「どこの数字か」です。制作側がよく見る計測で段階ごとに分かれて見えるのは、ブラウザから手前のCDNまでの区間です。CDNからオリジンサーバーまでの往復は、CDNがオリジンへ取りに行くときの「応答待ち」の時間にまとめて入り、区別して見ることができません。
| 区間 | よく使う計測 | 遅いときの主な原因 |
|---|---|---|
| ブラウザ → CDN | Lighthouse、ブラウザの開発者ツール | 画像・JavaScript・レンダリング |
| CDN → オリジン | 上記では応答待ちに含まれ、区別できない | 接続の確立、オリジンの応答時間 |
| オリジン内部 | サーバーのログ、APM | アプリケーション処理、データベース |
フロントエンドの最適化をやり切ったのに体感が変わらないときは、下の2行を疑います。JavaScriptを削る方向の打ち手を先に確認したい場合は配信するJavaScriptを減らす判断を参照してください。
接続の時間だけを切り出して測る
サイト全体の点数ではなく、接続の段階だけを分けて測ると切り分けが進みます。curl は接続の各段階の経過時間を出せるので、名前解決・TCP接続・TLS確立・最初のバイトまでを分けて記録できます。
curl -o /dev/null -s -w \
'dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' \
https://example.com/tls と tcp の差がTLS確立にかかった時間、ttfb と tls の差がサーバーが返し始めるまでの時間です。CDNを経由するURLで測った場合、tls までは手元とCDNの間の数字で、CDNとオリジンの間の接続とオリジンの処理は ttfb と tls の差にまとめて入ります。そこで、--resolve でホスト名をオリジンのIPアドレスに向けるなどしてオリジンへ直接つなぎ、同じ計測をして比べます（オリジン側でCDN以外からの接続を断っている場合は、許可された場所から実行します）。何度か実行して、どの差が大きいかを見ます。直接つないだときのTLS確立が目立つなら接続まわり、その後が目立つならアプリケーションやデータベース側、という分け方になります。証明書と更新の運用そのものが原因になることもあり、その観点はTLS証明書の有効期間短縮と自動更新で扱っています。
保守の契約で確認しておくこと
今回の改善は、Cloudflare側の設定として自動的に効く種類のものです。公式ドキュメントでは、全プランの既存・新規のゾーンで既定で有効とされ、暗号化モードがFullやFull (strict)などで、オリジンとの接続がTLS 1.3の場合に働きます。利用者が何かを書き換える話ではありません。だからこそ、保守で見るべきはもっと手前の項目になります。
自社のサイトがどの経路で配信されているか（CDNを経由しているか、直接か）。オリジンのTLS設定（TLS 1.3に対応しているかを含む）を最後に見直したのはいつか。計測の対象がブラウザからの見かけだけになっていないか。この3つが答えられない状態で速度改善の見積りを取ると、効かない箇所に工数を使いかねません。改修ではなく継続的な手入れで直す考え方は公開後の改善に予算を残すで整理しています。
2026年9月24日に、CloudflareのブログとSSL/TLSのドキュメント、curlのマニュアルを、検索結果に含まれる各ページの抜粋で再確認しました。数値はCloudflare全体の集計で、個別サイトの改善幅ではありません。自社環境でのハンドシェイク時間の測定や、Cloudflare設定の比較検証は実施していません。本記事は切り分け手順と確認項目の整理です。
サイトの表示速度の調査や、配信構成の見直しの相談は、グリームハブへご相談ください。
