“Webページ 高速化” で検索すると、記事でよく見かける「CDNを使う」は高速化しない場合があります。
なぜCDNを使うのか？は、コンテキストによって答えは変わります。
例えば今と昔では事情が全く異なります。
以下、この記事ではCDNの定義をcdnjsやのような外部サービスで配信しているリソースと定義しています。
同時接続は、2リクエストまで？
HTTP/2とHTTP1.1のプロトコルは何が違うのか？
で、多く語られるのが同時接続数の違いです。
HTTP1.1には同時接続に2リクエストが望ましいというRFCの仕様があります。
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. A proxy SHOULD use up to 2*N connections to
another server or proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response
times and avoid congestion.
ただし、実際にはブラウザはRFCをガン無視してリクエスト数を状況に応じて変えています。
Chromeは6リクエストしているのが有名です。
ドメインシャーディングというHack
さきほどHTTP1.1は同時接続に6リクエストしかしないと書きましたが、これは同一ドメインでの場合の話です。
なので別ドメインを使用することでこの問題を回避することができました。
これがドメインシャーディングと呼ばれる手法で、CDNを使う理由のひとつでした。
HTTP/2はストリーミングで接続
そんな問題も解決させた、HTTP/2の登場🎉
Googleが独自に開発していたプロトコルをベースに標準化したもの。
- HTTPの同時接続数
→ (ドメイン数 x 6) - HTTP/2の同時接続数
→ 1 ※並行処理で複数の処理をおこなう
HTTP/2の同時接続数は1だが、ストリーミングで平行処理を行うことで複数のファイルを扱うことが可能。
※この記事を公開した当初、HTTP/2は同時接続無制限と書いていましたが誤りです。
高速化しない場合とは？
ドメインシャーディングを使った場合、ドメイン解決処理(DNS lookupやTCPコネクション、TLSネゴシエーション)がありドメイン数に応じて処理に時間がかかってしまいます。
なので高速化対策としてはドメイン数は増やさないほうが良いです。
…が、別の視点からみると使えるシーンもあります。
それは例えば負荷対策としてですが、自分のサーバーで捌くファイルを減らすことができると考えられます。
まとめ
- HTTP/2環境では、CDNを使ったドメインシャーディングはコストとなることがある。
- 別ドメイン使う場合は、Preconnectを設定しておくと良い。
記事のご指摘や、高速化の情報などあれば是非教えていただきたいです！
