Méthode d'optimisation des performances pour la pagination sans rafraîchissement Ajax

Cet article présente principalement des informations pertinentes sur la méthode d'optimisation des performances de la pagination sans rafraîchissement Ajax. Les amis qui en ont besoin peuvent s'y référer

La pagination sans rafraîchissement Ajax est déjà une chose que tout le monde connaît, Il existe probablement une méthode js sur la page Web frontale, qui demande l'interface de données de pagination côté serveur via Ajax. Après avoir obtenu les données, elle crée une structure HTML sur la page et l'affiche à l'utilisateur, similaire à ce qui suit. :

<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>

Parmi eux, RemoteInterface.cgi est une interface côté serveur. Nous sommes ici limités dans l'espace et les exemples de codes impliqués peuvent ne pas être complets, juste pour exprimer clairement le sens.

Sur l'interface utilisateur, il peut y avoir différents styles de commandes de pagination, que tout le monde connaît, tels que :

Mais ce n'est rien de plus que l'utilisateur cliquant sur le contrôle pour déclencher la méthode getPage(pageIndex) ici. Cette méthode getPage n'est peut-être pas si simple. .

Si nous l'écrivons selon l'extrait de code 1, nous pouvons imaginer qu'à chaque fois que l'utilisateur clique pour tourner la page, RemoteInterface.cgi sera demandé une fois, ignorant l'éventuelle mise à jour des données, à l'exception du la première fois, et plus tard Les requêtes d'interface distante déclenchées par chaque getPage(1), getPage(2), getPage(3), etc. et le trafic de données vers et depuis le réseau sont en réalité répétitifs et inutiles. Ces données peuvent être mises en cache sur la page sous une forme ou une autre lorsque chaque page est demandée pour la première fois. Si l'utilisateur souhaite revenir sur la page qu'il a consultée auparavant, la méthode getPage doit d'abord vérifier si le cache local contient la page. data. Si oui, elles seront directement re-présentées à l'utilisateur au lieu d'appeler l'interface distante. Selon cette idée, nous pouvons modifier l'extrait de code 1 comme suit :

<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>

Cela permettra d'économiser le temps d'aller-retour des requêtes réseau. Le plus important est d'économiser le précieux trafic réseau et de réduire la charge sur le serveur d'interface. Dans des environnements à faible vitesse de réseau ou lorsque la pression de fonctionnement du serveur d'interface est déjà relativement élevée, cette amélioration nécessaire peut montrer des effets d'optimisation évidents. La première des 34 fameuses règles Yahoo consiste à minimiser le nombre de requêtes HTTP. Les requêtes asynchrones Ajax entrent sans aucun doute dans le cadre des requêtes http. Les applications Web à faible trafic peuvent sembler inutiles, mais imaginez s'il existe une page comme celle-ci : 10 millions de visites par jour, les utilisateurs tournent en moyenne 5 pages et une page est consultée à plusieurs reprises. Ensuite, une telle page, selon la manière dont l'extrait de code 1 est écrit, déclenchera en moyenne 50 millions de requêtes de données par jour, et selon la manière dont l'extrait de code 2 est écrit, elle peut réduire en moyenne au moins 10 millions de requêtes par jour. . Si la quantité de données demandée à chaque fois est de 20 Ko, vous pouvez économiser 10 millions * 20 Ko = 200 000 000 Ko, soit environ 190 Go de trafic réseau. Les ressources ainsi économisées sont considérables.

Si vous souhaitez approfondir, la méthode de mise en cache des données dans l'extrait de code 2 mérite d'être discutée. Nous avions précédemment supposé que l'actualité des données de pagination pouvait être ignorée, mais dans les applications réelles, l'actualité est un problème inévitable. La mise en cache entraînera sans aucun doute une réduction des délais. Une véritable solution de mise en cache devrait également s'appuyer sur l'analyse et les compromis des exigences de rapidité de l'application.

Pour le contenu qui ne met généralement pas l'accent sur l'actualité, la mise en cache sur la page devrait toujours être acceptable. Premièrement, les utilisateurs ne resteront pas sur une page tout le temps. Lorsqu'il y a un saut entre les pages et un rechargement, cela peut obtenir. données mises à jour. De plus, si l'utilisateur a l'habitude de rafraîchir la page, il peut choisir de rafraîchir la page lorsqu'il souhaite notamment voir s'il y a une mise à jour de données dans la liste. Si vous recherchez la perfection, vous pouvez également envisager de définir une plage de temps, par exemple 5 minutes. Si l'utilisateur est resté sur la page actuelle pendant plus de 5 minutes, sa page tournant dans les 5 minutes lira d'abord le cache de la page, et la page tournant après 5 minutes demandera à nouveau les données du serveur.

Dans certains cas, si nous pouvons prédire la fréquence de mise à jour des données, comme le nombre de jours pendant lesquels une mise à jour des données peut avoir lieu, nous pouvons même envisager d'utiliser le stockage local pour déclencher une demande de données du serveur après une certaine période. de temps, de sorte que la demande Les économies de données et de trafic sont encore plus approfondies. Bien entendu, la méthode de mise en cache appropriée dépend en fin de compte des exigences de rapidité du produit, mais le principe est d'économiser autant que possible les requêtes et le trafic, en particulier pour les pages avec un grand nombre de visites.

Pour un type de données nécessitant des délais élevés, la mise en cache est-elle totalement inappropriée ? Bien sûr que non, mais l'idée générale doit changer ? D'une manière générale, les soi-disant changements peuvent principalement signifier que les données de la liste ont été augmentées, diminuées ou modifiées, mais que la grande majorité des données restent inchangées. Dans la plupart des cas, les paramètres mentionnés ci-dessus sont toujours applicables pour la mise en cache pendant une certaine période.

S'il existe une exigence proche de la mise à jour des données en temps réel, vous pouvez facilement penser à utiliser une minuterie, comme exécuter la méthode getPage(pageIndex) et redessiner la liste toutes les 20 secondes. Mais tant que vous pensez à l'hypothèse précédente de 10 millions de visites de pages, vous constaterez que c'est sans aucun doute une chose très effrayante. Avec ce nombre de visites et la fréquence des tentatives, le serveur est sous forte pression. Concernant la manière de gérer cette situation, je voudrais demander à tout le monde de jeter un œil à la manière dont Gmail, 163 Mailbox et Sina Mailbox gèrent les pages de liste de diffusion. Ils répondent presque simultanément à nos hypothèses précédentes : visites quotidiennes extrêmement importantes, mise à jour en temps réel des besoins en données, etc. Il n'est pas difficile d'analyser avec un outil de capture de paquets réseau et de constater qu'ils ne feront pas de requête au serveur lorsque l'utilisateur demande à plusieurs reprises des données pour le même numéro de page. Afin de garantir que les utilisateurs soient avertis à temps et que la liste de diffusion soit mise à jour lorsqu'il y a une mise à jour du message, une requête asynchrone planifiée et répétée peut être utilisée, mais cette requête effectue uniquement une requête d'état plutôt que d'actualiser la liste. Ce n'est que lorsque l'état avec mises à jour de message est obtenu qu'une demande sera lancée pour obtenir des données mises à jour, ou l'interface de requête d'état renverra directement les données mises à jour lorsqu'une mise à jour est trouvée. En fait, l'intervalle de requête d'état planifié pour 163 boîtes aux lettres est relativement long, environ une fois toutes les deux minutes. L'intervalle de la boîte aux lettres Sina est plus long, environ une fois toutes les 5 minutes. de demandes. Cependant, ce type de méthode de traitement ne peut pas être effectué uniquement par le front-end. Le plan de mise en œuvre doit être considéré dans son ensemble avec l'interface back-end.

Revenons maintenant à la méthode de mise en cache des données dans l'extrait de code 2. Maintenant que nous ne discutons plus du nombre de requêtes et des économies de trafic, jetons un coup d'œil à la mise en œuvre frontale pour voir s'il y a quelque chose qui mérite d'être approfondi. Selon la méthode de traitement présentée dans l'extrait de code 2, les données d'origine sont stockées lorsqu'elles sont à nouveau appelées, showPage(datalist) doit reconstruire à nouveau la structure HTML en fonction des données pour l'afficher à l'utilisateur, mais nous avons effectué ce processus de création. la structure avant. , est-il possible d'envisager de sauvegarder la structure directement lors de la première création de la structure ? Cela peut réduire les calculs répétés de js, surtout lorsque la structure est plus complexe, cela vaut la peine d'y réfléchir. Pensez-y encore, cette structure a déjà été créée sur la page. La détruire et créer une nouvelle structure en tournant la page consomme également des ressources. Pouvez-vous la créer pour la première fois et ne pas la détruire en tournant la page ? . Contrôlez le style CSS pour le masquer, et lorsque vous tournez la page à plusieurs reprises, vous contrôlez uniquement l'affichage ou le masquage des uns et des autres entre ces structures créées ?

Enfin, la méthode évoquée ici n'est peut-être pas applicable à toutes. scénarios, mais soit il y aura de l'inspiration, vous pourrez en essayer un ou deux au moment opportun. Dans le même temps, si les idées sont dispersées, elles ne s’appliqueront peut-être pas uniquement à la pagination sans actualisation. Discutons-en ensemble ici.

Ce qui précède est ce que j'ai compilé pour vous. J'espère que cela vous sera utile à l'avenir.

Articles connexes :

Téléchargement d'images Ajax basé sur Firefox

Méthode de mise en œuvre de l'effet de couche contextuelle de page externe de chargement Ajax

Méthode Ajax inter-domaines (même nom de domaine de base) de soumission de formulaire

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!