Fastly で TTFB を短縮して違いを実感

Fastly は最初の1バイトを受信するまでの時間が Akamai の CDN よりも43%、他の CDN よりも32%短く、これはパフォーマンスの全体的な改善を意味します。

CDN の比較は容易ではありません。「どの指標やデータセットを使用すべきか」、「どのサイトを調査対象にすべきか」など、考慮すべきポイントが多数ありますが、私たちはこの挑戦に挑むことにしました。数値を見れば一目瞭然ですが、このブログ記事では採用した比較方法とその理論的根拠を詳しくご説明し、他の CDN に比べて Fastly が高速 (しかもより安全) であることを実証します。

最初の1バイトを受信するまでの時間

TTFB は、利用状況を示す実際のデータの中で、データを多くのサイトで配信する CDN に直接起因する****唯一測定可能な指標です。最大コンテンツの描画 (LCP) を含む他の指標は、クライアント側の JavaScript の実行や不適切なWebサイトの設定、サードパーティコンテンツの埋め込みなどの影響を受けます。さらに、ドメインと最初の1バイトを配信する CDN とは別の CDN (単数または複数) がコンテンツ配信の他の部分で使用される可能性があるマルチ CDN 環境も考慮する必要があります。最初の1バイトの配信スピードを表す TTFB と同様に、その後に配信されたコンテンツの配信スピードを特定の CDN に起因させるメソッドは存在しません。 

通常は「今回はこの CDN によってコンテンツが配信され、次は別の CDN によって配信される」というのではなく、大規模な組織 (Fortune 500 に入る企業など) はマルチ CDN 環境を採用し、コンテンツの種類によって異なる CDN が使用されるケースが多いのです。動画、画像、その他の種類のコンテンツがそれぞれ別の CDN によって配信されることがあります。このようなサイトにユーザーがアクセスすると、マルチ CDN 体験が提供されるわけですが、これによって LCP パフォーマンスが影響を受けます。こうしたメトリクスを適切に抽出するのは不可能です。 

しかし、Fastly で得られる TTFB のメリットが、関連する LCP パフォーマンスにもプラスの影響をもたらしていることを確かめるため、さらに踏み込んでデータを確認したところ、プラスの効果がみられました！この点については後ほど詳しく解説しますが、Fastly によるパフォーマンス上のメリット (Akamai の CDN よりも43%、他の CDN よりも32%パフォーマンスが高い) は異常値ではなく、また他のパフォーマンス特性の犠牲の上に成り立っているものでもなく、むしろ LCP パフォーマンスにも大きなメリットをもたらしていました。 

この点について調べる最適な方法は、実際のブラウザを使用して世界中の実際のユーザーから収集されたデータを確認することです。幸い、Google の Chrome User Experience Report (CrUX) とデータセットのおかげで、TTFB を確認して調査を行うことができました。

CrUX データセットを選んだ理由

CrUX は Google による Web Vitals プログラムの公式データセットです。同プログラムは Web で優れたユーザーエクスペリエンスを提供するために重要と思われる品質シグナルの統合ガイドを提供する Google の取り組みの一環です。簡単に説明すると、Google はこのプログラムを通じて重要と思われる品質、それらの測定方法、「優れたパフォーマンス」の定義を共有しています。このガイドを参考にすることで、サイト管理者はサイトのパフォーマンスを改善し、Google ランキングにおけるスコア向上や SEO パフォーマンスの強化 (およびその結果としてもたらされるトラフィックの増加) といった形で Google から恩恵を受けるには何を目指すべきかを把握することができます。 

世界中の Chrome ユーザーから収集されたデータは、合成的なものではなく、Webサイトを訪問したユーザーの実際のエクスペリエンスを反映しているといえます。データは経時的に実際のユーザーから収集されたものです。このような実世界のデータは、高いキャッシュヒット率 (CHR) やサーバーの近接性、ルーティングの最適化、効率的なロードバランシングなどによってWebサイトのパフォーマンスがどのように改善されるかをより正確に表しています。世界中の異なる地域から、トラフィックのピーク時と最低時を含む、さまざまな日時にデータが集計されることで、その時々においてサイトが負荷をどのように処理しているかを示すパフォーマンスを把握できるためです。これにより、自らテストをセットアップせず、すなわちコントロールできない環境で何が起きているか、実世界で自社のサイトをユーザーがどのように体験しているかを理解することができます。また CrUX には、使いやすい API を利用できるというメリットもあり、一定期間に何度も関連するデータのクエリを行うことが可能です。大量のデータに基づいているので、信頼性の高い情報が得られます。 

TTFB 自体、Google の Web Vitals の指標のひとつです。しかし、他の CrUX Web Vitals データと一緒に収集されるのにもかかわらず、TTFB は Google の「Core Web Vitals」に含まれていません。つまり、TTFB パフォーマンスが Google の推奨範囲外であっても、そのために Google によってサイトのスコアにペナルティが課されることはありません。上述の理由により、Google では LCP などの指標が評価されますが、高速で安定した TTFB もサイトパフォーマンスにおいて非常に重要です。TTFB は LCP に先行するため、LCP に影響します。つまり Google は LCP を測定することで、TTFB パフォーマンスを含むその他の重要な指標も同時に考慮に入れているのです。大切なポイントは、他の指標を利用できない場合、TTFB は注目に値する指標であるということです。 

CrUX データに関する注意事項

CrUX データセットでは TTFB や LCP などの指標の数値が75パーセンタイル値として提供されます。すなわち、過去28日間における上位75%のユーザーの測定値の最低値が使用されます。これは、サイトパフォーマンスをより正確に把握するために極端に悪いスコアが排除されるためです。サイトによるコントロールが不可能な要因などによる影響を抑えるために、Web Vitals の指標では下位25%の結果が除外されるのです。この下位のデータには、非常に遅いインターネット接続やデバイスのスローダウンなど、読み込み時間に影響する一時的な問題に関係するユーザーエクスペリエンスが含まれる可能性があり、このような問題のせいでサイトのパフォーマンススコアが損なわれるべきではありません。最下位の25パーセンタイルを除外することで、Google は測定結果が異常値によって歪められたものではなく、サイトの実際のパフォーマンスをより正確に表していると確信することができるのです。 

なお、データは Chrome ブラウザでのみ収集され、iOS は対象外です。この条件下でも非常に多様なエクスペリエンスがカバーされますが、モバイルサイトに関しては Android デバイスを使用する Chrome ユーザーのデータに限られます。これは、iOS ではアプリにおけるデータ収集が制限されているためです。デスクトップサイトの場合、Chrome ブラウザからのデータに限られますが (Firefox、Safari、Edge などその他のブラウザは対象外)、MacOS や Windows、Linux を含むあらゆるデスクトッププラットフォームが含まれます。また、中国からのトラフィックやデータは含まれません。 

しかし、iOS や中国のユーザーのエクスペリエンスが反映されていないトレードオフを考慮しても、CrUX が提供する実世界のデータには価値があると私たちは確信しています。さらに、TTFB はブラウザが最初の1バイトを受信するまでの時間であるため、デバイスやブラウザの種類が TTFB に大きな影響をもたらすとは考えにくく、iOS と他のブラウザにおけるパフォーマンスの差は、完全に同じではなくても、大差はないと思われます。

CrUX データに含まれるユーザーに関する Google のデータ収集方法について詳しくはこちらをご覧ください : https://developer.chrome.com/docs/crux/methodology/#user-eligibility 

Fortune 500 を選んだ理由

多様な業種・業界の組織を含むことがきわめて重要であることを私たちは認識していました。同時に、大規模な組織、複雑な Web エクスペリエンス、組織のデジタルプレゼンスにおける目標達成に必要なユースケースを反映したデータも含めたいと考えました。そこでまず、Fortune 500 の企業から着手しました。Fortune 500 はあらゆる業種・業界を含む、総収入に基づく全米企業ランキングの上位500社を意味し、これらの大企業は自社サイトに対してさまざまに異なるニーズや目標を抱えています。これらの組織は大規模かつ複雑で、それに見合った大規模かつ複雑なデジタルプレゼンスを確立していることが多く、そのような環境では、個人や地域規模の企業のWebサイトに比べ、日々のビジネスにおいて CDN が果たす役割の重要性が高い可能性があります。Fortune 500 社のドメインリストを入手するため、10月17日にこちらのサイトからリストを取得しました。私たちはこの調査で使用したリソースに誰もがアクセスできるようにしたいと考えました。Fortune の公式リストは有料であったため、このように別のサイトで公開されたリストを使用しました。

最初の1バイトを配信した CDN の特定方法

Fortune 500 の企業から着手することに決めた後、私たちは社内の CDN 検出ツールを使用し、2023年10月17日午後11時19分から2023年10月18日午後4時7分にかけて、各オリジンに対して20回ずつ検出を実行しました。各検出で Google のパブリック DNS サーバーにクエリを行い、オリジンに HTTP リクエストを送信し、既知のプロバイダーと値の設定ファイルと以下の内容を照らし合わせて CDN を検出しました。 

• HTTP レスポンスヘッダー (サーバー、X-cache など)

• CNAME レコード (*.fastly.net, *.edgekey.net など)

• IP アドレスと AS 番号のマッピング

私たちは、オリジンのホスト名に複数の CDN が使用されている2つのWebサイトのオリジンに遭遇しました。このような環境では、リクエストによって最初の1バイトが異なる CDN によって配信される可能性があるため、これらは分析の対象外としました。さらに、ヘッダーを待つ間、60秒のタイムアウト制限を超えた35件のWebサイトのオリジンも排除しました。(このうち、34件のWebサイトのオリジンが Akamai 経由で配信し、残りのひとつは CDN を使用していませんでした。これらを分析に含めていたら、Fastly は Akamai の CDN に比べて46%、その他の CDN に比べて34%パフォーマンスが高くなり、Fastly の優位性がより明確に示されたでしょう。) 

Fastly による TTFB の短縮 = Fastly による LCP パフォーマンスの向上

結果の信頼性を高めるため、TTFB パフォーマンス (Fastly と Akamai およびその他の CDN の比較) と LCP パフォーマンス (Fastly と Akamai およびその他の CDN の比較) の関係についても調べ、Fastly のより優れた TTFB パフォーマンスにより、Fastly のお客様は LCP を含むその他の指標においてもパフォーマンス上のメリットを得ている可能性が高いことを確認しました。企業が LCP や全体の読み込み時間を犠牲にして TTFB を改善するメソッドを使用している場合は、両指標の比較でそれが分かります。また、このような比較により、Fastly のパフォーマンス上の優位性が TTFB に限られ、LCP に関しては他のCDN より劣るかどうかも確認できます。結果から言うと、LCP においても Fastly は Akamai に比べて大幅にパフォーマンスが優れていることが判明しました。LCP では、Akamai は Fastly よりも21%遅く、Fastly 以外の全 CDN の平均も Fastly より7%遅いという結果が得られました。

Fortune 500 のリストは、多くの企業がマルチ CDN 環境をデプロイしていることを考えるとサンプルが小さすぎ、効果的に LCP のパフォーマンスを確認するのが困難です。複数の CDN が使用されている場合、それらによって達成された LCP スコアをひとつの CDN に起因させることができないためです。サイトを比較できるのは、「フルサイトデプロイ」が採用されている、すなわち単一の CDN によってドメインとそのすべてのコンテンツが配信されている場合のみです。しかし Fortune 500 の企業のうち、フルサイト配信を採用している企業はごくわずかです。そこで、より多くのデータセットを使用してテストを行うことにしました。CrUX の上位1万サイトを取り上げ、上記の CDN 検出メソッドを使用して24時間の時間枠で CDN を検出するリクエストを20回実行しました。そして、ドメインやアセットのプロバイダーのすべてが単一の CDN から返される場合、そのサイトはその CDN を使用してフルサイト配信を行っているとみなされました。ただし、このように大きなデータセットを使用しても、単一 CDN によるフルサイト配信を行っていると確信できたドメインは、Fastly の場合176件、Akamai の場合はその3倍を若干超えた程度でした。

このリストをもとに、単一 CDN によるフルサイト配信を行っているドメインの LCP パフォーマンスを求めて CrUX API にクエリを行い、(このデータで確認された) Fastly がもたらす TTFB パフォーマンスにおけるメリットと、Fastly による LCP パフォーマンスの差との関係性について調べました。その結果、Fastly のフルサイト配信によって LCP においても大幅なパフォーマンス上の優位性がみられ、Akamai の CDN よりも21%、他の CDN よりも7%高いパフォーマンスが観測されました。

結果の詳細

以下の集約されたそれぞれの値は、各 CDN を使用する全Webサイトのオリジンに関する75パーセンタイルスコアの平均値を示しています。

Fortune 500 Webサイトのオリジン (ドメインプロバイダー)

Fastly 経由で配信しているオリジンの数 : 25

• TTFB : 843.0ミリ秒

Akamai 経由で配信しているオリジンの数 : 116

• TTFB : 1208.4ミリ秒 (Fastly よりも365.4ミリ秒 (43%) 遅い)

Fastly 以外の CDN で配信しているオリジンの数 : 354

• TTFB : 1111.3ミリ秒 (Fastly よりも268.3ミリ秒 (32%) 遅い)

CrUX における上位1万のオリジン (フルサイト配信)

Fastly 経由で配信しているオリジンの数 : 176

• LCP : 2274.3ミリ秒

Akamai 経由で配信しているオリジンの数 : 555

• LCP : 2757.8ミリ秒 (Fastly よりも483.5ミリ秒 (21%) 遅い)

Fastly 以外の CDN で配信しているオリジンの数 : 5741

• LCP : 2444.7ミリ秒 (Fastly よりも170.4ミリ秒 (7%) 遅い)