IM クライアントを常にログイン状態に保つために、Facebook はページをドキュメントに挿入する前に AJAX を使用してページをロードすることにより、ページ全体のロードを回避します。
ただし、Facebook の AJAX リクエストの間、ブラウザは目に見えてロードしているように見えます。再読み込みボタンが X に変わり、ブラウザに組み込まれた進行状況インジケーターが読み込み/待機中などを示します)
私は AJAX ベースのナビゲーションを正常に実装できましたが、(リクエストが非同期であるため) 私のブラウザにはロードの兆候がまったく表示されません。
読み込み中の要素がドキュメントにある場合、ブラウザーは読み込み状態を表示します。Ajax リクエストはすべて JavaScript 内から行われます。ドキュメントは影響を受けないため、読み込み状態はトリガーされません。
一方、Facebook の要求のほとんどは<script>、必要なデータを含む JavaScript ファイルを指すタグをドキュメントに挿入することによって行われます。<script>(異なる形式を使用することを除いて、基本的には JSONP です。)タグがドキュメント内のアンロードされた要素であるため、ブラウザーはその読み込み状態を表示します。
この手法/JSONP は、クロスサイト リクエストが許可されているため、注意しないとサイトをセキュリティ リスクにさらす可能性があります。Facebook は、リソースごとにランダムな URL を生成することでこれに対処し、最初のページ読み込みでブラウザに送信されます。
Facebook は Big Pipe と呼ばれる彼らが開発したツールを使用して、基本的にサイトをチャンクでクライアントにストリーミングします。それらはベア DOM を含む初期スクリプト タグをクライアントに送信し、スクリプトはページにモジュールを非同期的にロードします。サーバーがモジュール 2 をフェッチしている間にクライアントがモジュール 1 を提示するという考えにより、ロード時間が短縮されます。
その上で、ロングポーリングと呼ばれる手法を使用します。HTTP 1.1 を使用すると、永続的な接続を利用できるため、タイムアウトを心配する必要がありません。ページがレンダリングされると、クライアント側のスクリプトは Facebook に対して AJAX 要求を行い、基本的にイベントを "リッスン" します。そこに座って、イベントが発生するまでリッスンします。その間、ブラウザはデータを「読み込んでいる」ように見えます。
Facebook 側でイベントがトリガーされると (たとえば、誰かがあなたのウォール ポストにコメントしたとします)、FB はその応答をクライアントに送り返し、それぞれのコールバックを起動します (コメントについて知らせる小さなツール ヒントをポップアップ表示するなど)。 FB に別のリクエストを送信して、次のイベントをリッスンします。