Le cache d'Ajax est maintenu par le navigateur. Pour une certaine URL envoyée au serveur, Ajax n'interagit qu'avec le serveur lors de la première demande. Dans les demandes suivantes, Ajax ne soumet plus de demande au serveur, mais extrait les données directement du cache.
Dans certains cas, nous devons obtenir des données mises à jour du serveur à chaque fois. L'idée est de rendre l'URL demandée différemment sans affecter l'application normale: ajouter un contenu aléatoire après l'URL.
par exemple
url = url + "&" + math.random ();
Points clés:
1. L'URL demandée à chaque fois est différente (le cache ajax ne fonctionne pas)
2. Cela n'affecte pas l'application normale (la plus élémentaire)
Ici, nous avons deux conclusions:
1: le cache Ajax et le cache HTTP sont les mêmes
Les mécanismes HTTP et de mise en cache des navigateurs modernes sont bien pires que ceux de l'objet XMLHttpRequest de l'Ajax, il ne reconnaît donc ni ne se soucie des demandes d'Ajax. Il suit simplement les règles de mise en cache HTTP ordinaires et les met en cache via l'en-tête de réponse renvoyée par le serveur.
Si vous avez déjà une compréhension du cache HTTP, vous pouvez utiliser la connaissance du cache HTTP pour comprendre le cache ajax. La seule différence est que la façon de définir les en-têtes de réponse sera différente de celle des fichiers ordinaires.
Les en-têtes de réponse suivants peuvent rendre votre Ajax à cacheable:
Expire: Cet élément doit être réglé sur un point de temps approprié à l'avenir. Le réglage du point temporel dépend de la fréquence des changements de contenu. Par exemple, si la quantité d'inventaire demandée, la valeur de l'expiration peut être de 10 secondes plus tard. Si la photo demandée, la valeur de l'expiration peut être plus longue car elle ne changera pas fréquemment. L'en-tête expiré permet au navigateur de réutiliser les données de cache locales pendant une période de temps, évitant ainsi toute interaction inutile avec les données du serveur.
Dernier mode: La définition de cet élément est un bon choix. Grâce à lui, le navigateur utilisera si-modifié dans l'en-tête de demande pour vérifier le contenu mis en cache local lors de l'envoi d'une demande de GET conditionnelle. Si les données n'ont pas besoin d'être mises à jour, le serveur renverra un état de réponse 304.
Cache-Control: En cas de circonstances appropriées, cette valeur doit être définie en public afin que tout proxy et cache intermédiaires puissent être enregistrés et partagés avec d'autres utilisateurs. Dans Firefox, il prend également en charge Cache pour les demandes HTTPS.
Bien sûr, si vous utilisez la méthode Post pour envoyer Ajax, il ne peut pas être mis en cache, car les demandes de poste ne seront jamais mises en cache. Si votre demande AJAX aura d'autres effets (tels que les transferts entre les comptes bancaires), veuillez utiliser la demande de poste.
Nous avons mis en place une démo (cette démo ne peut plus être vue (□) ノ) pour clarifier le fonctionnement de ces en-têtes. Dans httpwatch, vous pouvez voir que nous définissons les trois en-têtes de réponse ci-dessus dans les informations d'en-tête de réponse.
Si vous cliquez régulièrement sur le bouton «Ajax Update», les changements de temps ont tendance à être toutes les deux minutes. Parce que l'en-tête de réponse expire est réglé à la minute suivante. Dans la capture d'écran ci-dessous, vous pouvez voir: lorsque vous cliquez sur le bouton de mise à jour à plusieurs reprises, la demande Ajax lira le cache local du navigateur sans générer une activité réseau (les valeurs des barres d'envoi et de transfert sont 0)
La demande AJAX envoyée par le dernier clic à 1: 06.531 Time a généré des données réseau transmission car les données mises en cache avaient dépassé une minute. Le serveur a renvoyé l'état de 200 de la réponse pour indiquer qu'une nouvelle copie des données a été obtenue.
Je suppose que cette démo devrait être un bouton, obtenez l'heure actuelle à chaque fois que vous cliquez, puis revenez à la page actuelle.
2: IE Le navigateur ne rafraîchira pas le contenu obtenu via AJAX avant l'expiration du temps.
Parfois, Ajax est utilisé pour remplir certaines parties de la page (comme une liste de prix) lorsque la page est chargée. Il n'est pas déclenché par l'événement d'un utilisateur (comme cliquer sur un bouton), mais est envoyé via JavaScript lorsque la page est chargée. C'est comme si les demandes AJAX étaient les mêmes que les ressources intégrées (comme JS et CSS).
Si vous développez une telle page, lorsque vous la rafraîchissez, vous voudrez peut-être mettre à jour le contenu de demande Ajax intégré. Pour les ressources intégrées (fichiers CSS, images, etc.), le navigateur enverra automatiquement les différents types de demandes suivants en si l'utilisateur se rafraîchisse par F5 (actualisation) ou CTRL + F5 (Force Refresh):
1.F5 (actualiser): Si le contenu de la demande a un en-tête de réponse au dernier modifié, le navigateur enverra une demande de mise à jour conditionnelle. Il utilise l'en-tête de demande If-Modified-Since pour la comparaison, afin que le serveur puisse retourner un statut 304 pour éviter la transmission de données inutiles.
2.CTRL + F5 (Force Refresh): dit au navigateur d'envoyer une demande de mise à jour inconditionnelle, et le contrôle de cache de l'en-tête de demande est défini sur «sans cache». Cela indique à tous les procurations intermédiaires et au cache: le navigateur doit obtenir la dernière version, qu'elle ait été mise en cache.
Firefox propage cette méthode de rafraîchissement aux demandes AJAX envoyées lorsque la page est chargée et traite ces demandes AJAX comme des ressources intégrées. Vous trouverez ci-dessous une capture d'écran de HttpWatch sous Firefox, montrant l'effet des demandes AJAX lors de la page rafraîchissante (F5):
Firefox garantit que la demande initiée par Ajax est conditionnelle. Dans cet exemple, si les données sont mises en cache pendant moins de 10 secondes, le serveur renvoie 304, s'il dépasse 10 secondes, le serveur renvoie 200 et retransmet les données.
Dans IE, la demande Ajax initiée lorsque la page est chargée est considérée comme n'a rien à voir avec la rafraîchissement des autres parties de la page et ne sera pas affectée par la méthode de rafraîchissement de l'utilisateur. Si les données AJAX mises en cache n'ont pas expiré, il n'y aura pas de demandes de GET envoyées au serveur. Il lira les données directement à partir du cache, et à partir de httpwatch, c'est le résultat (cache). Le chiffre suivant est d'appuyer sur F5 pour actualiser si le cache n'est pas expiré sous IE:
Même s'il est obligé de se rafraîchir via CTRL + F5, les données obtenues via Ajax seront lues à partir du cache:
Cela signifie que tout ce qui est obtenu via Ajax ne sera pas mis à jour sous IE s'il n'a pas expiré - même si vous utilisez Ctrl + F5 pour forcer la rafraîchissement. La seule façon de vous assurer que vous obtenez les dernières données est d'effacer manuellement le cache. Vous pouvez utiliser la barre d'outils HttpWatch:
Notez que le résultat du cache et le résultat 304 sont différents. Le cache est en fait de 200 (cache), 304 signifie 304. Le cache n'envoie pas de demande au serveur. Vous pouvez voir sur Chrome que son temps est de 0 et que la réponse est également vide. Cependant, 304 est différent.
La demande 304 est une demande conditionnelle initiée par le navigateur. Cette demande comporte l'en-tête de demande si-modifiée à la demande. Si le fichier n'a pas été modifié après que le navigateur envoie le temps, le côté serveur renvoie un statut 304 et dise au navigateur d'utiliser son contenu de cache local. Il n'est pas aussi rapide que la demande est envoyée du côté serveur, mais le côté serveur n'envoie pas de données.
Vous pouvez vérifier la page d'accueil de Taobao, qui a à la fois 200 (cache) et 304. Vous pouvez vérifier leurs différences.
Résumer:
Nous savons tous que la principale raison pour laquelle Ajax peut augmenter la vitesse du chargement des pages est qu'il réduit le chargement des données en double via AJAX et réellement une acquisition à la demande. Étant donné que c'est le cas, lorsque nous écrivons le programme AJAX, nous pourrions aussi bien l'envoyer à l'ouest et le mettre à nouveau sur le client pour améliorer davantage la vitesse de chargement des données. C'est-à-dire pour mettre en cache les données dans la mémoire du navigateur lors du chargement des données. Une fois les données chargées, tant que la page n'est pas actualisée, les données seront mises en cache dans la mémoire pour toujours. Lorsque l'utilisateur considère à nouveau les données, il n'est pas nécessaire d'obtenir des données du serveur, ce qui réduit considérablement la charge du serveur et améliore l'expérience de l'utilisateur.