最初の1バイトの配信速度において無敵の Fastly

11月2日のブログ記事</u>で、 Akamai の CDN に対する Fastly の優位性についてご紹介したばかりですが、今回新たに取得したデータでは、Edgio CDN に比べて Fastly の TTFB が29%も高速であることが判明しました。この記事では、この指標がパフォーマンス全体の優位性を反映している理由をご説明します。

前回の記事でも触れたように、CDN のパフォーマンス比較は複雑です。使用する指標やデータセット、調査対象のサイトなど、考慮すべき重要なポイントが多数あります。Fastly に移行することでサイトが高速化する (しかも安全性も高まる</u>) ことをご理解いただけるよう、以下で比較方法とその理由について細かく解説します。

十分なデータ量の確保

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

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

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

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

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

CrUX は Google による Web Vitals</u> プログラムの公式データセットです。同プログラムは 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 は LCP の前の段階の測定値で、LCP にも影響を及ぼすため、高速で安定した TTFB はサイトパフォーマンスにおいて非常に重要です。つまり 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</u> 

CrUX リストを選んだ理由

前回のブログ記事でご説明したように、Akamai の TTFB テストでは、Fortune 500 のリストをデータセットとして使用しました。しかし今回のテストでは、Fortune 500 の企業のうち、最初の1バイトの配信に Edgio を使用している企業はごくわずかであることが判明しました。これにより、データに歪が生じるリスクが発生します。そこで、人気の高いWebサイトのパフォーマンスを正確に反映したデータが得られるよう、CrUX リストに切り替えました。当初は最も人気の高い1万件のWebサイトを対象にしていましたが、後に5万件に拡大しました。これは、平均の比較を行うのに十分な Edgio のサンプルデータを取得するためです。最後に、今回の調査では非常に遅いWebサイトによる歪みを排除するため、中央値を使用することにしました。

(サードパーティによる正確さの評価を含む、CrUX リストに関する詳細については、https://zakird.com/papers/toplists.pdf</u> をご参照ください)

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

2023年12月1日午後6時13分から2023年12月4日午前10時27分にかけて、Fastly 独自の CDN 検出ツールを使用し、各オリジンに対して8回の検出を実行しました。各検出で Google のパブリック DNS サーバーにクエリを行い、既知のプロバイダーと値の設定ファイルと以下の内容を照らし合わせて CDN を検出しました。 

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

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

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

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

重要なのはスピード

オンライン訪問者が遅延を経験すると、ロイヤルティなどに大きな害をもたらすことが、これまでに何度も実証されています。例えば、ショッピングカートの放棄といった重大なリスクを招きます。

読者や買い物客など、サイトのユーザーにデータが配信されるスピードによってインタラクションの成否が決まる可能性があるのです。幸い、(上記で証明されているように) CDN の選択次第でサイトの配信速度を大幅に加速できます。

Fastly はまさに「スピード」を体現しています。私たちは今後も高速化に努め、最先端の CDN に切り替えることで得られる競争上の優位性を証明していきたいと思います。

結果の詳細

以下の集約されたそれぞれの値は、各 CDN を使用する全Webサイトのオリジンに関する75パーセンタイルスコアの平均値を示しています (Fastly : 2023年11月5日-2023年12月2日、Edgio : 2023年11月7日-2023年12月4日)。

CrUX トップ5万オリジン (ドメインプロバイダー)

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

• TTFB: 554ミリ秒

• LCP: 1994ミリ秒

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

• TTFB : 713ミリ秒 (Fastly よりも159ミリ秒 (29%) 遅い)

• LCP : 2426ミリ秒 (Fastly よりも432ミリ秒 (22%) 遅い)