なぜ「F5連打」は負けるのか？ 0.1秒を削り出す「Preconnect（事前接続）」の技術

「ちゃんと押したのに繋がらない」の正体

チケットの発売時刻ぴったりにF5キーを押した。それなのに「混雑しています」の画面。隣の人は買えたのに、自分は買えなかった。

これは「指が遅い」のではなく、あなたのブラウザが接続の準備に時間を取られているのが原因かもしれません。

その準備時間は、環境にもよりますが数十〜数百ミリ秒。チケット争奪戦では、この差が結果を左右することがあります。

Webアクセスの裏側で起きていること

ブラウザでWebサイトを開くとき、目に見えない「3つの手続き」が毎回行われています。

1. DNS解決 — 住所を調べる

URLに含まれるドメイン名（例: ticket.example.com）を、サーバーのIPアドレス（例: 203.0.113.5）に変換する作業です。電話帳で相手の電話番号を調べるようなものです。

2. TCP接続 — 回線をつなぐ

IPアドレスがわかったら、相手サーバーとの通信回線を確立します。「もしもし」「はい、どうぞ」というやり取り（3ウェイハンドシェイク）で、お互いの通信準備が整います。

3. TLSハンドシェイク — 暗号化する

現在のWebサイトはほぼすべてHTTPS（暗号化通信）です。 TCP接続の上にさらに暗号鍵の交換を行い、安全な通信路を構築します。

手続き	やっていること	所要時間の目安
DNS解決	ドメイン名 → IPアドレスの変換	数ms〜数十ms（キャッシュ状況で変動）
TCP接続	サーバーとの通信回線の確立	数十ms〜（サーバーとの距離に依存）
TLSハンドシェイク	暗号鍵の交換・安全な通信路の構築	数十ms〜（プロトコルバージョンに依存）

これらの処理は、初回アクセス、待機が長くて接続が切れた、ネットワーク切替直後などで発生しやすく、合計で数十〜数百ミリ秒かかることがあります。ブラウザにはDNSキャッシュや接続の再利用（keep-alive等）の仕組みもありますが、チケット発売のように「初めてのサイトに時刻ぴったりでアクセスする」場面では、フルセットの処理が走りやすいのです。

F5連打が逆効果な理由

この仕組みを知ると、なぜF5連打が逆効果かがわかります。

F5を押すたびに、ブラウザは読み込み途中のページを破棄して再取得を始めます。状況によっては接続やDNSキャッシュが再利用されることもありますが、 読み込み完了前にリロードを繰り返すと、結果的に待ち時間が増えてしまいます。

ゴール直前で「やっぱり最初から！」と何度もスタートラインに戻っているようなものです。

さらに、短時間にリクエストが集中すると、サーバーから レート制限（アクセス制限）の対象になることもあります。連打は速くなるどころか、自分だけアクセスをブロックされるリスクすらあるのです。

Preconnect（事前接続）という解決策

もし、DNS・TCP・TLSの手続きをタイマーが0になる前に済ませておけたらどうでしょうか。

これがPreconnect（事前接続）の考え方です。ブラウザの標準機能として用意されている最適化ヒントで、以下の1行で指示できます。

<link rel="preconnect" href="https://ticket.example.com">

補足：異なるオリジン（ドメイン）への接続で、フォントやfetchなどCORS対応が必要なリソースには crossorigin 属性を追加する必要があります（例: <link rel="preconnect" href="..." crossorigin>）。ページ遷移自体の接続には不要です。

この指示を受けたブラウザは、実際のページリクエストを送る前に、裏側でDNS解決・TCP接続・TLSハンドシェイクを先に完了させることができます。

そして、いざページを開く瞬間には、準備運動が済んだ状態で本番のリクエスト送信からスタートできます。

ただし、preconnectはあくまで「ヒント」です。ブラウザや接続先の状況によっては効果が限定的な場合もあります。 MDNでも「重要なコネクションに絞って使うべき」とされています。

実測データ：当環境で291msの差

ページ更新君の開発時に、Preconnectの効果を実際に計測しました。対象はWikipediaのトップページ、Chrome DevToolsのNetwork Timingで計測した結果です。

注意：以下は特定の環境・タイミングでの1回の計測結果です。実際の効果はネットワーク環境、接続先サーバー、ブラウザの状態によって変動します。

Preconnectなし（400ms）とあり（100ms）のChrome DevTools比較 — Chrome DevToolsでの計測結果。左がPreconnectなし（400ms）、右がPreconnectあり（100ms）

Preconnect なし（従来の方法）

フェーズ	時間
DNS Lookup	16.35ms
TCP接続	162.51ms
TLSハンドシェイク	82.88ms
リクエスト送信 + サーバー応答	156.87ms
合計	約401ms

Preconnect あり（Premium機能）

フェーズ	時間
DNS Lookup	0ms（事前完了）
TCP接続	0ms（事前完了）
TLSハンドシェイク	0ms（事前完了）
リクエスト送信 + サーバー応答	90.62ms
合計	約110ms

この計測では、DNS + TCP + TLS の処理が事前に完了したことで、 約291ms（約0.3秒）の短縮が確認できました。ただし、これは計測環境での結果であり、実際の効果はネットワーク状況によって異なります。

※ DevTools上の「0ms」は、そのリクエスト時点で待ちが発生しなかったことを示しています。接続準備のコスト自体は事前のpreconnect側で支払われています。

ページ更新君での実装

ページ更新君のPremiumプランでは、タイマー実行中に自動でPreconnectが動作します。ユーザーが意識する必要はありません。

タイミングの工夫

Preconnectには1つ注意点があります。ブラウザが事前確立した接続は、一定時間使われないとタイムアウトで切れることがあります（具体的な秒数はブラウザやサーバー設定に依存します）。早すぎるタイミングで接続しても、肝心の遷移時には切れてしまう可能性があるのです。

ページ更新君では、この問題を以下のように解決しています。

待機時間	Preconnectのタイミング
5分以内	遷移の3秒前に接続を確立
5分以上（Premiumのみ）	遷移の5秒前に再接続を確立

長時間待機の場合も、直前に再接続するため、接続のタイムアウトを心配する必要はありません。

Preconnect + NTP同期 + ミリ秒指定の組み合わせ

Premiumプランでは、Preconnectに加えて以下の機能が連携して動作します。

NTP同期 — NICTの公開NTPサーバーから時刻を取得し、デバイスの時計のズレを補正
ミリ秒単位の時刻指定 — 1ms単位で時刻を指定でき、可能な範囲で実行タイミングを詰める
Preconnect — 接続の準備を事前に完了

これらを組み合わせることで、手動操作に比べて有利なタイミングでアクセスできる可能性が高まります。

F5連打 vs Preconnect — 比較まとめ

項目	F5連打	Preconnect
DNS + TCP + TLS	読み込み完了前の連打でリクエストが無駄になりやすい	事前に1回だけ完了（環境による）
サーバーへの負荷	大量のリクエストを送信	必要な1回だけ送信
レート制限のリスク	高い（ブロックされる可能性）	低い
必要なスキル	指の速さと運	チェックを1つ入れるだけ

ご利用にあたっての注意

チケット販売サイトの利用規約には、自動化ツールの使用や過剰なアクセスを禁止する条項が含まれている場合があります。ページ更新君は指定時刻にページを1回開くだけのツールですが、ご利用の際は各サイトの規約をご確認のうえ、他のユーザーの迷惑にならない範囲でお使いください。

まとめ

チケット争奪戦で不利になる原因の一つは、「指の速さ」ではなく「回線の準備時間」です。 F5を何度押しても、読み込みが完了する前にリロードを繰り返せば結果的に待ち時間が増え、その分だけ遅れが生じます。

Preconnect技術を使えば、この準備時間を削減できる場合があります。運任せの連打ではなく、技術的に有利なポジションを目指しましょう。