インターネット史上最大の変革？
2025 年 8 月 27 日、ニフティが個人向け Web サイトホスティングサービス「LaCoocan」を 10 月 1 日から HTTPS 対応させることを発表しました。これにより、疎通確認サイト「阿部寛のホームページ」も HTTPS 化する見通しとなりました。
この変化は一見小さなアップデートに見えますが、実はインターネットの「疎通確認界隈」に激震を走らせています。HTTPS 非対応のレトロ PC やゲーム機などの接続確認に同ページを使っていたユーザから、残念がる声が出ています。
果たして HTTPS 化は本当にサイト表示速度に影響するのか？開発者ツールによる実測データをもとに、技術的観点から検証してみました。
1. 阿部寛のホームページの構成
開発者ツールによる確認
Web ブラウザの開発者ツールを使用し、ロードされるリソースを確認しました。回線速度はおよそ 500Mbps でした。一瞬で表示完了します。
| ファイル名 | サイズ | 読み込み時間 | 役割 |
|---|---|---|---|
| index.htm | 775 B | 69 ms | フレーム構造の定義 |
| menu.htm | 2.8 kB | 35 ms | ナビゲーションメニュー |
| top.htm | 4.7 kB | 26 ms | メインコンテンツ |
| abe-top-20190328-2.jpg | 26.4 kB | 51 ms | プロフィール画像 |
| abehiroshi.jpg | 3.3 kB | 32 ms | 背景画像 |
実測結果:
- 総リクエスト数：5 件
- 転送データ量：38.0 kB
- リソースサイズ：36.8 kB
- 総読み込み時間：173 ms（DOMContentLoaded: 87 ms）
上記のとおり、阿部寛のホームページのトップページ(index.htm)にアクセスすると、<frame>タグによって menu.htm と top.htm がロードされるため、計 3 つの htm ファイルがロードされます。また、プロフィール画像と背景画像の 2 つの画像ファイルもロードされます。
2. HTTP と HTTPS の通信手順
HTTP
【接続確立フェーズ】
1. TCP接続確立（3ウェイハンドシェイク） × 1回
※HTTP/1.1 Keep-Aliveにより1接続を再利用
【リソース取得フェーズ】
2. index.htm取得
GET /index.htm HTTP/1.1
3. フレーム解析後、並列取得開始
GET /menu.htm HTTP/1.1
GET /top.htm HTTP/1.1
4. HTML解析後、画像取得
GET /abe-top-20190328-2.jpg HTTP/1.1
GET /abehiroshi.jpg HTTP/1.1
総ハンドシェイク：3回（TCP）
総リクエスト：5回
HTTPS
【接続確立フェーズ】
1. TCP接続確立（3ウェイハンドシェイク）
2. TLS/SSLハンドシェイク（4往復）
- ClientHello → ServerHello
- 証明書交換 → キー交換
※HTTP/2なら1接続で多重化、HTTP/1.1なら接続再利用
【リソース取得フェーズ】
3-7. 各リソースの暗号化取得（5回）
- 各レスポンスの暗号化処理
- 各リクエストの復号化処理
総ハンドシェイク：7回（TCP + TLS）
総リクエスト：5回（すべて暗号化）
3. 表示時間の理論値
HTTP
HTTP表示時間 = 接続確立時間 + 並列取得時間
接続確立時間 = RTT × 1.5
並列取得時間 = max(
index.htm取得時間,
menu.htm + top.htm取得時間（並列）,
画像ファイル群取得時間（並列）
)
各ファイル取得時間 = ファイルサイズ / 帯域幅
HTTPS
HTTPS表示時間 = 接続確立時間 + TLS確立時間 + 暗号化並列取得時間
接続確立時間 = RTT × 1.5
TLS確立時間 = RTT × 2 + 暗号化処理時間（30-50ms）
と仮定します。
暗号化並列取得時間 = max(
暗号化index.htm取得時間,
暗号化menu.htm + 暗号化top.htm取得時間,
暗号化画像ファイル群取得時間
) + 復号化処理時間
4. 具体的な表示速度の理論値
良好な通信環境の場合
- 回線速度： 500Mbps
- RTT 実測値： 平均 23.572ms（min: 20.573ms, max: 27.026ms, stddev: 2.344ms）
- パケットロス： 0.0%（安定した接続環境）
HTTP
TCP確立時間 = RTT × 1.5 = 23.572ms × 1.5 = 35.4ms
データ転送時間 = 38kB / 500Mbps = 0.6ms
HTTP理論合計 = 36ms
実測173ms - 理論36ms = 137ms
→ サーバー処理時間 + DOM構築 + 並列処理待ち時間 = 137ms
HTTPS
TCP確立時間 = 35.4ms
TLS確立時間 = RTT × 2 + 暗号化処理 = 47.1ms + 40ms = 87.1ms
データ転送時間 = 0.6ms（TLSオーバーヘッド含む）
その他処理時間 = 137ms（HTTPと同等と仮定）
HTTPS予測合計 = 260ms
回線速度による表示時間の変化
| 回線速度 | HTTP (a) | HTTPS (b) | 差分 (b - a) | 増加率 (b / a) |
|---|---|---|---|---|
| 500Mbps | 173ms | ～ 260ms | 87ms | 1.50 |
| 100Mbps | 178ms | 265ms | 87ms | 1.49 |
| 10Mbps | 209ms | 296ms | 87ms | 1.42 |
| 1Mbps | 483ms | 570ms | 87ms | 1.18 |
今回の仮定においては、RTT 23.572ms という良好な環境でも、HTTPS 化で約 87ms の固定的な遅延が発生します。また、この遅延は回線速度に関係なく一定で、TLS ハンドシェイク＋暗号化処理によるものです。
絶望的な超低速回線の場合
56kbps 回線（ダイアルアップ相当）
HTTP: 35.4ms + 5,429ms + 137ms = 5,601ms（約5.6秒）
HTTPS: 122.5ms + 5,701ms + 137ms = 5,960ms（約6.0秒）
差分：359ms（TLS固定遅延 87ms + データ転送遅延）
さらに過酷な 28.8kbps 回線
HTTP: 35.4ms + 10,548ms + 137ms = 10,720ms（約10.7秒）
HTTPS: 122.5ms + 11,075ms + 137ms = 11,334ms（約11.3秒）
差分：614ms（約0.6秒の追加遅延）
5. 私たちの生活への影響
疎通確認文化の終焉
これまで阿部寛のホームページは、以下の用途で愛用されてきました。
疎通確認の聖地としての役割
- 月末の通信制限時の最後の希望
- レトロ PC（Windows 95/98/ME）の動作確認
- 古いゲーム機（PlayStation 2 のネットワークアダプタ等）
- 組み込み機器の HTTP 実装テスト
- 新しいルーター設定の動作確認
実際の利用者の声
「家のネット回線が遅すぎて、阿部寛のホームページの読み込みが途中で止まる」
「通信制限の辛さを表現するなら阿部寛のホームページが表示されない状況」
これらの文化的価値が失われる可能性があります。
技術的難民の発生
HTTPS 化により以下の機器・環境が影響を受けます。
接続不可能になる機器
- SSL/TLS 非対応のレトロブラウザ
- レガシー PDA
- 一部の組み込み機器
測定基準の変化
従来の基準: 「阿部寛のホームページが ○ 秒で開けば正常」
新基準の必要性: HTTPS 対応軽量サイトの新たな聖地が必要
ポジティブな影響
セキュリティの向上
- 中間者攻撃の防止
- データ改ざん防止
- プライバシー保護の強化
技術的進歩
- HTTP/2 による多重化の恩恵
- TLS 1.3 による高速化
- セキュアな軽量サイト設計の新基準
6. まとめ
阿部寛のホームページの HTTPS 化による影響は予想していたよりも大きかった。
※本記事の計算は開発者ツール実測データと理論値の組み合わせです。実際の環境では様々な要因により結果が異なる場合があります。