現代の Web 世界では、独立した Web サイトは存在しません。私たちは複雑なサードパーティリソースのネットワークに依存しています。これには、分析ツール、フォント、アドテック、同意管理ツール、その他のサードパーティサービスが含まれ、豊かな体験を構築するために利用されています。しかし、これらのツールは変革をもたらす一方で、重大なリスクをもたらします。つまり、サイトの速度と稼働時間を他者の手に委ねることになるのです。
1570万の Web サイトを対象とした HTTP Archive の最近の分析は、Web 構築の驚くべき脆弱性を明らかにしています。 67%のウェブサイトが、レンダリングをブロックするサードパーティリソースを少なくとも1つ要求しているのです。リソースの読み込み方法によっては、プロバイダーで障害が発生すると、それに依存する Web サイトも影響を受ける可能性があります。
Fastly では、サードパーティに依存する場合でも、可用性は最終的にお客様が管理するべきものであると考えています。ここでは、リスクを特定し、そのエッジを使ってコントロールを取り戻す方法をご紹介します。
「偶発的な」依存関係
多くの組織は冗長性を確保するため、意図的にマルチ CDN 戦略を採用しています。サイトの資産を別のコンテンツ配信ネットワーク対応ドメインでホストすることも一般的です。しかし、実際にはリスクを増大させる意図しないマルチ CDN 戦略を、何千もの企業が導入しているのです。
上位 100万のサイトを分析したところ、11,186社の Fastly の顧客が、Fastly 以外のコンテンツ配信ネットワークからレンダリングをブロックするコンテンツを読み込んでいることがわかりました。これにより、隠れたバックドアが生まれます。配信を Fastly に任せていても、重要な資産を他の場所でホストしている場合、稼働時間はそのネットワークに依存することになります。
特に注目すべきは、最近数回の大きな障害が発生したあるコンテンツ配信ネットワークに依存し、そこからレンダリングを妨げるコンテンツを読み込んでいる Fastly ホストの Web サイトが5,476件見つかったことです。
これらのサイトでは、そのコンテンツ配信ネットワークでの障害が、自社の Web サイトでの障害に連鎖する可能性があります。このリスクは複雑さによってさらに増大しています。他のコンテンツ配信ネットワークからレンダリングをブロックするコンテンツをロードしている Fastly の顧客のうち、56.5%が複数の異なるコンテンツ配信ネットワークからコンテンツをロードしているのです。
30秒間の真っ白な画面
重要な依存関係に問題が生じると、どうなるでしょうか？それは、エンドユーザーにとって単なるエラーでは済みません。
ブラウザが、応答のない外部ドメインにホストされた、同期読み込みのレンダリングをブロックするスクリプトやスタイルシートに遭遇すると、そのリソースを待つためにレンダリングを一時停止してしまうのです。多くのブラウザでは、接続がタイムアウトするまで空白の白い画面が表示されます。
これは理論上の話ではありません。最近発生した TikTok のサービス停止では、同社の分析スクリプト (analytics.tiktok.com) の障害がWeb 全体に混乱をもたらしました。一部の大手小売業者ではファビコンの読み込みスピナーが機能しなくなり、他のサイトではユーザーエクスペリエンスが完全に阻害される事態となりました。同様に、主要コンテンツ配信ネットワークの広範囲な障害では、そのコンテンツ配信ネットワークの直接の顧客でさえなかった数千のサイトがダウンしました。単にそこでホストされているサードパーティ製ウィジェットに依存していたという理由だけでです。
依存関係をテストしてください
次のベンダーのサービス停止を待たなくても、サイトの障害対応を確認できます。ブラウザからすぐにサードパーティのテストを実行することをお勧めします。
DevTools のブロッキング : Chrome では、個々のネットワークリクエストまたはドメイン全体をブロックして、完全な停止をシミュレートできます。Firefox では、個々のネットワークリクエストをブロックすることもできます。
DevTools のスロットリング : Chrome 145 以降では、特定のサードパーティタグで極端なレイテンシ (10秒など) をシミュレートするために、個々のネットワークリクエストをスロットルして、First Contentful Paint (FCP) への影響を観察することができます。
これらのテストで空白の画面が表示される場合、単一障害点 (SPOF) が存在しています。
ソリューション : サードパーティからファーストパーティへ
このリスクを排除する最も効果的な方法は、Fastly 上で自社ドメイン経由でサードパーティスクリプトをプロキシ処理し、これらの資産を自社管理下・自社ドメイン下に移行することです。この手法には3つの大きな利点があります。
レジリエンス : サードパーティのオリジンに障害が発生した場合、Fastly は失効済みのキャッシュされたバージョンのスクリプトを提供し、サイトをオンラインに保ちます。
パフォーマンス : your-site.com/analytics.js からスクリプトを読み込むことで、third-party.com/analytics.js を使用する場合と比べて、DNS ルックアップ、TCP 接続、およびトランスポート・レイヤー・セキュリティ (TLS) ハンドシェイクの必要性がなくなります。接続はすでに開いているので、HTTP の優先順位付けがしやすくなります。
コントロール : リクエストが自社の Fastly サービス経由で配信される場合、コンテンツ配信ネットワークおよびブラウザでのレスポンスのキャッシュ期間や圧縮方法をコントロールできます。Fastly を使用してサードパーティのスクリプトを Brotli 圧縮すると、ペイロードを10 - 15%削減できます。
プライバシー : プロキシ化により、Cookie、X-Forwarded-For、Fastly-Client-IP などの機密ヘッダーをリクエストがベンダーに到達する前に除去できるため、データ漏洩を防ぐことができます。
主なしくみ
一部のサードパーティスクリプトでは、自社のドメインでスクリプトを提供する簡単な方法が提供されています。他にも、このパターンを使用して変換できるものがあります。
サードパーティが新しいバックエンドとして Fastly サービスに追加されます。
HTML の <script> タグは、ローカルパスから読み込むように変更されます。たとえば、/services/analytics などです。
このパスへのリクエストは、Fastly によって正しいバックエンドパスに変換され、バックエンドにルーティングされます。
サードパーティが提供するライブラリコードは Fastly に取り込まれ、必要に応じて変換されます。たとえば、サードパーティのデータコレクターの URL を検索し、プロキシエンドポイントに置き換えます。
サードパーティのスクリプトによる後続のリクエストは、Fastly サービスに送信され、必要に応じて検査、フィルタリングされてから、サードパーティに転送されます。
詳細については、Andrew の説明をご覧ください。記事「 単一オリジンの Web サイトでサードパーティを使いこなす」で、このパターンについて詳しく説明しています。
最後に
サードパーティの障害を避けることはできませんが、それがビジネスに及ぼす影響は、必ずしも避けられないものではありません。ソーシャルメディアのスクリプトであれ、フォントファイルであれ、それがレンダリングを妨げるものであれば、貴社の収益を脅かすリスクとなるのです。
今すぐ、貴社のサイトでレンダリングを妨げているサードパーティのリソースがないか監査しましょう。もし見つかった場合は、Fastly がそれらの資産のプロキシをどのように支援できるか、ぜひご相談ください。インターネットのどこかで障害が発生した場合でも、貴社のサイトは影響を受けずに済むようにしましょう。