エッジが大事！HTTP3.0時代のCDNの活用方法

かつてのCDNの役割は「ダウンロード元の分散」が大きかった

通信プロトコルがHTT1.0/1.1の時代では、ブラウザが同じドメインから一度にダウンロードできるファイル数に限界があったため、CDNで静的ファイルを配信することで、物理的にドメインを増やして平行ダウンロードを増やすことで、ページ表示速度を高速化する手法が多く利用されていました。

しかし、現在の標準通信プロトコルであるHTTP2.0では並列ファイル受信が、そして近々標準化されるHTTP3.0では並列パケット受信機能が実装されるため、このような使い方でのCDNの必要性はあまりません。

HTTP2.0に対応しているサーバーであれば、同一サーバーから静的ファイルを配信していても、ダウンロード速度への影響は大きくありません。

平行DLが出来るHTTP2.0ではエッジが大事

しかし、現在ではCDNが重要ではないかというと、そういうわけでありません。

CloudflareやAmazonのCloudfrontなどの大手CDNは世界中にエッジサーバーを持っているため、変更頻度が少ないファイルをCDNのエッジサーバにキャッシュすることで、クラアントに高速にレスポンスを返すことが可能になります。

たとえクライアントとオリジンサーバーの距離短い場合（日本サーバーから日本ユーザーなど）でも、CDNのエッジサーバーの方がクライアントに近いため、オリジンサーバーから配信するよりも圧倒的に高速配信が可能になります。ファイルサイズによっては100ms未満で配信することも可能です。

最近は、SPAなどJavascriptで動的処理をするサイトが増えてきているため、レンダリングブロックを短くするためにも、静的ファイルの配信は高速化するのがベストです。

可能であればオールキャッシュ

CDNはエッジサーバーから高速配信が可能なため、静的ファイルに限らずCDNから配信できるファイルは全てエッジサーバーから配信した方がサイトの高速化ができます。

例えば、

• HTMLのみのサイト
• 更新頻度があ低いサイト
• SPAサイト

については、HTMLファイルやPHPなどの動的出力した結果もキャッシュしても良いでしょう。

SPAサイトについては、HTMLやCSS、Javascriptはページの枠であって、中身のデータはAPIサーバーから出力するのが普通なので、APIサーバー以外は全てキャッシュしても問題ありません。

SPAサイトは静的ファイルのファイルサイズが大きくなりがちなので、なるべくレンダリングブロックを減らして、FCP(First Contentful Paint)を高速化する仕組みも必要でしょう。

サーバー負荷の軽減という役割も

CDNはページ速度を改善するための方法以外にも、オリジンサーバーの負荷軽減という大きな役割も果たしてくれます。

たとえ静的ファイルであっても、サーバーはレスポンスを返してクライアントに結果を送信するという負荷は確実に負うことになるので、アクセス規模が大きいサイトほどCDNを利用することでサーバーの負荷を軽減させることが可能です。

サーバー負荷が下がれば、それだけ動的処理にサーバーリソースを回せるだけでなく、サーバーコストを下げることが可能になります。

---

HTTP3.0時代のCDNの活用方法をみてきました。

近年はエッジコンピューティングが注目されるなど、CDNの役割も変化してどんどん高機能になってきています。CDNを使いこなして、ページを高速化・サーバー負荷の軽減をしてみてください。