セルフホスティングのサードパーティ リソース: 良い点、悪い点、醜い点

近年、フロントエンド プロジェクトを最適化するためのプラットフォームがますます増えており、サードパーティ リソースをセルフホスティングまたはプロキシする機会が提供されています。 Akamai では次の設定が可能です 特定のパラメータ 自己生成された URL の場合。 Cloudflareにはエッジワーカーテクノロジーが搭載されています。ファスタージン缶 リライト ページ上の URL。サイトのメイン ドメインにあるサードパーティのリソースを指すようにします。

プロジェクトで使用されるサードパーティ サービスがあまり頻繁に変更されず、それらをクライアントに提供するプロセスを改善できることがわかっている場合は、おそらくそのようなサービスをプロキシすることを検討しているでしょう。このアプローチを使用すると、これらのリソースをユーザーに近づけることができ、クライアント側でキャッシュをより完全に制御できるようになります。さらに、サードパーティのサービスの「クラッシュ」やパフォーマンスの低下によって引き起こされるトラブルからユーザーを保護することができます。

良い: パフォーマンスの向上

他人のリソースを自己ホストすると、非常に明白な方法でパフォーマンスが向上します。ブラウザは DNS に再度アクセスする必要はなく、TCP 接続を確立してサードパーティ ドメイン上で TLS ハンドシェイクを実行する必要もありません。次の 2 つの図を比較すると、他人のリソースを自己ホストすることがパフォーマンスにどのような影響を与えるかがわかります。

サードパーティのリソースは外部ソースからダウンロードされます（から取得されます） 故に)

サードパーティのリソースは、サイトの残りのマテリアルと同じ場所に保存されます (以下から取得) 故に)

この状況は、ブラウザがメイン ドメインとすでに確立されている HTTP/2 接続からのデータを多重化し、優先順位を付ける機能を使用することによっても改善されます。

サードパーティのリソースをホストしていない場合、それらのリソースはメインのドメインとは異なるドメインから読み込まれるため、優先順位を付けることができません。これにより、クライアントの帯域幅をめぐって互いに競合するようになります。これにより、ページの構築に重要なコンテンツの読み込み時間が、理想的な状況で達成できる時間よりも大幅に長くなる可能性があります。 ここで HTTP/2 の優先順位付けについての話は、これらすべてを非常によく説明しています。

外部リソースへのリンクでの属性の使用が想定されます。 preconnect 問題の解決に役立ちます。ただし、さまざまなドメインへのこれらのリンクが多すぎると、最も重要な瞬間に実際に通信回線に過負荷がかかる可能性があります。

サードパーティのリソースを自分でホストする場合は、これらのリソースをクライアントにどのように正確に提供するかを制御できます。つまり、次のようなことについて話しています。

• 各ブラウザに最適なデータ圧縮アルゴリズム (Brotli/gzip) が使用されていることを確認できます。
• 最もよく知られたプロバイダーであっても、通常は特に長くないリソースのキャッシュ時間を増やすことができます (たとえば、GA タグの対応する値は 30 分に設定されています)。

関連するコンテンツをキャッシュ管理戦略 (URL ハッシュ、バージョン管理など) に組み込むことで、リソースの TTL をたとえば 1 年に延長することもできます。これについては以下で説明します。

▍サードパーティサービスの運用の中断またはシャットダウンに対する保護

セルフホスティング サードパーティ リソースのもう 1 つの興味深い側面は、サードパーティ サービスの停止に伴うリスクを軽減できることです。使用しているサードパーティの A/B テスト ソリューションが、ページのヘッド セクションに読み込まれるブロック スクリプトとして実装されていると仮定します。このスクリプトの読み込みは遅いです。対応するスクリプトのロードに失敗すると、ページは空になります。読み込みに非常に長い時間がかかる場合、ページの表示にかなりの遅れが生じます。または、プロジェクトがサードパーティ CDN リソースからダウンロードされたライブラリを使用しているとします。このリソースに障害が発生したか、特定の国でブロックされたと想像してみましょう。このような状況は、サイトのロジックの違反につながります。

一部の外部サービスが利用できないときにサイトがどのように動作するかを確認するには、次の SPOF セクションを使用できます。 ウェブページテスト.org.

webpagetest.org の SPOF セクション

▍ブラウザでのマテリアルのキャッシュに関する問題についてはどうですか? （ヒント：それは神話です）

これらのサービスはかなり高品質のネットワークを備えており、世界中に分散されているため、パブリック CDN を使用すると、自動的にリソースのパフォーマンスが向上すると考えるかもしれません。しかし、実際にはすべてがもう少し複雑です。

いくつかの異なるサイト (website1.com、website2.com、website3.com) があるとします。これらのサイトはすべて jQuery ライブラリを使用しています。 CDN (例: googleapis.com) を使用してそれらに接続します。ブラウザーがライブラリを一度ダウンロードしてキャッシュし、その後 XNUMX つのサイトすべてでそれを使用することが期待できます。これにより、ネットワークの負荷が軽減される可能性があります。おそらくこれにより、どこかでコストを節約し、リソースのパフォーマンスを向上させることができます。実際の観点から見ると、すべてが異なって見えます。たとえば、Safari には次のような機能があります。 インテリジェントなトラッキング防止: キャッシュは、ドキュメントのソースとサードパーティ リソースのソースに基づいて二重キーを使用します。 ここで このトピックに関する良い記事。

古い研究 Yahoo и Facebook、さらに最近の 調査 Paul Calvano 氏、リソースは私たちが期待しているほど長くブラウザーのキャッシュに保存されないことを示しています。「プロジェクト自身のリソースとサードパーティのリソースのキャッシュ時間には重大な差があります。 CSS と Web フォントについて話します。つまり、ネイティブ フォントの 95% のキャッシュ寿命は 50 週間以上ですが、サードパーティ フォントの XNUMX% のキャッシュ寿命は XNUMX 週間未満です。これにより、Web 開発者は自分自身でフォント ファイルをホストする説得力のある理由が得られます。」

その結果、他の人のコンテンツをホストする場合、ブラウザーのキャッシュによって引き起こされるパフォーマンスの問題に気づくことはありません。

サードパーティのセルフホスティングの長所について説明したので、次は、このアプローチの良い実装と悪い実装を区別する方法について話しましょう。

悪い点: 悪魔は細部に宿る

サードパーティのリソースを独自のドメインに移動するには、そのようなリソースが適切にキャッシュされていることを確認する必要があります。

ここでの主な問題の 1 つは、キャッシュ時間です。たとえば、バージョン情報は次のようにサードパーティのスクリプト名に含まれます。 jquery-3.4.1.js。このようなファイルは今後も変更されないため、キャッシュに問題が発生することはありません。

ただし、ファイルを操作するときに何らかのバージョン管理スキームが使用されていない場合、キャッシュされたスクリプトは、ファイル名は変更されないまま内容が変更されるため、古くなってしまう可能性があります。これは、たとえば、クライアントができるだけ早く受け取る必要があるスクリプトに自動セキュリティ パッチを追加できないため、深刻な問題になる可能性があります。開発者は、キャッシュ内のそのようなスクリプトを更新する努力をする必要があります。さらに、クライアントでキャッシュから使用されるコードが、プロジェクトのサーバー部分が設計されている最新バージョンのコードと異なるため、アプリケーションのエラーが発生する可能性があります。

確かに、頻繁に更新されるマテリアル (タグ マネージャー、A/B テスト用のソリューション) について言えば、CDN ツールを使用してそれらをキャッシュすることは解決できるタスクですが、はるかに複雑です。タグ管理ソリューションである Commanders Act などのサービスは、新しいバージョンを公開するときに Webhook を使用します。これにより、CDN 上でキャッシュを強制的にフラッシュしたり、ハッシュや URL を強制的に更新したりできるようになります。

▍クライアントへの資料の適応的な配信

さらに、キャッシュについて話すときは、CDN で使用されるキャッシュ設定が一部のサードパーティ リソースには適していない可能性があるという事実を考慮する必要があります。たとえば、そのようなリソースは、ユーザー エージェント スニッフィング (アダプティブ サービング) テクノロジを使用して、特定のブラウザに、そのブラウザ向けに特別に最適化されたバージョンのコンテンツを提供する場合があります。これらのテクノロジーは、正規表現、つまり HTTP ヘッダー情報のデータベースに依存して、ブラウザーの機能を把握します。 User-Agent。どのブラウザを扱っているかがわかったら、そのブラウザ用に設計されたマテリアルを提供します。

ここで 2 つのサービスを覚えておいてください。 XNUMX つ目は googlefonts.com です。 XNUMX つ目は、polyfill.io です。 Google Fonts サービスは、ブラウザの機能に応じて、特定のリソースに対してさまざまな CSS コードを提供します (woffXNUMX リソースへのリンクを使用して提供します)。 unicode-range).

以下は、さまざまなブラウザから行われたいくつかの Google Fonts クエリの結果です。

Chrome からの Google Fonts クエリ結果

IE10から実行したGoogle Fontsクエリの結果

Polyfill.io は、ブラウザに必要なポリフィルのみを提供します。これはパフォーマンス上の理由から行われます。

たとえば、さまざまなブラウザから次のリクエストを実行した場合に何が起こるかを見てみましょう。 https://polyfill.io/v3/polyfill.js?features=default

IE10からこのようなリクエストを実行すると、34KBのデータが受信されます。 Chrome から実行すると、それに対する答えは空になります。

怒り: プライバシーに関する考慮事項

この点は順番の最後ですが、最も重要なことではありません。重要なのは、プロジェクトのメイン ドメインまたはそのサブドメインでサードパーティ リソースを自己ホストすると、ユーザーのプライバシーが危険にさらされ、メインの Web プロジェクトに悪影響を及ぼす可能性があるということです。

CDN システムが正しく構成されていない場合、ドメインの Cookie がサードパーティのサービスに送信されてしまう可能性があります。 CDN レベルで適切なフィルタリングが構成されていない場合、セッション Cookie は通常 JavaScript では使用できません ( httponly)、外部ホストに送信される場合があります。

これはまさに Eulerian や Criteo などのトラッカーで起こり得ることです。サードパーティのトラッカーが Cookie に一意の識別子を設定している可能性があります。それらがサイト マテリアルの一部である場合、ユーザーが別の Web リソースを操作しているときに、その識別子を自由に読み取ることができます。

最近では、ほとんどのブラウザにこの種のトラッカー動作に対する保護機能が組み込まれています。その結果、トラッカーはテクノロジーを使用するようになりました。 CNAME クローキング、さまざまなプロジェクトの独自のスクリプトを装っています。つまり、トラッカーはサイト所有者に、特定のドメインの設定に CNAME を追加するよう提案します。そのアドレスは通常、ランダムな文字セットのように見えます。

Web サイトの Cookie をすべてのサブドメイン (*.website.com など) で利用できるようにすることはお勧めできませんが、多くのサイトでこれが行われています。この場合、そのような Cookie は偽装されたサードパーティ トラッカーに自動的に送信されます。その結果、私たちはプライバシーについて話すことができなくなりました。

また、HTTP ヘッダーでも同じことが起こります クライアントヒントを作成するために使用できるため、メイン ドメインにのみ送信されます。 デジタル指紋 ユーザー。使用する CDN サービスがこれらのヘッダーを正しくフィルタリングしていることを確認してください。

結果

サードパーティ リソースのセルフホスティングをすぐに実装する予定がある場合は、いくつかのアドバイスをさせてください。

• 最も重要な JS ライブラリ、フォント、CSS ファイルをホストします。これにより、サードパーティ サービスの障害によりサイトに不可欠なリソースが利用できなくなり、サイトの障害やパフォーマンスが低下するリスクが軽減されます。
• サードパーティのリソースを CDN にキャッシュする前に、ファイルに名前を付けるときに何らかのバージョン管理システムが使用されていること、または新しいバージョンの公開時に CDN キャッシュを手動または自動でリセットすることでこれらのリソースのライフサイクルを管理できることを確認してください。スクリプト。
• CDN、プロキシ サーバー、キャッシュの設定には十分注意してください。これにより、プロジェクトまたはヘッダーに Cookie が送信されるのを防ぐことができます。 Client-Hints サードパーティのサービス。

親愛なる読者！ プロジェクトの運営にとって非常に重要な他の人のマテリアルをサーバー上でホストしていますか?

出所： habr.com