クライアントSPOFの本質
クライアント側のSPOFの機能は、ブラウザによるページのレンダリング機能によって決まります。 レンダリングエンジンの理解を深めるために、ページレンダリングへのクリティカルパスに関する以前の記事habrahabr.ru/post/262239を読むことをお勧めします。
典型的なクライアントSPOFの例：
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>jQuery UI Datepicker - Default functionality</title> <link rel="stylesheet" href="//code.jquery.com/ui/1.11.4/themes/smoothness/jquery-ui.css"> <script src="//code.jquery.com/jquery-1.10.2.js"></script> <script src="//code.jquery.com/ui/1.11.4/jquery-ui.js"></script> <link rel="stylesheet" href="/resources/demos/style.css"> <script> $(function() { $( "#datepicker" ).datepicker(); }); </script> </head> <body> <p>Date: <input type="text" id="datepicker"></p> </body> </html>
クリティカルレンダリングパスについて知っている主なこと：ページとCSSファイルで遭遇するJSコードでブラウザーがブロックされています（現時点では、詳細は省略します）。 これは、重要なJSおよびCSSリソースを受け取る前にページ（ページの全部または一部）を見ることができないことを意味します。 これらのリソースがサイトと同じサーバー上にある場合、これは時間の問題です。待機し、ロードして実行します（またはすぐに404を取得します）。
しかし、他のサーバーからリソースをロードするとどうなりますか？ この場合、ブラウザは最初にDNSクエリを作成し、サーバーに接続して要求を送信し、応答を待つ必要があります。 その後、受信したリソースを処理してからページのレンダリングを続行します。
これがクライアントSPOFを理解するために来た場所です。 サイトに外部ソース（別のドメイン）からダウンロードされた重要なJSまたはCSSリソースがある場合、クライアント障害点（SPOF）が発生します。 この場合、任意のサーバーが外部ソースとして機能できます。CDNノード、JS-APIを備えた外部サイト、JSライブラリのホストなどです。外部サーバーからの応答が遅い場合、障害の表示が保証されます（低速または非常に遅いページレンダリング）。 外部サーバーがまったく応答しない場合、ブラウザはタイムアウトが期限切れになるまで待機します（最大で数十秒）。
このように見える場合があります（スクリーンショットの上の時間に注意してください）。
ユーザーにとって、最悪の場合のSPOFの兆候は、「サイトがダウンしている」ように見えますが、せいぜい「サイトが非常に遅い」だけです。 同時に、ホスティングは正常に機能し、サイトへの攻撃はなく、効果は優れたDDoSのようなものです。
なぜこれが重要なのですか？
この問題に関する基本的な記事は2010年6月1日にSteveによって書かれましたが、外部ホスティングサービス（apis.google.com、code.jquery.com、userapi.com、facebook、twitterなど）からJSライブラリを接続するサイトを常に見る必要があります。 。）危険なのは、同期モードでHTMLコードの上部にあるスクリプトを接続することです（「async」属性なし）。
まあ、これはすべて怖いですが、非常に信頼性が高く、クラッシュすることのない分散CDNホスティングからファイルをダウンロードします！ 彼らは常に応答し、それを速くします！ 問題ないようです...
残念ながら、それが理由です。
- 最も信頼性の高いホスティング会社でさえも（クラウドでも）落ちています。
- CDN配布ポイントは、ユーザーから遠く離れている場合があります（ロシアには多くのポイントがありません）。
- 静的配布サービスとライブラリホスティングは多くの場合無料であり、操作性と応答速度の保証はありません。
- ホストソースは、プロバイダー/国レベル（たとえば、中国またはロシア）でブロックできます。
その結果、時限爆弾が発生します。 通常、すべてが正常に機能しますが、サイトが突然「クラッシュ」するときが来ます。 問題が浮かんでいたり、一部のユーザーにしか影響を与えないことは特に楽しいです。
SPOFの結果の存在と重大度を確認します
これらすべてをどうするか？ まず、サイト上のSPOFの存在を確認する必要があります。 これを行うために、JSおよびCSSリソースのダウンロード元であるすべての外部ホストを収集します（接続されているフォントのソースを見つけることもできます）。
次に、外部ホストに障害が発生した場合に何が起こるかを確認する必要があります。 これを行うには、SPOFタブのあるWebpagetest.orgが最善の方法だと思います。 このフィールドには、パケットを静かにドロップして応答しないすべてのホストを入力できます。 興味のあるテストポイント、ブラウザを選択し、通常のテストを実行します。
出力では、通常とSPOFの2つのテストを取得します。 ページレンダリングのスクリーンショットを表示すると、SPOFの結果の重大度がわかります（原則として、レンダリングの開始が遅れた瞬間）。 これらのデータに基づいて、リソースの転送または障害に対する保険について決定を下すことはすでに可能です。
問題解決
このような手段を講じて、クライアントSPOFの影響を排除または最小限に抑えることができます。
- 可能であれば、すべてのJSライブラリを非同期モード（非同期属性）にします。
- すべての外部同期JSライブラリを閉じている本体まで削除します。
- 接続する外部APIの非同期バージョンを使用します。
- 標準のJSライブラリをホストしているサイトに転送し、そこからロードします。
- フォントとそのCSSコードをホスティングサイトに転送します。
- SPOFについて定期的にサイトを確認してください。
これがすべての推奨事項です。 クライアントSPOFに対処するための独自の経験を蓄積している場合は、コメントを記入してください。