ページネーションを検討する必要があります。「次へ」を頻繁にクリックする必要があることにユーザーが不満を感じている場合は、各チャンクを適度に大きくすることができます(したがって、通常のリーダーページは20分ごとに表示されます)。
もう1つのオプションは、Chunked-Endoding転送タイプです:WikipediaEntry。これにより、サーバーは迅速に応答し、ネットワークを介してファイルの残りの部分をストリーミングしている間、ユーザーに何かを読み取ることができます(サーバーがファイルを読み込んで一度に送信する必要はありません)。これにより、通常のファイルの提供と比較して、知覚されるパフォーマンスが劇的に向上する可能性がありますが、それでもサーバーの帯域幅を大量に消費します。
JavascriptとAJAXを使用して大きなドキュメントをシミュレートできる場合がありますが、パフォーマンスを向上させるために一度に送信するのはピースのみです。
数ページ分のドキュメントを送信し、ブラウザのスクロールイベントにリスナーをアタッチすることを検討してください。時間の経過とともに、またはユーザーが下にスクロールすると、AJAXのチャンクが増えます。これにより、次のような厄介なUXエッジケースがいくつか作成されます。
- スクロールバーは、実際よりもはるかに小さいドキュメントを示します
- ドキュメントの下部に多くのページ分割を入力することでこれを回避できる場合がありますが、長さを完全にすることは困難です。
- 現在利用可能なコンテンツのポイントを超えてスクロールすると、空白のページが表示されます。
- JavaScriptを使用してこれを検出し、「読み込み中」アイコンを表示して、何が起こっているかをユーザーに知らせることができます。
- 組み込みの「検索」機能が機能しない
- ユーザーがドキュメント全体をダウンロードしない限り、これを回避するのは困難ですが、代わりに使用する独自の検索機能を提供することもできます(それほど良くはありませんが、おそらく適切です)。
ただし、実際には、中サイズのページでページ付けを行うのがおそらく最善です。これは非常によく理解されているデザインパターンであり、(少なくとも他のオプションと比較して)実装と高速化が比較的簡単です。
お役に立てば幸いです。