現在、AJAX を使用してアクティブなストリーム (TwitchTV) のリストを取得しています。これは視聴者であり、毎秒これを要求しています。チェックするストリームのリストが非常に長くなる場合があるため、ajax リクエストを 2 つまたは 3 つの部分に分割する予定です。
1) 現在のストリームの視聴者数を取得 (1 秒ごとにチェック)
2) ストリームを半分に分割し、アクティブなストリーマーのリストの最初の半分を確認します (5 秒ごとに確認します)。
3) アクティブなストリーマーのリストの後半をチェック (5 秒ごとにチェック)
そのため、3 つのリクエストを同時に実行することになりますが、ロード時間がどのくらいになるか心配です。常にデータを引き込んでいるので、ページが遅くなりますか? ユーザーはおそらく気付くでしょうか？大量のデータに対して 1 つの ajax リクエストを保持する方が良いですか、それとも小さなデータに対して複数の ajax リクエストを使用する方が良いですか? ajax は、常に変化するライブ データを取得するのに本当に最適なものですか?
さまざまな質問に対する答えは、おそらく「場合による」です。
ajax リクエスト自体によって速度が低下することはありません。これらは非同期リクエストであるため、実際にはリクエストが完了したときにユーザーのブラウザーにかなりの (そしておそらくまだ目立たない) 負荷がかかるだけです。
アプリの速度が低下する可能性がある (または、ユーザーが不快な方法で気付く原因となる) 可能性がある 1 つのことは、要求が完了したときの DOM 操作です。現在のストリーミング ユーザー数をインプレースで変更しても問題はありませんが、ストリームの数やリストでの表示方法によっては、これを再描画すると非常にコストがかかる可能性があり、再描画などで遅延が発生する可能性があります。
Ajax を使用する代わりに (サポートするブラウザーによって異なります)、websocket を使用することもできます。このようにして、接続を開いたままにしておくことができ、サーバーは、データをポーリングする必要があるのではなく、いつデータを変更する必要があるかをアプリケーションに伝えることができます。
リストを前半と後半に分ける必要があるのはなぜですか?
送受信するデータの量を減らす 1 つの方法は、受信したデータの最後のビットを示す何らかの信号を送信することです。たとえば、twitter.com のタイムラインが数秒ごとに更新される場合、ajax リクエストは受信した最新のツイートの ID と共に送信するため、サーバーはそれより古いデータを送信する時間を無駄にしないことを認識します。ユースケースによっては、これが効果的な場合があります。