CDNのパフォーマンス機能を向上させる6つの方法

本記事ではコンテンツ配信ネットワーク（CDN）が一般的に提供するパフォーマンスの向上機能について説明します。

ファイルを圧縮したり、TLS1.3・HTTP/2（HTTP/3）、画像を最適化したりコード自体を縮小化するなどの方法があります。

逆に言えばこれらの設定を使わないままの管理者が多く、その意味でパフォーマンスUPの機会を失っていると言えます。

CDNのパフォーマンス機能を向上させる6つの方法

コンテンツ配信ネットワーク（CDN）を使えば、どんな環境化でも手放しでWEBサイトのパフォーマンスが上がるという訳ではありません。

こちらから積極的により効果の高い設定を進めていく事が重要です。

様々な工夫を凝らすことで、WEBサイトのパフォーマンスがさらに伸びる可能性があるのです。

主なパフォーマンスUPが見込める設定

関連記事

データを圧縮させる

テキストベースのリクエストは、gzipまたはBrotliのいずれかで圧縮する必要があります。

どちらかを選択ができる環境であれば、Brotliを選択して下さい。

Brotliは新しい圧縮アルゴリズムであり、gzipと比較してもより高い圧縮率を実現できます。

CDNがサポートするBrotli圧縮には「オリジン側のBrotli圧縮」と「自動Brotli圧縮」の2種類があります。

オリジン側のBrotli圧縮

オリジン側のBrotli圧縮は、CDNがオリジンサーバーによってBrotli圧縮されたリソースを利用する場合に必要です。

このためにはオリジン側に、CDNが対応可能なリソース（gzip圧縮とBrotli圧縮）をキャッシュできる環境が必要です。

自動Brotli圧縮

これはリソースがCDNによって自動的にBrotli圧縮される事を意味します。

CDNはキャッシュ可能なリソースとキャッシュ不可能なリソースの両方を圧縮できます。

段階的な圧縮作業

リソースが最初に要求されると、まずはBrotli-5レベル程度の圧縮が展開されます。

このタイプの圧縮は、リソースがキャッシュ可能・不可能に限らず両方で適用できます。

このリソースがキャッシュ可能であった場合は、CDNはオフラインでBrotli-11などのさらに強力な（代わりに速度が落ちる）圧縮レベルでリソースを圧縮します。

この両者でより圧縮されたバージョンの方がキャッシュされ、後続のリクエストに使用されます。

圧縮のベストプラクティスは併用する事

パフォーマンスを最大化したい場合は、オリジンサーバーとCDNの両方でBrotli圧縮を適用しておきましょう。

オリジン側でBrotli圧縮を用意する事は、キャッシュから提供できないリソースの転送サイズを最小限に抑える事につながります。

特に動的リソースの場合はリクエスト処理の遅延を防ぐため、オリジン側ではかなり控えめな圧縮レベル（Brotli-4など）での圧縮がおすすめです。

それに対し静的リソースであれば、Brotli-11など高レベルな圧縮ができます。

Brotliをサポートしていない場合

オリジンサーバーがBrotliをサポートしていない場合、動的リソースならgzip-6を使用して圧縮する事ができます。

そして静的リソースを圧縮する場合は、gzip-9が使用できます。

TLS1.3

TLS1.3は、HTTPSで使用される暗号化プロトコルであるトランスポート層セキュリティ（TLS）の最新バージョンです。

TLS1.2と比較してより優れた保護とパフォーマンスを提供します。

ラウンドトリップが短縮できる

特にTLS1.3はTLSハンドシェイクを2ラウンドトリップから1ラウンドトリップに短縮するメリットがあります。

HTTP/1またはHTTP/2を使用する場合、TLSハンドシェイクを1ラウンドトリップに短縮できれば、接続のセットアップ時間が33％短縮されます。

https（SSL化）している場合でTLS1.3が利用できる環境であれば、積極的に活用しましょう。

HTTP/2

HTTP/2とHTTP/3はどちらも、HTTP/1よりもパフォーマンス上の利点があります。

CDNがデフォルトでHTTP/2をまだ有効にしていない場合は、有効にする事を検討しましょう。

HTTP/2はHTTP/1に比べて複数のパフォーマンス上の利点があり、全ての主要なブラウザでサポートされています。

HTTP/2のパフォーマンス機能には以下のようなものがあります。

HTTP/2の特徴

多重化（バイナリプロトコル）

多重化（バイナリプロトコル）はHTTP/2の最も重要な機能です。

多重化により、単一のTCP接続で複数の要求と応答の両者を同時に処理する事ができます。

これにより不要な接続設定のオーバーヘッドが排除されます。

限られた接続数の中で並行処理ができる

ブラウザには特定の時間内に開く事ができる接続の「数」が制限されています。

ですのでこの多重化により、ブラウザがより多くのページのリソースを並行して要求できるようになる事を意味しています。

HTTP/1の最適化の必要がなくなる？

これにより連結やスプライトシートなどHTTP/1最適化の必要性がなくなる様に思えます。

しかし実際にはファイルが大きいほど圧縮率が高くなる訳ですから、HTTP/1の最適化手法は引き続き必要と言えます。

配信の優先順位付け

上記の多重化により、複数接続の同時配信が可能になります。

これらは別に設けられた優先順位命令の元に配信されます。これが接続配信の優先順位付けです。

これによりサーバーは最初に要求されていなくても、最も重要と位置づけられたリソースを最初に送信します。

より多くのサイトがCDNを介して提供されると、配信の優先順位付けがより効果的になります。

HTTP/2でリソースの優先順位付けをする場合は注意

CDNインスタンスをHTTP/2に切り替える自体は比較的簡単ですが、本番環境で有効にする前に十分テストする必要があります。

HTTP/1とHTTP/2はリクエストヘッダーとレスポンスヘッダーに同じ規則を使用しますが、HTTP/2は規則がはるかに厳格です。

ヘッダーに非ASCII文字や大文字を含める等の非仕様があると、HTTP/2にした際にエラーが出る可能性があります。

デベロッパーツールで確認

これが発生した場合、ブラウザがリソースをダウンロードしようとすると失敗するので注意しましょう。

失敗したダウンロードの試行は、DevToolsの[ネットワーク]タブに表示されます。

またコンソールに「ERR_HTTP2_PROTOCOL_ERROR」というエラーメッセージが表示されます。

サーバープッシュ

サーバープッシュとは、サーバーは特定のリソースをクライアントにまとめて通信できる機能の事です。

通常は一つのリクエストに対し一つのレスポンスを返す事で、クライアントとサーバー間のデータ通信が行われます。

このサーバープッシュ機能により、1回目のリクエストに対するレスポンスのタイミングで複数のリソースを送信する事ができるのです。

この時必要なリソース一つ一つに対して、クライアントからはリクエストをする必要はありません。

HTMLとCSSの場合

例えば1つのHTMLとCSSで構成されたページがあるとしましょう。

このサーバープッシュを利用すると、クライアントから起こした1回目のGETリクストに対し、HTMLのレスポンスと一緒にCSSファイルもレスポンスされるのです。

クライアントにどのリソースをプッシュするかは、ヘッダー情報で制御する事ができるようになっています。

ですのでプッシュされるリソース内容は、レスポンスデータの前に配信する必要があります。

ヘッダー圧縮

昨今の通信では、HTTPのボディだけでなくヘッダー自体も膨張する傾向にあり、ヘッダーを圧縮する必要性も高まってきました。

HTTP/2では、HPACKと呼ばれる圧縮方式でヘッダーを圧縮する事ができます。

HPACKは重複するヘッダー項目の中から送信が必要なヘッダーの「差分」を抽出して送信する方法です。

これによりヘッダー部分のサイズ量・転送量が削減されます。

HTTP/3

HTTP/3はHTTP/2の後継であり、パフォーマンス上の潜在的なメリットがより大きくなります。

HTTP/3はまだ完全に標準化されていませんが、これが標準化されれば広くサポートがされるようになります。

2020年9月の時点で全ての主要なブラウザはHTTP/3を実験的にサポートしており、一部のCDNでもサポートしています。

CDNにおけるHTTP/3のメリット

ヘッドオブラインブロッキングの排除

HTTP/2では多重化（バイナリプロトコル）が導入されましたが、これは単一の接続を使用して複数のデータ配信を平行で送信できる機能です。

ただしHTTP/2では何か一つ破棄されたパケットがあると、接続回線上の全ての配信をブロックしてしまいます。

これがヘッドオブラインブロッキングと呼ばれる現象です。

回線上の全ての配信を止めずに済む

HTTP/3ではこの破棄されたパケットがあっても、全ての配信ではなく破棄されたパケット配信のみをブロックします。

混雑したり損失の多いネットワークを介したデータ転送の場合は、HTTP/3が大いに貢献します。

HTTP/3がヘッドオブラインブロッキングを排除する事で、接続セットアップ時間をさらに短縮できるのです。

接続セットアップ時間の短縮

HTTP/3を利用するにはTLS1.3のSSL化が必須のため、パフォーマンス上の利点は共有されます。

新しい接続が1回のラウンドトリップで確立でき、さらに既存の再接続にラウンドトリップの必要がありません。

HTTP/3は、特にネットワーク接続が不十分な場合にユーザーに最大の影響を与えます。

HTTP/3は、以前のバージョンよりもパケット損失を適切に処理するだけでなく、0-RTTまたは1-RTT接続のセットアップによる絶対的な時間の節約につながります。

通信が途切れない

HTTP/3には「クライアントのIPアドレスが変わってもセッションを継続できる」という特長があります。

例えば外出先から帰宅した場合など、モバイルデータ通信からWi-Fi通信に切り替わる事がよくあります。

この時IPアドレスが変わる事で、通信が切れてしまう事がありますよね。

しかしHTTP/3では、このIPアドレスが変わっても通信を継続できるのです。

HTTP/3の注意

現在のところHTTP/3が利用できるWEBサーバーは大手のものではLiteSpeedの有料版しかありません。

NginxやApacheなどのWEBサーバーはまだ未対応です。

レンタルサーバー対応しているホスティング事業者がまだ少ないのが現状です。

画像を最適化する

CDN画像最適化サービスは通常、画像転送サイズを削減するために自動的に適用できる画像最適化に重点を置いています。

例：EXIFデータの削除、可逆圧縮の適用、画像の新しいファイル形式（WebPなど）への変換など。

画像はWEBページの転送バイトの約50％を占めるとされるため、画像を最適化する事はページサイズの大幅な削減につながります。

画像リサイズ

ほぼすべてのCDNサービスには画像を自動でリサイズする機能が搭載されています。

これにより常に最適な画像サイズにてコンテンツ配信が可能になります。

画像拡張子の自動判別

現在はJPEG形式と同等画質を維持しつつファイルサイズを大きく削減できる、新しい画像ファイル形式が複数開発されています。

しかしながら画像形式ごとにブラウザにおけるサポート体制がまちまちで、なかなか進展していない状況です。

しかし一つの画像に対してブラウザごとに最適となる複数の画像フォーマットを準備する事は現実的ではありません。

ブラウザごとに配信画像を自動判別

そこで、来訪者のブラウザを判別してそれぞれに最適な画像ファイル形式で配信する機能を持つCDNもあります。

例えばiPhoneやMacのSafariへはJPEG2000、AndroidなどのChromeへはWebPによる高度な圧縮を加えて提供しています。

ストレージサービスとの連携

画像をオリジンサーバー側から取得するのではなく、Amazon S3などの画像ストレージサービスから取得する事もできます。

CDNによってはクラウドストレージから画像を配信・最適化する事ができます。

コードの縮小化

縮小化はJavaScriptやCSS、およびHTMLから不要な文字を削除する事を意味します。

この縮小化は、CDN側ではなくオリジンサーバー側でを実行するべきとされています。

サイトの所有者は、縮小するコード部分に関する状況を把握しているはずなので、CDNで採用されている手法よりもより効果的な縮小ができる事が多いのですね。

ただしオリジンでコードを縮小することができない場合は、CDNによる縮小方法を使う事になります。

一押し人気コーナー紹介