コンテンツ配信ネットワーク（CDN）

コンテンツ配信ネットワークを使用してパフォーマンスを改善します。

Katie Hempenius 氏
Katie Hempenius
X

コンテンツ配信ネットワーク（CDN）は、サーバーの分散ネットワークを使用してユーザーにリソースを提供することで、サイトのパフォーマンスを向上させます。CDN はサーバーの負荷を軽減するため、サーバー費用を削減し、トラフィックの急増の処理に適しています。この記事では、CDN の仕組みについて説明し、CDN 設定の選択、構成、最適化に関するプラットフォームに依存しないガイダンスを示します。

概要

コンテンツ配信ネットワークは、ユーザーにコンテンツを素早く配信するように最適化されたサーバーのネットワークで構成されています。CDN はキャッシュされたコンテンツの配信で最もよく知られていますが、キャッシュできないコンテンツの配信も改善できます。一般的に、CDN によって配信されるサイトが多いほど効果的です。

大まかに言うと、CDN のパフォーマンス上のメリットは、いくつかの原則に起因しています。CDN サーバーは送信元サーバーよりもユーザーに近い場所に配置されているため、ラウンドトリップ時間（RTT）のレイテンシが短くなります。ネットワークの最適化により、CDN はコンテンツが配信元サーバーから「直接」読み込まれた場合よりも迅速にコンテンツを配信できます。最後に、CDN キャッシュを使用すると、配信元サーバーへのリクエストが不要になります。

リソース配信

直感的に理解しづらいかもしれませんが、CDN を使用してリソースを配信する方が（キャッシュできないリソースであっても）通常は、ユーザーがリソースをサーバーから「直接」読み込むよりも高速です。

CDN を使用して送信元からのリソースの配信を行うと、クライアントと近くの CDN サーバーの間に新しい接続が確立されます。残りの部分（CDN サーバーと送信元間のデータ転送）は CDN のネットワーク上で行われます。多くの場合、これには送信元との既存の永続的な接続が含まれます。この方法のメリットは 2 つあります。1 つ目は、ユーザーのできるだけ近くで新しい接続を終端することで、不要な接続設定コストを排除することです（新しい接続の確立にはコストがかかり、複数回のラウンドトリップが必要になります）。また、事前にウォームアップした接続を使用すると、最大限のスループットでデータを即座に転送できます。

CDN ありとなしの接続設定の比較

一部の CDN は、インターネット上に分散している複数の CDN サーバーを介して送信元へのトラフィックをルーティングすることで、この点をさらに改善しています。CDN サーバー間の接続は、Border Gateway Protocol（BGP）によって決定されたルートではなく、信頼性が高く高度に最適化されたルートを介して行われます。BGP はインターネットの事実上のルーティング プロトコルですが、ルーティングの決定は必ずしもパフォーマンス指向とは限りません。そのため、BGP で決定されたルートは、CDN サーバー間の微調整されたルートよりもパフォーマンスが低下する可能性があります。

CDN ありとなしの接続設定の比較

キャッシュ

CDN のサーバーにリソースをキャッシュ保存することで、配信のためにリクエストが送信元まで到達する必要がなくなります。その結果、リソースがより迅速に配信され、配信元サーバーの負荷も軽減されます。

キャッシュへのリソースの追加

CDN キャッシュにデータを入力する最も一般的な方法は、必要に応じて CDN リソースを「pull」することです。これは「送信元 pull」と呼ばれています。特定のリソースがキャッシュから初めてリクエストされると、CDN は送信元サーバーにそのリソースをリクエストし、レスポンスをキャッシュに保存します。このようにして、キャッシュされていないリソースがさらにリクエストされると、時間の経過とともにキャッシュの内容が蓄積されます。

キャッシュからのリソースの削除

CDN はキャッシュ エビクションを使用して、あまり役に立たないリソースをキャッシュから定期的に削除します。また、サイト所有者はパージを使用してリソースを明示的に削除できます。

  • キャッシュ エビクション

    キャッシュのストレージ容量は有限です。キャッシュが容量の上限に近づくと、最近アクセスされていないリソースや、多くの容量を占有しているリソースを削除することで、新しいリソースのためのスペースが確保されます。このプロセスは、キャッシュ エビクションと呼ばれます。あるキャッシュからリソースが削除されたからといって、CDN ネットワーク内のすべてのキャッシュからリソースが削除されたとは限りません。

  • パージ

    パージ（「キャッシュの無効化」とも呼ばれます）は、期限切れになるか強制排除されるまで待つことなく、CDN のキャッシュからリソースを削除するためのメカニズムです。通常は、API を介して実行されます。パージは、コンテンツを撤回する必要がある場合（入力ミス、価格エラー、誤ったニュース記事の修正など）に重要です。さらに、サイトのキャッシュ戦略においても重要な役割を果たします。

    CDN がほぼ即時のパージをサポートしている場合、パージは、動的コンテンツのキャッシュを管理するメカニズムとして使用できます。つまり、長い TTL を使用して動的コンテンツをキャッシュに保存し、更新されるたびにリソースをパージします。これにより、リソースが変更されるタイミングを事前に把握していなくても、動的リソースのキャッシュ保存期間を最大化できます。この手法は、「hold-till-told キャッシュ」と呼ばれることもあります。

    大規模なパージを行う場合、通常は「キャッシュ タグ」または「サロゲート キャッシュキー」という概念と組み合わせて使用されます。このメカニズムにより、サイト所有者は 1 つ以上の追加の識別子（「タグ」とも呼ばれます）をキャッシュされたリソースに関連付けることができます。これらのタグを使用すると、きめ細かなパージを実行できます。たとえば、サイトのフッターを含むすべてのリソース（例: /about、/blog）に「フッター」タグを追加できます。フッターが更新されたら、「フッター」タグに関連付けられているすべてのリソースを削除するように CDN に指示します。

キャッシュに保存可能なリソース

リソースをキャッシュに保存するかどうかとその方法は、一般公開か限定公開か、静的か動的かによって異なります。

限定公開リソースと一般公開リソース

  • 限定公開リソース

    プライベート リソースには単一ユーザーを対象としたデータが含まれているため、CDN によってキャッシュに保存しないでください。プライベート リソースは、Cache-Control: private ヘッダーで示されます。

  • 公開リソース

    公開リソースにはユーザー固有の情報が含まれていないため、CDN によってキャッシュに保存できます。Cache-Control: no-store または Cache-Control: private ヘッダーがないリソースは、CDN によってキャッシュ可能であるとみなされます。パブリック リソースをキャッシュに保存できる期間は、アセットの変更頻度によって異なります。

動的コンテンツと静的コンテンツ

  • 動的コンテンツ

    動的コンテンツとは、頻繁に変更されるコンテンツのことです。API レスポンスやショップのホームページは、このコンテンツ タイプの例です。ただし、このコンテンツが頻繁に変更されるからといって、必ずしもキャッシュされないわけではありません。トラフィックが多いときに、これらのレスポンスを非常に短い時間（5 秒など）キャッシュに保存すると、データの更新頻度への影響を最小限に抑えながら、配信元サーバーの負荷を大幅に軽減できます。

  • 静的コンテンツ

    静的コンテンツは、それほど頻繁には変更されません。一般的に、画像、動画、バージョン管理されたライブラリなどがこれに該当します。静的コンテンツは変更されないため、長い有効期間（TTL）を設定してキャッシュに保存する必要があります（6 か月や 1 年など）。

CDN の選択

パフォーマンスは通常、CDN を選択する際の最重要事項です。ただし、CDN のその他の機能（セキュリティと分析の機能など）、CDN の料金、サポート、オンボーディングはすべて、CDN を選択する際に考慮すべき重要事項です。

パフォーマンス

CDN のパフォーマンス戦略は、レイテンシの最小化とキャッシュ ヒット率の最大化のトレードオフの観点から考えることができます。多くのポイント オブ プレゼンス（PoP）がある CDN はレイテンシを短縮できますが、トラフィックがより多くのキャッシュに分割されるため、キャッシュ ヒット率が低下する可能性があります。逆に、PoP の少ない CDN は、地理的にユーザーから遠く離れている可能性がありますが、キャッシュ ヒット率は高くなります。

このトレードオフの結果、一部の CDN はキャッシュに階層型アプローチを採用しています。ユーザーに近い場所にある PoP（「エッジ キャッシュ」とも呼ばれます）は、キャッシュ ヒット率が高い中央の PoP で補完されます。エッジ キャッシュがリソースを見つけることができない場合、エッジ キャッシュはリソースの中央 PoP を探します。このアプローチでは、レイテンシが若干長くなり、CDN キャッシュからリソースが提供される可能性が高くなりますが、必ずしもエッジ キャッシュではありません。

レイテンシの最小化とキャッシュ ヒット率の最大化のトレードオフにはさまざまなものがあります。どれほど優れた手法が最適というものもありません。しかし、サイトの性質やユーザーベースの性質によっては、一方のアプローチの方が他方よりも大幅に高いパフォーマンスを発揮する場合があります。

また、CDN のパフォーマンスは、地域、時間帯、さらには現在のイベントによって大きく異なる場合もあります。CDN のパフォーマンスについて独自の調査を行うことは常におすすめしますが、CDN から得られるパフォーマンスを正確に予測することは困難な場合があります。

Largest Contentful Paint（LCP）への影響

この記事で前述したように、CDN の主な目的は、地理的にユーザーに近いサーバーにリソースを分散してレイテンシを短縮することです。このため、CDN の主なメリットは読み込みパフォーマンスの向上です。特に、ウェブサイトのサーバーサイド アーキテクチャに CDN を導入すると、リソースの Time to First Byte（TTFB）を大幅に短縮できます。

TTFB はユーザー中心のパフォーマンス指標ではありませんが、ユーザー中心の指標である Largest Contentful Paint（LCP）の問題を診断するための重要な指標です。

CDN は LCP の改善に特に効果的です。ドキュメント配信の改善（接続設定とドキュメントのキャッシュにおける TTFB の削減）と、LCP 要素のレンダリングに必要な静的リソースの配信の改善の両方を実現できるためです。

その他の機能

CDN は通常、中核となる CDN サービスに加えて、さまざまな機能を提供します。一般に提供される機能には、ロード バランシング、画像の最適化、動画ストリーミング、エッジ コンピューティング、セキュリティ プロダクトなどがあります。

CDN の設定方法

CDN を使用してサイト全体を配信するのが理想的です。大まかな設定プロセスでは、CDN プロバイダに登録し、CDN プロバイダを指すように CNAME DNS レコードを更新します。たとえば、www.example.com の CNAME レコードが example.my-cdn.com を参照しているとします。この DNS の変更により、サイトへのトラフィックは CDN 経由でルーティングされるようになります。

CDN を使用してすべてのリソースに対応できない場合は、リソースのサブセットのみ（たとえば、静的リソースのみ）を提供するように CDN を構成できます。これを行うには、CDN によって提供されるリソースにのみ使用する別の CNAME レコードを作成します。たとえば、example.my-cdn.com を参照する static.example.com CNAME レコードを作成するとします。CDN によって提供されるリソースの URL も、作成した static.example.com サブドメインを参照するように書き換える必要があります。

この時点で CDN は設定されますが、構成が非効率になる可能性があります。この記事の次の 2 つのセクションでは、キャッシュ ヒット率を高め、パフォーマンス機能を有効にすることで CDN を最大限に活用する方法について説明します。

キャッシュ ヒット率の改善

CDN を効果的に設定することで、できるだけ多くのリソースがキャッシュから提供されます。これは一般にキャッシュ ヒット率（CHR）で測定されます。キャッシュ ヒット率は、特定の期間におけるキャッシュ ヒット数を合計リクエスト数で割った値として定義されます。

新しく初期化されたキャッシュの CHR は 0 ですが、キャッシュにリソースが追加されるにつれて増加します。ほとんどのサイトでは、CHR を 90% に設定することをおすすめします。CDN プロバイダから、CHR に関する分析情報とレポートが提供されます。

CHR を最適化する際にまず確認すべきことは、キャッシュ可能なすべてのリソースが正しい時間、キャッシュとキャッシュの対象になっていることです。これは、すべてのサイトで実施する必要がある簡単な評価です。

CHR 最適化の次のレベルは、大まかに言えば、論理的に同等のサーバー レスポンスが個別にキャッシュされないように CDN 設定を微調整することです。これは、クエリ パラメータ、Cookie、リクエスト ヘッダーなどの要因がキャッシュ保存に及ぼす影響によって発生する一般的な非効率性です。

初期監査

ほとんどの CDN はキャッシュ分析を提供します。さらに、WebPageTest や Lighthouse などのツールを使用すると、ページのすべての静的リソースが正しい期間、キャッシュに保存されていることをすばやく確認できます。これを行うには、各リソースの HTTP キャッシュ ヘッダーを確認します。最適な有効期間（TTL）を使用してリソースをキャッシュすることで、その後の不要な送信元取得を回避して、CHR を増やすことができます。

CDN でリソースをキャッシュに保存するには、通常、少なくとも次のいずれかのヘッダーを設定する必要があります。

  • Cache-Control: max-age=
  • Cache-Control: s-maxage=
  • Expires

さらに、リソースが CDN によってキャッシュに保存されるかどうかや、キャッシュに保存される方法には影響しませんが、Cache-Control: immutable ディレクティブも設定することをおすすめします。Cache-Control: immutable は、リソースが「更新の存続期間中は更新されない」ことを示します。その結果、ブラウザはリソースをブラウザ キャッシュから提供する際にリソースを再検証せず、不要なサーバー リクエストを削除することになります。このディレクティブは Firefox と Safari でのみサポートされており、Chromium ベースのブラウザではサポートされていません。この問題では、Chromium の Cache-Control: immutable サポートを追跡しています。この問題にスターを付けると、この機能のサポートが促進されます。

HTTP キャッシュの詳細については、HTTP キャッシュを使用して不要なネットワーク リクエストを防止するをご覧ください。

ファイン チューニング

CDN キャッシュの仕組みを少し簡単に説明すると、リソースをキャッシュしてキャッシュから取得するためのキーとして、リソースの URL が使用されるというものです。実際には、これは依然として非常に当てはまりますが、リクエスト ヘッダーやクエリ パラメータなどの影響によって若干複雑になります。そのため、リクエスト URL の書き換えは、CHR を最大化し、適切なコンテンツをユーザーに提供できるようにするための重要な手法です。CDN インスタンスを適切に設定すれば、過度に詳細なキャッシュ保存（CHR に悪影響を及ぼします）と、粒度が不十分なキャッシュ保存（ユーザーに正しくないレスポンスが返される）の適切なバランスを取ります。

クエリ パラメータ

デフォルトでは、CDN はリソースをキャッシュに保存するときにクエリ パラメータを考慮します。ただし、クエリ パラメータの処理を少し調整するだけで、CHR に大きな影響が出る可能性があります。次に例を示します。

  • 不要なクエリ パラメータ

    デフォルトでは、CDN は example.com/blog と example.com/blog?referral_id=2zjk を別々にキャッシュに保存しますが、基盤となるリソースは同じである可能性があります。この問題は、CDN の設定を調整して referral\_id クエリ パラメータを無視することで修正されます。

  • クエリ パラメータの order

    CDN は、example.com/blog?query=dogs&id=123 とは別に example.com/blog?id=123&query=dogs をキャッシュに保存します。ほとんどのサイトでは、クエリ パラメータの順序は重要ではありません。そのため、クエリ パラメータを並べ替えるように CDN を設定すると（それにより、サーバー レスポンスのキャッシュに使用される URL が正規化されます）、CHR は増加します。

変動

Vary レスポンス ヘッダーは、特定の URL に対応するサーバー レスポンスが、リクエストに設定されているヘッダー（たとえば、Accept-Language または Accept-Encoding リクエスト ヘッダー）によって異なる可能性があることをキャッシュに通知します。その結果、CDN に対してこれらのレスポンスを個別にキャッシュに保存するよう指示します。Vary ヘッダーは CDN で広くサポートされていないため、本来はキャッシュ可能なリソースがキャッシュから配信されなくなる可能性があります。

Vary ヘッダーは便利なツールですが、不適切な使用は CHR に悪影響を及ぼします。また、Vary を使用する場合は、リクエスト ヘッダーを正規化すると、CHR を改善できます。たとえば、正規化を行わないと、リクエスト ヘッダー Accept-Language: en-US と Accept-Language: en-US,en;q=0.9 の内容が同一である可能性が高いにもかかわらず、2 つの別々のキャッシュ エントリが生成されます。

クッキー

Cookie はリクエストでは Cookie ヘッダー、レスポンスでは Set-Cookie ヘッダーによって設定されます。通常、このヘッダーを含むサーバー レスポンスはキャッシュに保存されないので、Set-Cookie ヘッダーを不必要に使用しないでください。

パフォーマンス機能

このセクションでは、CDN がコアプロダクトの一部として一般に提供しているパフォーマンス機能について説明します。多くのサイトでは、これらの機能を有効にしていないと、パフォーマンスを容易に向上できません。

圧縮

テキストベースのレスポンスはすべて、gzip または Brotli で圧縮する必要があります。可能であれば、gzip ではなく Brotli を選択します。Brotli は新しい圧縮アルゴリズムであり、gzip と比較して高い圧縮率を達成できます。

Brotli 圧縮に対する CDN サポートには、「送信元からの Brotli」と「自動 Brotli 圧縮」の 2 種類があります。

原点の Brotli

送信元からの Brotli は、送信元で Brotli 圧縮されたリソースを CDN が提供することです。この機能は、すべての CDN ですぐにサポートできるはずの機能ですが、特定の URL に対応するリソースの複数のバージョン（つまり、gzip 圧縮と Brotli 圧縮）を CDN がキャッシュに保存できる必要があります。

Brotli 自動圧縮

自動 Brotli 圧縮では、CDN によってリソースが Brotli 圧縮されます。CDN は、キャッシュに保存可能なリソースとキャッシュに保存できないリソースの両方を圧縮できます。

リソースが最初にリクエストされたときは、「十分な性能」の圧縮を使用して提供されます（例: Brotli-5）。このタイプの圧縮は、キャッシュに保存可能なリソースとキャッシュに保存できないリソースの両方に適用できます。

一方、リソースがキャッシュ可能な場合、CDN はオフライン処理を使用して、より強力でありながらはるかに遅い圧縮レベル（Brotli-11 など）でリソースを圧縮します。この圧縮が完了すると、圧縮後のバージョンがキャッシュに保存され、後続のリクエストに使用されます。

圧縮のベスト プラクティス

パフォーマンスを最大化したいサイトでは、配信元サーバーと CDN の両方で Brotli 圧縮を適用する必要があります。送信元で Brotli 圧縮を行うと、キャッシュから提供できないリソースの転送サイズを最小限に抑えることができます。リクエストの処理の遅延を防ぐために、送信元はかなり控えめな圧縮レベル（Brotli-4 など）を使用して動的リソースを圧縮する必要があります。静的リソースは Brotli-11 を使用して圧縮できます。オリジンが Brotli をサポートしていない場合は、gzip-6 を使用して動的リソースを圧縮できます。gzip-9 を使用して静的リソースを圧縮できます。

TLS 1.3

TLS 1.3 は、HTTPS で使用されている暗号プロトコルである Transport Layer Security（TLS）の最新バージョンです。TLS 1.3 は、TLS 1.2 と比較してプライバシーとパフォーマンスに優れています。

TLS 1.3 では、TLS handshake が 2 回のラウンドトリップから 1 回のラウンドトリップに短縮されます。HTTP/1 または HTTP/2 を使用する接続の場合、TLS handshake を 1 ラウンドトリップに短縮すると、接続設定時間が 33% 短縮されます。

TLS 1.2 handshake と TLS 1.3 handshake の比較

HTTP/2 と HTTP/3

HTTP/2 と HTTP/3 はどちらも、HTTP/1 よりもパフォーマンス上の利点があります。この 2 つのうち、HTTP/3 はパフォーマンス上の大きなメリットを期待できます。HTTP/3 はまだ完全に標準化されていませんが、実現すれば広くサポートされる予定です。

HTTP/2

CDN で HTTP/2 がまだデフォルトで有効になっていない場合は、有効にすることを検討してください。HTTP/2 は、HTTP/1 に比べて複数のパフォーマンス上のメリットを提供し、すべての主要ブラウザでサポートされています。HTTP/2 のパフォーマンス機能には、多重化、ストリームの優先順位付け、ヘッダー圧縮があります。

  • 多重化

    多重化は、間違いなく HTTP/2 の最も重要な機能です。多重化により、1 つの TCP 接続で複数のリクエスト / レスポンスのペアを同時に処理できます。これにより、不必要な接続設定によるオーバーヘッドがなくなります。ブラウザがある時点で開くことができる接続の数が限られていることを考えると、ブラウザがより多くのページのリソースを並列にリクエストできるようになったことを意味します。多重化により、理論的には連結やスプライト シートなどの HTTP/1 最適化が不要になりますが、ファイルが大きいほど圧縮率が向上するため、これらの手法は実際には重要です。

  • ライブ配信の優先順位付け

    多重化は複数のストリームの同時実行を可能にします。ストリームの優先順位付けは、これらの各ストリームの相対的な優先度を通信するためのインターフェースを提供します。これにより、サーバーは最も重要なリソースを最初に送信できるようになります。最初にリクエストされていないリソースも含まれます。

ストリームの優先順位付けは、依存関係ツリーによってブラウザによって表現されます。優先順位のステートメントにすぎません。つまり、サーバーには、ブラウザによって指定された優先順位を満たす（または考慮する）義務はありません。CDN から配信されるサイトが多いほど、ストリームの優先順位付けの効果が高まります。

HTTP/2 リソースの優先順位付けの CDN 実装は、大きく異なります。CDN が HTTP/2 リソースの優先順位付けを完全にサポートしているかどうかを確認するには、HTTP/2 はまだ高速かどうかをご覧ください。

CDN インスタンスを HTTP/2 に切り替えるには、スイッチを切り替える必要がありますが、本番環境で有効にする前に、この変更を徹底的にテストすることが重要です。HTTP/1 と HTTP/2 は、リクエスト ヘッダーとレスポンス ヘッダーに同じ規則を使用しますが、これらの規則が守られていない場合、HTTP/2 の許容性ははるかに低くなります。そのため、HTTP/2 が有効になると、ヘッダーに ASCII 以外の文字や大文字を含めるといった仕様以外の方法でエラーが発生する可能性があります。この場合、ブラウザによるリソースのダウンロードは失敗します。失敗したダウンロードは、DevTools の [Network] タブに表示されます。さらに、「ERR_HTTP2_PROTOCOL_ERROR」というエラー メッセージがコンソールに表示されます。

HTTP/3

HTTP/3 は HTTP/2 の後継です。2020 年 9 月現在、すべての主要なブラウザで HTTP/3 の試験運用版サポートが提供され、一部の CDN はサポートしています。HTTP/2 よりも HTTP/3 の主なメリットはパフォーマンスです。具体的には、HTTP/3 によって接続レベルでのヘッドオブライン ブロッキングがなくなり、接続のセットアップ時間が短縮されます。

  • ヘッドオブライン ブロックの排除

    HTTP/2 で導入された多重化は、1 つの接続を使用して複数のデータ ストリームを同時に転送できる機能です。しかし、HTTP/2 では、1 つのパケットがドロップされると、接続上のすべてのストリームがブロックされます（ヘッドオブライン ブロッキングと呼ばれる現象）。HTTP/3 では、ドロップされたパケットがブロックするストリームは 1 つだけです。この改善は主に、HTTP/3 が TCP ではなく UDP を使用する（HTTP/3 は QUIC 経由で UDP を使用する）ことによるものです。このため、HTTP/3 は輻輳の多いネットワークや損失の多いネットワークを介したデータ転送に特に役立ちます。

HTTP/1、HTTP/2、HTTP/3 のデータ転送の違いを示す図

  • 接続設定時間の短縮

    HTTP/3 は TLS 1.3 を使用しているため、パフォーマンス上の利点があります。新しい接続を確立するために必要なラウンドトリップは 1 回だけで、既存の接続を再開してもラウンドトリップが不要です。

TLS 1.2、TLS 1.3、TLS 1.3 0-RTT、HTTP/3 の接続再開の比較

HTTP/3 は、ネットワーク接続状況が悪いユーザーに最も大きな影響を及ぼします。これは、HTTP/3 が以前のモデルよりもパケットロスの処理性能に優れているだけでなく、レイテンシが高いネットワークでは 0-RTT または 1-RTT 接続の設定による絶対時間の節約が大きくなるためです。

画像の最適化

CDN 画像最適化サービスは通常、画像転送サイズを縮小するために自動的に適用できる画像最適化に重点を置いています。たとえば、EXIF データの削除、可逆圧縮の適用、新しいファイル形式（WebP など）への画像の変換などです。画像は中央値のウェブページ上の転送バイト数の約 50% を占めるため、画像を最適化するとページサイズを大幅に削減できます。

圧縮

圧縮: JavaScript、CSS、HTML から不要な文字を削除します。圧縮は、CDN ではなく送信元サーバーで行うことをおすすめします。サイト所有者は圧縮するコードについてより多くのコンテキストを持っているため、CDN で採用されているものよりも積極的な圧縮技術を使用することが多くあります。ただし、送信元でコードを圧縮できない場合は、CDN による圧縮をおすすめします。

まとめ

  • CDN を使用する: CDN はリソースを迅速に配信し、配信元サーバーの負荷を軽減します。また、トラフィックの急増に対応するのにも役立ちます。
  • 可能な限り積極的にコンテンツをキャッシュに保存する: 静的コンテンツと動的コンテンツはどちらもキャッシュに保存できます。保存期間は異なりますが、サイトを定期的に監査して、コンテンツの最適なキャッシュ保存が行われていることを確認します。
  • CDN パフォーマンス機能を有効にする: Brotli、TLS 1.3、HTTP/2、HTTP/3 などの機能を使用することで、さらにパフォーマンスが向上します。