ユーザーがWebページを訪問するたびに、できるだけ早くコンテンツを受信できるようにするための競争が始まっています。パフォーマンスは、訪問者とサイトのインタラクションに影響を与える重要な要素です。コンテンツを世界中に移動させるとかなりの遅延が発生するという考えもあるかもしれませんが、今から一定期間、ネットワーク転送速度は理論上の限界に近づきます。つまり、Cloudflare上のデータはニューヨークとロンドンの間の往復11,000キロを、まばたき1回分より速い約76ミリ秒で横断することができるのです。
しかし、リクエスト、レスポンス、設定の処理が複雑であるため、Webページの読み込みの遅延が常に発生しています。接続の確立、圧縮、ハードウェア、ソフトウェアの進歩を推進することに加え、訪問者が特定のWebページとどのように対話するかを予測することで、Cloudflareはページ読み込みの遅延を減らす新しい方法を構築しました。
本日私たちは、最新のスピードの飛躍的な向上に関する最新情報としてSpeed Brainを発泡でき、嬉しく思います。これは、Speculation Rules APIを使用して、ユーザーの次のナビゲーションの可能性が高いコンテンツをプリフェッチします。Speed Brainの主な目標は、ユーザーがWebページに移動する前にブラウザキャッシュにWebページをダウンロードし、実際のナビゲーションが行われたときにページがほぼ瞬時に読み込まれるようにすることです。
初期のアプローチではユーザーがタッチやクリックイベントを開始した時に、次のページの静的コンテンツをプリフェッチする保守的なモデルを採用していました。2024年第4四半期から2025年にかけて、より高速なエクスペリエンスを実現する、投機的プリレンダリング（ナビゲーションが起こる前にページをフェッチするだけでなく、完全にレンダリングする）などの積極的な投機モデルを提供する予定です。最終的に、Speed Brainは設定をすることなく静的なWebサイトの遅延を排除する方法を学習し、ブラウザと連携して可能な限り高速に読み込む方法を学習します。
これをより詳しく説明するために、衣料品を販売するeコマースWebサイトを想像してみてください。当社のグローバルリクエストログから得たインサイトを用いて、典型的な訪問者が親ページで「男性 > 衣料品」を閲覧する際に「シャツ」をクリックする可能性が高いことを、高い精度で予測できます。これに基づき、購入者が「シャツ」リンクをクリックする前に、画像などの静的コンテンツの配信を開始することができ、クリックすれば必然的にページが瞬時に読み込まれます。アグレッシブローディングモデルの実装を最近行った機関テストでは、LCP（Largest Contentful Paint）が75%も短縮されたことが示されました。LCPは、最大の可視要素（画像、動画、テキストブロックなど）をブラウザに読み込んでレンダリングするのにかかる時間です。
Speed Brainの最大の利点は、すべてのプランタイプですぐにかつ無料でご利用いただけることです。ダッシュボードまたはAPIからWebサイトでSpeed Brain機能を切り替えるだけです。一見魔法のように見えますが、この舞台裏では賢いエンジニアリングが行われています。
すでに、すべての無料ドメインでデフォルトでSpeed Brainが有効にになっており、プリフェッチの成功時にLCPが45%削減されています。Pro、Business、およびEnterpriseプランのドメインはSpeed Brainを手動で有効にする必要があります。まだ実行していない方は、ダッシュボードでReal User Measurements（RUM）も有効にすることを強くお勧めします。これにより、新しく改善されたWebページのパフォーマンスを確認できます。さらに、ドメインでRUMを有効にすることで、近い将来、お客様にWebサイトで改善され、カスタマイズされたWebサイトプリフェッチングおよびプリレンダリングルールを提供する予定です。
一目でわかるブラウザの仕組み
Speed Brainがどのようにコンテンツを極めて高速に読み込むかを説明する前に、ブラウザでのコンテンツ読み込みの複雑さを一歩下がって確認してみましょう。ユーザーがWebページに移動するたびに、一連のリクエストとレスポンスのサイクルを完了する必要があります。
ブラウザは、サーバーとの安全な接続を確立した後、Webページのベースドキュメントを取得するためにHTTPリクエストを送信します。サーバーはリクエストを処理し、必要なHTMLドキュメントを構築して、レスポンスとしてブラウザに送り返します。
ブラウザはHTMLドキュメントを受け取ると、すぐにコンテンツの解析を開始します。その際、CSSファイル、JavaScript、画像、フォントなどの外部リソースへの参照が必要になることがあります。これらのサブリソースは、ページを正しく表示するために不可欠であるため、ブラウザはこれらを取得するために追加のHTTPリクエストを発行します。ただし、これらのリソースがブラウザのキャッシュで利用可能な場合、ブラウザはローカルで情報を取得できるため、ネットワークの遅延が大幅に削減され、ページ読み込み時間が改善されます。
ブラウザがHTML、CSS、JavaScriptを処理すると、レンダリングエンジンが画面上にコンテンツを表示し始めます。ページの視覚的要素が表示されると、リンクをクリックするなどのユーザー操作により、ブラウザは次のページの新しいコンテンツを取得するためにこのプロセスの多くを再起動するように要求されます。このワークフローは、すべてのブラウジングセッションで典型的なものであり、ユーザーがページを移動するにつれて、ブラウザは新しいリソースまたはキャッシュされていないリソースを継続的に取得およびレンダリングするため、新しいページが完全に読み込まれるまでに遅延が生じます。
では、上述のショッピングサイトでページを移動するユーザーを例に挙げてみましょう。購入者がホームページからサイトの「男性」セクション、「衣料品」セクション、「シャツ」セクションへと移動すると、それ以降の各ページを取得するのに費やす時間が蓄積され、取引が完了する前に購入者がサイトを離れる原因となります。
各リンクがクリックされた時にプリフェッチされプリレンダリングされたページがブラウザに存在していれば、ネットワーク遅延の影響の多くを取り除くことができ、ブラウザはコンテンツを瞬時に読み込むことができ、よりスムーズなユーザーエクスペリエンスを提供することができます。
ですが、以前にもこの話を聞いたことがあるかもしれません。そこからどうやってSpeed Brainにつながるのでしょうか？
私たちは、お客様が何を考えているかをわかっています。何年もプリフェッチングは行われてきています。過去には、投機的なプリフェッチングがいくつか行われたこともあります。こうした話を以前から耳にしたことがあるかもしれません。では、どのような違いがあるのでしょうか？
お客様の認識は正しいです。長年にわたり、開発者やブラウザベンダーは、ページ読み込み時間を最適化し、 Web全体のユーザーエクスペリエンスを向上させるために絶え間ない努力を続けてきました。ネットワーク層接続の最適化からクライアントにより近いアプリケーションコンテンツのプリロードまで、インターネットスタックのさまざまな層にまたがる数多くの技術が開発されてきました。
初期のプリフェッチ：データと柔軟性の欠如
Webプリフェッチングは10年以上前から存在する技術の1つです。これは、特定のサブリソースが近い将来必要になる可能性が高いという前提に基づいています。したがって、それらを積極的に取得しない理由は何でしょうか？これには、HTMLページから画像、スタイルシート、スクリプトまで、ユーザーがWebサイトを移動する際に必要とするものが含まれます。実際、長年にわたってコンピュータサイエンスのさまざまな分野で使用されてきた一般的な技術であり、その主要な例としてCPUにおける分岐予測が挙げられるため、投機的実行のコアコンセプトは新しいものではありません。
Webの黎明期には、パフォーマンスを向上させるためにいくつかのカスタムプリフェッチソリューションが登場しました。たとえば、2005年にGoogleは、ブロードバンドユーザーのブラウジングの高速化を目的としたクライアント側のアプリケーションであるGoogle Web Acceleratorを導入しました。革新的ではありましたが、プライバシーと互換性の問題のために短命に終わりました（Speed Brainがどのように異なるかについては後述します）。当時の予測プリフェッチングには、ユーザーの挙動、特に削除や購入のような機密性の高いアクションをキャプチャするためのデータインサイトやAPIサポートが欠けていました。
静的リストと手作業
従来、プリフェッチングはリソースヒントの一つとして<link rel="prefetch">属性を使用することで実現されてきました。開発者は、ブラウザにプリエンプティブにフェッチしてメモリにキャッシュさせたいリソースごと、ページごとに手動で属性を指定しなければなりませんでした。この手作業は面倒であるだけでなく、どのリソースをプリフェッチすべきかについてインサイトが得られないことが多く、そのために特定のヒントの質が低下していました。
同様に、Cloudflareは2015年からURLのプリフェッチング機能を提供しています。ブラウザキャッシュでプリフェッチする代わりに、Cloudflareではお客様がリソースの静的リストをCDNキャッシュにプリフェッチすることを許可しています。この機能を使用することで、リソースが実際に必要になる前にアイドルタイムやネットワークの状態が良好であるときに事前にリソースをプリフェッチすることができます。ただし、お客様は所有する各ページについて、どのリソースがプリフェッチするのに良い候補かを手動で判断する必要があるため、 CDNプリフェッチの際にも同様の懸念がページに起こります。設定を誤ると、静的リンクのプリフェッチが足かせになる可能性があり、Webページの読み込み時間が遅くなる原因となることもあります。
server pushとその苦労
HTTP/2の「server push」は、リクエストされる前にクライアントにリソースをプッシュすることでWebパフォーマンスを向上させるもう1つの試みでした。理論的には、これにより将来のアセットのための追加のラウンドトリップが必要がなくなるため、遅延が削減されます。しかし、リソースをクライアントに「プッシュ」するというサーバー中心の指示は、主にブラウザですでにキャッシュされたものが考慮されていなかったことによって大きな問題を引き起こしました。これにより、帯域幅が消費されただけでなく、ページをレンダリングするときにブラウザがフェッチする際に競合状態が発生するため、ベースのHTMLやCSSなどの重要なリソースの配信が遅くなる可能性がありました。提案されたcache digestというソリューションは、クライアントのキャッシュの内容をサーバーに知らせるものでしたが、実装が広く普及することはなく、サーバーはやみくもにリソースをプッシュすることになりました。2022年10月、Google ChromeはServer Pushのサポートを終了しし、2024年9月にFirefoxもこれに追随しました。
Early Hintsで前進
後継として、Early Hintsが2017年に登場しましたが、当社がブラウザおよび主要顧客と提携し、導入を決定した2022年まで広く採用されませんでした。これは、どのリソースを読み込むか、クライアントに「ヒント」を提供することで、より効率的な代替手段を提供し、ブラウザが必要とするものに基づいてより良い優先順位付けを可能にします。具体的には、サーバーは、メインレスポンスの準備を行っている間に、ブラウザが読み込みを開始すべき主要なページアセットのリストとともに103 Early Hints HTTPステータスコードを送信します。これにより、ブラウザは重要なリソースの取得をいち早く開始し、アセットがすでにキャッシュされている場合、冗長なプリロードを回避できます。Early Hintsはユーザーの挙動や動的なページ条件にはまだ対応しておらず、その使用は主にWebページ全部ではなく特定のアセットのプリロードに限定され、特に、HTMLを生成するためのサーバーの「思考時間」が長い場合に適用されます。
Webが進化するにつれて、投機的実行によるパフォーマンスの向上とエンドユーザーにとっての潜在的な欠点のバランスを取るために、複雑で動的なユーザーインタラクションを処理できるツールがますます重要になってきました。長年にわたり、CloudflareではArgo Smart Routing、Smart Tiered Cache、Smart Placementなど、ユーザーの挙動に適応し、インターネット全体の速度と正確性の決定のバランスを取るために機能するパフォーマンスベースのソリューションを提供してきました。本日、Cloudflareは、コンテンツの超高速配信を実現するための適応性の高いフレームワークに向けて、新たな一歩を踏み出します。
Speed Brainが他社と異なる点
Speed Brainは、サーバーから返されたルールセットに基づいて、ブラウザ内で直接予測プリフェッチング戦略を実装する堅牢なアプローチを提供します。以前の試みから学んだことを基に、リソース予測の責任をクライアントに移し、ユーザーインタラクションであるリンクのホバーリングなどとそのデバイス機能に基づく、より動的でパーソナライズされた最適化を可能にします。ブラウザは、次のWebページがユーザーによってリクエストされるのをただ待つのではなく、ユーザーがページとどのようにやり取りしているかを見越して、ユーザーがリンクをクリックし終わる前に次のWebページページをリクエストし始めます。
舞台裏では、この魔法のすべてを可能にしているのが、GoogleによるWebパフォーマンス分野における新たな標準であるSpeculation Rules APIです。 CloudflareのSpeed Brain機能を有効にすると、Speculation-Rulesと呼ばれるHTTPヘッダーがWebページレスポンスに追加されます。このヘッダーの値は、指定されたルール設定をホストするURLです。この設定は、今後のナビゲーションのためのプリフェッチリクエストを開始するようブラウザに指示します。Speed Brainは、Webサイトでアクセスされた最初のページの読み込み時間を改善しませんが、同じWebサイトにアクセスされたそれ以降のWebページの読み込み時間を改善します。
アイデアは十分にシンプルに見えますが、プリフェッチングには問題が伴います。プリフェッチされたコンテンツは最終的に使用されない可能性があるからです。Speed Brainの最初のリリースで、私たちは、以前の投機的な取り組みを制限した2つの重要ながら異なる問題、つまり、古いプリフェッチ設定と誤ったプリフェッチに対処できる機能を備えたソリューションを開発しました。この初期リリースのために選択したSpeculation Rules API構成は、サイト全体にルールを広く適用可能に保ちながら、プリフェッチングの安全性のバランスをとるために慎重に設計されています。
古いプリフェッチ設定
Webサイトは時間の経過とともに必然的に変化するため、静的プリフェッチ設定は時代遅れになり、非効率または非効果的なプリフェッチにつながります。これは、rel=prefetch属性や静的CDNプリフェッチURLセットのような手法に特に当てはまり、こうした手法はWebサイトの各ページに関連するプリフェッチ可能なURLリストを手動で維持する必要がありました。ほとんどの静的プリフェッチリストは、実際のユーザーナビゲーションデータではなく、開発者の直感に基づいているもので、重要なプリフェッチの機会を見逃したり、不要なプリフェッチにリソースを浪費したりする可能性があります。
誤ったプリフェッチ
プリフェッチリクエストは、「sec-purpose」HTTPリクエストヘッダーがある以外は通常のリクエストと同じなので、クライアント、ネットワーク、サーバーで同じオーバーヘッドが生じます。ただし、決定的な違いは、プリフェッチリクエストはユーザーの行動を予測するため、レスポンスは最終的に使用されない可能性があり、そのオーバーヘッドがすべて無駄になる可能性があることです。このため、プリフェッチの精度は非常に重要になります。つまり、プリフェッチされたページがユーザーによって閲覧される割合を最大化することが重要です。不適切なプリフェッチングは、リクエストされていないリソースをキャッシングしたり、帯域幅やネットワークリソースを浪費したりするなど、非効率や不要なコストにつながる可能性があります。これは、従量制のモバイルネットワークや帯域幅の少ない環境では特に重要なことです。
ガードレール
Speed Brainの最初のリリースで、Cloudflareは古いプリフェッチ設定の可能性を完全に排除し、誤ったプリフェッチングのリスクを最小限に抑える、重要な悪影響防止ガードレールを備えたソリューションを設計しました。この専用の設定は、Speculation Rules APIからdocumentルールおよびeagernessを設定することによって実現されます。当社が選んだ設定は以下の通りです。
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*", "relative_to": "document" },
]
},
"eagerness": "conservative"
}]
}
Documentルール
"source": "document"と設定内の"where"キーで示されるDocumentルールにより、Webページ全体に動的にプリフェッチングを適用することができます。これにより、プリフェッチするための事前定義された静的URLリストは必要なくなり、プリフェッチの候補リンクはアクティブなページ構造に基づいて決定されるため、古いプリフェッチ設定の問題は排除されます。
where句で"relative_to": "document"を使うことで、プリフェッチングを同一サイトリンクに制限するようブラウザに指示しています。これには、Cloudflareの実装がクロスオリジンプリフェッチを回避することで、Web上でユーザーを追跡することがないため、ユーザーのプライバシーへの影響を避けることができるという利点もあります。
Eagerness
Eagernessは、ブラウザがコンテンツをプリフェッチする程度を制御します。次の4つの設定が可能です。
immediate：ページ読み込み時にできるだけ早く使用されます。通常、ルール値がブラウザで見られるとすぐに、次のページのプリフェッチが開始されます。
eager：上記のimmediate設定と同様ですが、プリフェッチトリガーはさらにリンクに向けてブラウザを移動させることなどわずかなユーザーインタラクションイベントに依存します（近日実装予定）。
moderate：リンク上でポインターを200ミリ秒以上保持する場合や、先にpointerdownイベントがあったり、ホバーイベントがないモバイルではプリフェッチされます。
conservative：ポインターまたはリンクのタッチダウンでプリフェッチします。
Speed Brainの初期リリースは、Webサイトを著しく高速化しながら、意図しないリソースの浪費につながる可能性のある誤ったプリフェッチのリスクを最小限に抑えるために、保守的なeagerness値を利用します。より積極的なeagerness設定ほどパフォーマンス向上の可能性は損なわれるため、ユーザーの安全性を優先するためこの慎重なアプローチを選択しました。今後は、より自由な設定の恩恵を受けられるサイトに治して、より動的なeagerness設定の搭載を予定しています。また、プリレンダリングを含めるためにルールを拡張する予定です。
Cloudflareが実装するもう1つの重要な保護措置は、 CDNキャッシュにすでに保存されている静的コンテンツのプリフェッチリクエストだけを受け入れることです。コンテンツがキャッシュにない場合、プリフェッチリクエストは拒否されます。プリフェッチリクエストのためにCDNキャッシュから直接コンテンツを取得することで、キャッシュの適格性に関する懸念を回避することができます。この理由は明白です。ページがキャッシングの対象でない場合、意図しない結果や配信元負荷の増加につながる可能性があるため、ブラウザキャッシュでプリフェッチされることは避けたいからです。例えば、ログアウトページをプリフェッチすると、ユーザーが実際にアクションを完了する前に早くログアウトする可能性があります。ステートフルなプリフェッチまたはプリレンダリングリクエストは予測不可能な影響を与える可能性があり、クライアントが確認していないアクションについてはサーバーの状態が変化する可能性があります。すでにCDNキャッシュに保存されているページのプリフェッチのみを許可することで、それらのページがユーザーエクスペリエンスに悪影響を与えない可能性が高くなります。
これらのガードレールは、パフォーマンスが重視される環境で機能するように実装されました。2024年7月初旬にCloudflareの開発者向けドキュメント全体のすべてのページに対する保守的なデプロイメントモデルの影響を測定しました。その測定により、正しいコンテンツ、つまり実際にユーザーがナビゲートするコンテンツを94%の確率でプリフェッチできることがわかりました。これは、意図しない悪影響を引き起こすことなく、p75分位でのLCPを40%減らすことにより、ナビゲーションのパフォーマンスの改善につながりました。これによりすばらしい結果が得られました。
Cloudflareの実装
当社のグローバルネットワークは330以上の都市に広がり、インターネット人口の95%で50ミリ秒以内のサービスを提供しています。この広範なリーチにより、お客様のためにキャッシュ可能なアセットのパフォーマンスを大幅に向上させることができます。Speed Brainでのスマートなプリフェッチングにこのネットワークを活用することで、CloudflareはプリフェッチされたコンテンツをCDNキャッシュから直接提供でき、ネットワークの遅延をほぼ瞬時の状態まで削減できます。
ネットワークにおける当社の独自のポジションは、お客様が配信元サーバーの構成を変更することなく、Speed Brainを自動的に有効にすることを可能にします。それは、スイッチを切り替える程度の簡単さです。Speed Brainの最初のバージョンが現在公開されています。
Speed Brainが有効になっているWebページのリクエストを受信すると、Cloudflareサーバーは、追加の「Speculation-Rules」HTTPレスポンスヘッダーを返します。このヘッダーの値は、指定されたルール設定上記の通りをホストするURLです。
ブラウザがレスポンスヘッダーの解析を開始すると、Speculation-Rules設定を取得し、Webページの一部として読み込みます。
この設定は、訪問者のページとのエンゲージメントの程度に基づいて、訪問者が移動する可能性のあるCloudflareのページをプリフェッチするタイミングの指針をブラウザに提供するものです。
ユーザーのアクション（次のページリンク上のマウスダウンイベントなど）によりRulesアプリケーションがトリガーされると、ブラウザは「sec-purpose: prefetch」HTTPリクエストヘッダーと共にそのページのプリフェッチリクエストを送信します。
サーバーはリクエストヘッダーを解析して、プリフェッチリクエストを識別します。リクエストされたコンテンツがキャッシュに存在する場合は、それを返します。そうでない場合は、503 HTTPステータスコードが返され、プリフェッチリクエストが拒否されます。これにより、プリフェッチングを認識していない配信元やCloudflare Workersにリクエストを送信することによる安全でない悪影響のリスクを排除することができます。キャッシュだけに存在するコンテンツのみが返されます。
成功のレスポンスが発生すると、ブラウザは正常にコンテンツをメモリにプリフェッチします。訪問者がそのページに移動すると、ブラウザはブラウザのキャッシュからWebページを直接読み込み、すぐにレンダリングします。
一般的なトラブルシューティングのパターン
Speed Brainのサポートは、新たなWeb標準であるSpeculation Rules APIに依存しています。2024年9月現在、この新しい標準のサポートはGoogle ChromeやMicrosoft EdgeなどのChromiumベースのブラウザバージョン121以降に限定されています。WebコミュニティがAPI標準化についてコンセンサスを得るのに伴い、他のブラウザベンダーにも普及が広がることを期待しています。
プリフェッチンぐは動的コンテンツには適用されません。このようなコンテンツの状態は変化する可能性があり、エンドユーザーに古いデータが配信されたり、配信元の負荷が増加したりする可能性があるためです。そのため、Speed BrainはCloudflareのネットワーク上にキャッシュされたお客様のWebサイトの非動的ページに対してのみ機能します。動的ページの読み込みには影響を与えません。Speed Brainを最大限に活用するために、キャッシュルールを使用して、サイト上のすべての静的コンテンツ（特にHTMLコンテンツ）がキャッシュの対象であることを確認することをお勧めします。
投機的プリフェッチリクエスト（sec-purpose:prefetchヘッダーでマークされます）に対するレスポンスとして503 HTTPステータスコードをブラウザが受信すると、プリフェッチの試行が取り消されます。ブラウザのコンソールに503エラーが表示されるのは憂慮すべきことに思えるかもしれませんが、プリフェッチリクエストの取り消しにとっては全く無害です。初期のテストでは、503レスポンスコードがサイトオーナーの懸念を引き起こしました。クライアントエクスペリエンスの向上に向けてパートナーと度重なる協力を行っていますが、現時点では投機的なリクエストを安全に破棄するために、ブラウザに503レスポンスを推奨する仕様のガイダンスに従っています。Cloudflareは、初期のベータテスターからのフィードバックに基づいて、Chromeと積極的に議論を重ねており、新しい非エラーの専用レスポンスコードがより適切で、混乱を引き起こすことを減らすと考えています。一方で、Speed Brainに関連するプリフェッチリクエストの503レスポンスログは無害です。ツール上、こうしたリクエストを無視することが難しい場合は、Chrome Teamとの間で改善策が講じられるまで、Speed Brainを一時的に無効にすることができます。
さらに、Webサイトが独自のカスタムSpeculation RulesとCloudflareのSpeed Brain機能の両方を使用する場合、両方のルールセットを同時に動作させることができます。Cloudflareのガードレールは、投機的ルールをキャッシュ可能なページに制限しますが、既存の実装を持つユーザーにとっては、予期しない制限となるかもしれません。このような動作が見られる場合は、動作の一貫性を確保するために、サイトのいずれかの実装を無効にすることを検討してください。配信元サーバーのレスポンスにSpeculation-Rulesヘッダーが含まれる場合、ヘッダーがオーバーライドされないことに注意してください。したがって、ルールセットが競合する可能性は、主に事前定義されたインライン投機ルールに対して適用されます。
どうすればSpeed Brainの効果を実感できますか？
通常、RUMパフォーマンス測定ツールを有効にしてSpeed Brainや他のほとんどのCloudflareのパフォーマンス機能をご利用いただくことをお勧めします。CloudflareのRUM機能は、開発者やWebサイト運営者がエンドユーザーがアプリケーションのパフォーマンスをどのように経験しているかを理解するのに役立ち、以下を可視化します。
読み込み : コンテンツが使用可能になるまでにどれくらいの時間が必要か
インタラクティビティ：ユーザーがWebサイトを操作する際に、どれくらい応答性がよいか？
視覚的な安定性：読み込み中にどれくらいページが移動するか？
RUMを有効にすると、ダッシュボードのWeb Analyticsセクションに移動して、LCP（Largest Contentful Paint）や読み込み時間などのコアWebバイタルメトリクスの遅延の削減にSpeed Brainがどう役立つかに関する重要な情報を確認できます。
9月16日頃にSpeed Brainを有効にしたプリフェッチ可能なコンテンツが多いWebサイトのRUMダッシュボードの例
これまでの導入実績
すべてのFreeプランでデフォルトでこの機能を有効にし、以下を確認しています。
ドメイン
Cloudflareは現在、数千万のドメインでSpeed Brainを利用しています。これらのサイトについて75分位（p75）でLCPを測定したところ、40%から50%（平均45%程度）の改善が見られました。
この改善は、同じドメインセットに対する通常のプリフェッチされないページ読み込みとナビゲーションのプリフェッチを比較することで確認されました。
リクエスト
Speed Brainを有効にする前に、Cloudflare上の無料Webサイトのp75で約2.2秒のLCPが発生しました。Speed Brainを有効にすることで、これらのサイトでLCP上の大幅な遅延の削減が見られました。まとめると、Speed Brainは成功したプリフェッチごとに最低約0.88秒、最高1.1秒読み込み時間が短縮されます。
該当するブラウザ
現在、Speculation Rules APIはChromiumブラウザでのみ利用可能です。Cloudflare Radarより、訪問者からのリクエストの約70%がChromium（ChromeやEdgeなど）ブラウザからのものであることがわかっています。
ネットワークにわたって
Cloudflareでは、数千億件にわたるHTMLコンテンツへのリクエストを確認しています。これらのリクエストのうち、約半数はキャッシュされます（HTMLがキャッシュ可能であることを確認してください！）。これらのリクエストの約1%が、訪問者によって生じたナビゲーションのプリフェッチに対するものです。これは、Speed Brainを有効にするWebサイトの訪問者にとっては毎日大幅読み込み時間の短縮につながることを意味します。 24時間ごとに、Speed Brainは82年分以上の遅延を節約できるのです！
今後の展開は？
現在当社がSpeed Brainで提供しているものは、ほんの始まりに過ぎません。2025年に向けて、ご提供対象となるエキサイティングな追加機能が検討されています。
機械学習の活用
インターネット上でのCloudflareのユニークな立場により、Webのブラウジングパターンに関する貴重なインサイトが得られ、個々のユーザーのプライバシーを保護しながら、Webパフォーマンスを向上させるために活用できます。一般化されたデータ駆動型の機械学習アプローチを採用することにより、ユーザーのページに対してより正確でサイト固有プリフェッチ予測を定義することができます。
当社は現在、保守的な現行サービスを大幅に改善する適応型投機モデルを開発中です。このモデルは、プライバシー保護手法を用いて、同一サイトのReferrerヘッダーに基づいて、各サイトのユーザー移動グラフを生成します。ナビゲーションホップでつながっている2つのページに対して、Cloudflareのモデルは、集計されたトラフィックデータから抽出したインサイトを用いて、典型的なユーザーがページ間を移動する可能性を予測します。
このモデルにより、サイト上の関連する次ページリンクそれぞれに合わせて、カスタムのeagerness値でルールセットを調整することができます。モデルによってユーザーナビゲーションの信頼性が高いと予測されるページについて、システムは積極的にプリフェッチするかプリレンダリングを行います。モデルがページのルールを提供しない場合、デフォルトで既存の保守的なアプローチをとり、ベースラインのSpeed Brainモデルの利点が維持されます。これらのシグナルは、ブラウザが適切なページをプリフェッチしてプリレンダリングするように誘導します。これにより、現在の安全用ガードレールを維持しながら、ユーザーのナビゲーションを高速化するのに役立ちます。
ラボテストでは、MLモデルはLCPの遅延を75%改善し、訪問者のナビゲーションを最大98%の精度で予測しました。この結果、ユーザーのリソースの浪費を防ぐために正しいページがプリフェッチされていることが保証されます。このソリューションの拡張に向け、当社では変化するユーザーの行動と進化するWebサイトに適応するためのモデルの定期的なトレーニングに注力しています。オンライン機械学習アプローチを使用することで、高い精度を維持しながら、手動更新の必要性を大幅に減らし、コンテンツのドリフトを軽減することができます。これは、時間の経過とともに賢くなるSpeed Brain読み込みソリューションです。
RUMによる詳細な可観測性
先に述べたように、Cloudflareでは、当社のRUMツールは、Speed Brainがお客様のWebサイトのパフォーマンスにどのように貢献しているかを知る上で最高のインサイトを提供すると考えています。将来的には、RUMツールをナビゲーションのタイプでフィルタリングする機能を提供し、プリフェッチされたコンテンツと非プリフェッチのコンテンツのブラウザレンダリングを比較できるようにする計画です。
プリレンダリング
現在、キャッシュ可能なコンテンツのプリフェッチング機能を提供しています。プリフェッチングは、ユーザーがページから移動する前にページのメインドキュメントリソースをダウンロードしますが、ページをプリレンダリングしたり、追加のサブリソースをダウンロードしたりするようにブラウザに指示するものではありません。
将来的に、CloudflareのSpeed Brainサービスは、コンテンツをCDNキャッシュにプリフェッチし、ブラウザと連携して、プリレンダリングの最適な候補を判断するようになります。これにより、静的コンテンツをさらに瞬時のレンダリングに近づけることができます。
Argo Smart Browsing：Speed Brain & スマートルーティング
初期の実装では、Speed Brainの実装は保守的になりますが、優先度（eagerness）とリソース消費の観点の両方から、信じられないほどパフォーマンスを向上させることができます。
先に概説したように、機械学習と高い優先度（eagerness）により加速したモデルのラボテストを実施したところ、LCPが75%削減されました。Cloudflareでは、「Argo Smart Browsing」と呼ばれる製品へのより積極的なSpeed BrainとArgoスマートルーティングの組み込みを検討しています。
Cloudflareのお客様は引き続きSpeed Brainを無料でご利用いただけますが、さらなるパフォーマンス向上をご希望のお客様は、ボタンを1回クリックするだけでArgo Smart Browsingを有効にすることができます。Argo Smart Browsingを使用すると、より積極的なモデルにより、キャッシュ可能な静的コンテンツがブラウザで最大75%速く読み込まれるだけでなく、コンテンツがキャッシュできず、リクエストが配信元サーバーに転送されなければならない場合は、最も高性能なネットワークパス経由で送信され、平均33%のパフォーマンス向上を実現します。パフォーマンスの最適化は、コンテンツが静的か動的か、キャッシュされたかどうかに関係なく、リクエストライフサイクルのほぼすべてのセグメントに適用されます。
まとめ
Speed Brainの利用を開始するには、Cloudflareダッシュボードの速度 > 最適化 > コンテンツの最適化 >Speed Brainに進み、有効にするだけです。この機能は、API経由で有効化することもできます。FreeプランのドメインはデフォルトでSpeed Brainが有効になっています。
Speed Brainや他のCloudflare製品によるパフォーマンスの向上を可視化するために、ダッシュボードの同じセクションにあるRUMを有効にすることを強くお勧めします。
Cloudflareでは、Webパフォーマンスを確実に高速化する製品と機能を構築し続けられるよう鋭意努力しています。Web全体のパフォーマンス向上に興味をお持ちのエンジニアの方は、ぜひチームに加わってください！