Ajax 非リフレッシュ ページングのパフォーマンス最適化方法

この記事では、Ajax 非リフレッシュ ページングのパフォーマンス最適化方法に関する関連情報を主に紹介します。必要な方は参考にしてください。 Web フロントエンド ページ.js メソッドで、Ajax を介してサーバー側のページング データ インターフェイスをリクエストし、データを取得した後、次のような HTML 構造をページ上に作成してユーザーに表示します。

<script type=”text/javascript”>
function getPage(pageIndex){
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
function callback(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}
</script>

このうち、RemoteInterface.cgiはサーバー端末のインターフェースです。ここでのスペースは限られているため、意味を明確に表現するためだけに、関連するコード例は完全ではない可能性があります。

UI には、誰もがよく知っている、次のようなさまざまなスタイルのページング コントロールが存在します。

しかし、getPage をトリガーするのは、ユーザーがコントロールをクリックするだけです。 (pageIndex) here ) メソッドと同様に、この getPage メソッドはそれほど単純ではない可能性があります。

コード スニペット 1 の記述方法に従うと、ユーザーがクリックしてページをめくるたびに、初回を除き、データ更新の可能性を無視して、RemoteInterface.cgi が 1 回リクエストされることが想像できます。 getPage( 1)、getPage(2)、getPage(3) などによってトリガーされるリモート インターフェイス リクエストと、ネットワークとの間のデータ トラフィックは実際には反復的であり、不要です。このデータは、各ページが初めてリクエストされたときに何らかの形式でページ上にキャッシュできます。ユーザーが以前にめくったページを振り返ることに興味がある場合、getPage メソッドはまずローカル キャッシュにそのページが含まれているかどうかを確認する必要があります。データが「はい」の場合、リモート インターフェイスを呼び出す代わりに、ユーザーに直接再表示されます。このアイデアに従って、コード スニペット 1 を次のように変更できます:

<script type=”text/javascript”>
var pageDatalist={};
function getPage(pageIndex){
if(pageDatalist[pageIndex]){ //如果本地的数据列表中包含当前请求页码的数据
showPage(pageDatalist[pageIndex])//直接展现当前数据
}
else
{
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
}
function callback(pageIndex,datalist){
pageDatalist[pageIndex]= datalist; //缓存数据
showPage(datalist);//展现数据
}
function showPage(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}

</script>

これにより、ネットワーク リクエストの往復時間が節約され、さらに重要なことに、貴重なネットワーク トラフィックが節約され、インターフェイスの負担が軽減されます。サーバ。ネットワーク速度が低い環境、またはインターフェイス サーバーの動作負荷がすでに比較的高い場合、この必要な改善により明らかな最適化効果が現れる可能性があります。 Yahoo の有名な 34 のルールの 1 つ目は、HTTP リクエストの数を最小限に抑えることです。 Ajax 非同期リクエストは間違いなく http リクエストの範囲内にあります。トラフィックの少ない Web アプリケーションは不要に思えるかもしれませんが、次のようなページがあると想像してください。1 日あたり 1,000 万回のアクセスがあり、ユーザーは平均 5 ページをめくる、1 つのページが繰り返し表示されます。コード スニペット 1 の記述方法によれば、そのようなページは 1 日あたり平均 5,000 万件のデータ リクエストをトリガーし、コード スニペット 2 の記載方法によれば、1 日あたり平均で少なくとも 1,000 万件のリクエストを削減できます。 。毎回要求されるデータ量が 20kb の場合、1,000 万 * 20kb = 200,000,000kb、つまり約 190G のネットワーク トラフィックを節約できます。この方法で節約されるリソースはかなりのものになります。

さらに詳しく知りたい場合は、コード スニペット 2 のデータ キャッシュ方法について議論する価値があります。以前は、ページング データの適時性は無視できると想定していましたが、実際のアプリケーションでは適時性は避けられない問題です。キャッシュは間違いなく適時性の低下につながります。実際のキャッシュ ソリューションは、アプリケーションの適時性要件の分析とトレードオフにも依存する必要があります。

一般的に適時性を重視しないコンテンツの場合、ページ上のキャッシュは許容されるべきです。第一に、ユーザーは常に 1 つのページに留まることはなく、ページ間の移動やリロードが発生すると、更新されたコンテンツを取得できます。データ。さらに、ユーザーがページを更新する習慣がある場合は、リストにデータが更新されているかどうかを特に確認したいときにページを更新することを選択できます。完璧を追求する場合は、5 分などの時間範囲を設定することも検討できます。ユーザーが現在のページに 5 分以上滞在した場合、5 分以内にページをめくるとまずページ上のキャッシュが読み取られ、5 分後にページをめくるとサーバー データが再度リクエストされます。

場合によっては、データ更新が何日行われるかなど、データ更新の頻度を予測できれば、一定期間後にローカル ストレージを使用してサーバー データのリクエストをトリガーすることも検討できます。リクエスト数とトラフィックにさらに大きな影響を与えます。もちろん、どのようなキャッシュ方法が最終的に適しているかは、製品の適時性要件によって異なりますが、原則として、特にアクセス数が多いページの場合は、リクエストとトラフィックを可能な限り節約することです。

適時性が要求されるタイプのデータにとって、キャッシュは完全に不適切なのでしょうか? もちろんそうではありませんが、全体的な考え方を変更する必要があります。一般に、いわゆる変更とは、主にリスト内のデータが増加、減少、または変更されたことを意味しますが、データの大部分は変更されていません。ほとんどの場合、上記の設定は一定期間内のキャッシュに引き続き適用されます。

データのリアルタイム更新に近い要件がある場合は、getPage(pageIndex) メソッドを 20 秒ごとに実行してリストを再描画するなど、タイマーを使用することが容易に考えられます。しかし、1,000 万ページの訪問という前述の仮定を考える限り、この訪問数と再試行の頻度では、これは間違いなく非常に恐ろしいことであることがわかります。この状況にどう対処するかについては、Gmail、163 Mailbox、Sina Mailbox がメーリング リスト ページをどのように処理しているかを皆さんに見ていただきたいと思います。これらは、毎日の非常に大規模な訪問、データ要件のリアルタイム更新など、以前の想定をほぼ同時に満たしていました。ネットワーク パケット キャプチャ ツールを使用して分析し、ユーザーが同じページ番号のデータを繰り返し要求した場合に、サーバーに要求が行われないことを確認することは難しくありません。メッセージが更新されたときにユーザーに時間通りに通知し、メーリング リストが更新されるようにするために、スケジュールされた繰り返しの非同期リクエストを使用できますが、このリクエストはリストを更新するのではなく、ステータスのクエリのみを実行します。メッセージ更新を含むステータスが取得された場合にのみ、更新データを取得するための要求が開始されます。または、更新が見つかった場合、ステータス クエリ インターフェイスは更新データを直接返します。実際、163 メールボックスのスケジュールされた状態クエリ間隔は 2 分に 1 回程度と比較的長く設定されていますが、Sina メールボックスの間隔は 5 分に 1 回程度と、頑張って数を減らしていることがわかります。リクエストの。ただし、このような処理方法はフロントエンドだけで行えるわけではなく、バックエンドインターフェースと合わせて実装計画を検討する必要があります。

ここで、コード スニペット 2 のデータ キャッシュ メソッドを見てみましょう。リクエストの数とトラフィックの節約についてはもう説明しません。フロントエンドの実装を見て、掘り下げる価値のあるものがあるかどうかを確認してみましょう。コードスニペット 2 で示した処理方法では、元のデータが保存されているため、再度 showPage(datalist) を呼び出すと、そのデータを元に html 構造を再構築してユーザーに表示する必要がありますが、この作成プロセスを実行しています。構造体を初めて作成するときに構造体を直接保存することを検討できますか? これにより、特に構造体がより複雑な場合、JS の繰り返しの計算を減らすことができます。検討する価値があります。もう一度考えてみましょう。この構造は以前にページ上に作成されており、ページをめくるときにそれを破棄して新しい構造を作成することも、ページをめくるときにそれを破棄せずに行うことができますか? . CSS スタイルを制御して非表示にします。ページを繰り返しめくると、これらの作成された構造間で相互に表示または非表示を制御することしかできません。

最後に、ここで説明した方法はすべてのシナリオに適用できるわけではありませんが、インスピレーションが得られるかもしれないので、適切なタイミングで 1 つまたは 2 つ試してみてください。同時に、アイデアが広がれば、リフレッシュ不要のページングだけに応用できる可能性もあります。ここでは、みんなで話し合うためのアイデアをいくつか紹介します。

上記は私があなたのためにまとめたものです。

関連記事:

FirefoxベースのAjax画像アップロード

Ajax読み込み外部ページポップアップレイヤーエフェクト実装方法

Ajaxクロスドメイン(基本ドメイン名は同じ)フォーム送信方法

以上がAjax 非リフレッシュ ページングのパフォーマンス最適化方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。