caching - Arrêtez le navigateur pour faire des requêtes HTTP pour les images qui doivent rester en cache - mod_expires

Translate

Après avoir lu de nombreux articles et quelques questions ici,J'ai finalement réussi à activer l'Apachemod_expirespour dire au navigateur qu'il DOIT mettre en cache les images pendant 1 an.

<filesMatch "\.(ico|gif|jpg|png)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</filesMatch>

Et heureusement, les réponses du serveur semblent correctes:

HTTP/1.1 200 OK 
Date: Fri, 06 Apr 2012 19:25:30 GMT 
Server: Apache 
Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT 
Accept-Ranges: bytes 
Content-Length: 24884 
Cache-Control: max-age=31536000, public 
Expires: Sat, 06 Apr 2013 19:25:30 GMT
Connection: close
Content-Type: image/jpeg 

Eh bien, je pensais que cela empêcherait le navigateur de télécharger et même demanderait au serveur les images pendant 1 an. Mais c'est partiellement vrai: parce quesi vous fermez et rouvrez le navigateur, le navigateur ne télécharge PAS les imagesdu serveur plus,mais le navigateur interroge toujours le serveur avec une requête HTTP pour chaque image.

Comment forcer le navigateur à arrêter de faire des requêtes HTTP pour chaque image? Même si ces requêtes HTTP ne sont pas suivies d'une image en cours de téléchargement, ce sont toujours des requêtes adressées au serveurcela augmente inutilement la latence et ralentit le rendu de la page!

J'ai déjà dit au navigateur qu'il DOIT garder les images en cache pendant 1 an! Pourquoi le navigateur demande-t-il toujours au serveur chaque image (même s'il ne télécharge pas l'image)?!


En regardant les graphiques du réseau dans FireBug (menu FireBug> Net> Images), je peux voir différents comportements de mise en cache (j'ai évidemment commencé avec le cache du navigateur complètement vide, j'ai forcé une suppression du cache sur le navigateur en utilisant "Effacer tout l'historique"):

  • Lorsque la page est chargée pour la première fois, toutes les images sont téléchargées(et la même chose se produit si je force le rechargement d'une page en cliquant sur le bouton de rechargement de la page du navigateur).C'est logique!

  • Lorsque je navigue sur le site et que je reviens à la même pageles images ne sont pas du tout téléchargées et lele navigateur ne demande même PAS au serveurpour l'une des images.Cela a du sens, (et j'aimerais voir ce comportement également lorsque le navigateur est fermé)!

  • Lorsque je ferme le navigateur et que je l'ouvre à nouveau sur la même page, le navigateur stupide fait de toute façon une requête HTTP au serveur une fois par image: il ne rétrograde PAS l'image, mais il fait toujours une requête HTTP, c'est comme si le navigateur interrogeait le serveur à propos de l'image(le serveur répond par 200 OK).C'est celui qui m'irrite!

Je joins également les graphiques ci-dessous si vous êtes intéressé:

enter image description here

enter image description here

EDIT: je viens de tester maintenant aussi avec FireFox 11.0 juste pour m'assurer que ce n'était pas un problème de mon FireFox 3.6 étant trop vieux. La même chose arrive !!!J'ai également testé le site Google et le site Stackoverflow, ils envoient tous les deux leCache-Control: max-age=...maisle navigateur fait toujours une requête HTTP au serveur pour chaque image une fois que le navigateur est fermé et rouvert sur la même page, après la réponse du serveur, le navigateur ne télécharge PAS l'image (comme je l'ai expliqué ci-dessus) mais il fait toujours la foutue demande qui augmente le temps de voir la page.

EDIT2: et en supprimant leLast-Modifieden-tête comme suggéréici, ne résout pas le problème, cela ne fait aucune différence.

This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

Vous utilisiez le mauvais outil pour analyser les demandes.

Je recommanderais l'addon Firefox vraiment utileEn-têtes HTTP en directafin que vous puissiez voir ce qui se passe réellement sur le réseau.

Et juste pour être sûr, vous pouvez ssh / putty votre serveur et faire quelque chose comme

tail -f /var/log/apache2/access.log
La source
Translate

Le comportement que vous observez est celui prévu (voirRFC7234pour plus de détails), comportement spécifié:

Tous les navigateurs modernes enverront des requêtes HTTP au serveur pour chaque élément de page affiché, quel que soit l'état du cache. Il s'agissait d'une décision de conception prise à la demande des services Web (en particulier des réseaux publicitaires) pour s'assurer que les serveurs HTTP étaient en mesure de conserver des enregistrements de chaque affichage de chaque élément.

Si les navigateurs n'effectuaient pas ces demandes, le serveur ne serait jamais averti qu'une image avait été affichée à l'utilisateur. Pour les réseaux publicitaires, ce serait catastrophique. Dès le début, les réseaux publicitaires ont «piraté» leur chemin en diffusant la même image d'annonce en utilisant des noms générés aléatoirement (ex: «coke_ad_1_98719283719283.gif»). Cependant, pour les FAI, cette pratique a entraîné une augmentation considérable des transferts de données, car chacun de leurs utilisateurs téléchargeait à nouveau ces images publicitaires identiques, en contournant les serveurs de mise en cache / proxy que leur FAI exploitait.

Une trêve a donc été atteinte: les navigateurs enverraient toujours des requêtes HTTP, même pour les éléments mis en cache non expirés. Les serveurs répondraient avec des codes d'état HTTP 304 ("non modifiés"). Cela permet aux serveurs d'enregistrer le fait que l'image a été affichée au client. En conséquence, les réseaux publicitairesgénéralementarrêté d'utiliser des noms d'image aléatoires pour contourner les serveurs de cache réseau.

Cela a donné aux réseaux publicitaires ce qu'ils voulaient - un enregistrement de chaque image affichée - et cela a donné aux FAI ce qu'ils voulaient - des images pouvant être mises en cache et du contenu statique.

C'est pourquoi vous ne pouvez pas faire grand-chose pour empêcher les navigateurs d'envoyer des requêtes HTTP pour les éléments de page mis en cache.

Mais si vous regardez d'autres solutions côté client disponibles fournies avec html5, il existe une possibilité d'empêcher le chargement des ressources

  1. Manifeste du cache(malgré ses pièges)
  2. IndexedDB(belles fonctionnalités asynchrones, permet le stockage d'objets blob)
  3. Stockage local(pas asynchrone)
La source
Translate

Il y a une différence entre «recharger» et «rafraîchir». Le simple fait de naviguer vers une page avec des boutons Précédent et Suivant n'initie généralement pas de nouvelles requêtes HTTP, mais en appuyant spécifiquement sur F5 pour "rafraîchir" la page, le navigateur revérifiera son cache. Cela dépend du navigateur, mais semble être la norme pour FF et Chrome (c'est-à-dire les navigateurs qui ont la capacité de surveiller facilement leur trafic réseau.) En appuyant sur F6, entrez devrait concentrer la barre d'adresse URL, puis "allez" dessus, ce qui devrait rechargez la page mais ne vérifiez pas les éléments de la page.

Mettre à jour: clarification du comportement de navigation arrière et avant. Il s'appelle "Back Forward Cache" ouBFCachedans les navigateurs. Lorsque vous naviguez avec les boutons Précédent / Suivant, l'intention est de vous montrer exactement comme la page était lorsque vous l'avez vue dans votre propre chronologie. Aucune demande de serveur n'est effectuée lors de l'utilisation de la fonction aller-retour, même si un en-tête de cache de serveur indique qu'un élément particulier a expiré.

Si vous voyez (200 OK BFCache) dans votre panneau de réseau de développeur, alors le serveur n'a jamais été touché - même pour demander si-modifié-depuis.

http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfcache/

La source
Translate

Si je force une actualisation en utilisant F5 ou F5 + Ctrl, une demande est envoyée. Cependant, si je ferme le navigateur et que je saisis à nouveau l'URL, aucune demande n'est envoyée. La façon dont j'ai testé si une demande est envoyée ou non était en utilisant des points d'arrêt à la demande de début sur le serveur, même si une demande n'est pas envoyée, elle apparaît toujours dans Firebug comme ayant fait une attente de 7 ms, alors méfiez-vous de cela.

La source
Translate

Ce que vous décrivez ici ne reflète pas mon expérience. Si le contenu est servi avec une directive no-store ou si vous effectuez une actualisation explicite, alors oui, je m'attendrais à ce qu'il retourne au serveur d'origine, sinon il devrait être mis en cache lors des redémarrages du navigateur (en supposant que cela soit autorisé et qu'il puisse écrire un fichier cache).

En regardant vos chutes d'eau un peu plus en détail (ce qui est délicat car elles sont un peu petites et floues), le navigateur semble faire exactement ce qu'il devrait - ilaentrées pour les images - mais elles ne font que chargerà partir du cache localpas du serveur d'origine - vérifiez l'en-tête «Date» dans la réponse (pourquoi pensez-vous que cela prend des millisecondes au lieu de secondes?). C'est pourquoi ils sont colorés différemment.

La source
Translate

Après avoir passé beaucoup de temps à chercher une réponse raisonnable, j'ai trouvé le lien ci-dessous le plus utile et il répond à la question posée ici.

https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests

La source
Translate

S'il s'agit d'une question de vie ou de mort (si vous souhaitez optimiser le chargement de la page de cette façon ou si vous souhaitez réduire au maximum la charge sur le serveur, quoi qu'il arrive), il existe une solution de contournement.

Utilisez HTML5stockage localpour mettre en cache les images après leur première demande.

  • [+]Vous pouvez empêcher le navigateur d'envoyer des requêtes HTTP, qui dans 99% renverraient 304 (Non modifié), peu importe les efforts de l'utilisateur (F5, ctrl + F5, revisitant simplement la page, etc.)

  • [-]Vous devez déployer des efforts supplémentaires dans la prise en charge de javascript pour cela.

  • [-]Les images sont stockées en base64 (nous ne pouvons pas stocker de données binaires), c'est pourquoi elles sont décodées à chaque fois côté client. Lequel estd'habitudeassez rapide et pas grand-chose, mais cela reste une utilisation supplémentaire du processeur côté client et doit être gardé à l'esprit.

  • [-]Le stockage local est limité. Vous pouvez viser à utiliser ~ 5 Mo de données par domaine (Remarque: base64 ajoute ~ 30% à la taille d'origine de l'image).

  • [?]Supporté parmajoritédes navigateurs.http://caniuse.com/#search=localstorage

Exemple

Tester

La source
Translate

Ce que vous voyez dans Chrome n'est pas un enregistrement des requêtes HTTP réelles - c'est un enregistrement des requêtes d'actifs. Chrome fait cela pour vous montrer qu'un élément est effectivement demandé par la page. Cependant, cette vue n'indique pas vraiment si la demande est en cours. Si un élément est mis en cache, Chrome ne créera jamais réellement la requête HTTP sous-jacente.

Vous pouvez également le confirmer en survolant les segments violets de la chronologie. Les ressources mises en cache auront un(from cache)dans l'info-bulle.

Afin de voir les requêtes HTTP réelles, vous devez regarder à un niveau inférieur. Dans certains navigateurs, cela peut être fait avec un plugin (comme Live HTTP Headers).

En réalité cependant, pour vérifier que les requêtes ne sont pas réellement effectuées, vous devez vérifier les journaux de votre serveur ou utiliser un proxy de débogage comme Charles ou Fiddler. Cela fonctionnera au niveau HTTP pour s'assurer que les requêtes ne se produisent pas réellement.

La source
Translate

Validation du cache et réponse 304

Il existe un certain nombre de situations dans lesquelles Internet Explorer doit vérifier si une entrée mise en cache est valide:

  • L'entrée mise en cache n'a pas de date d'expiration et le contenu est accédé pour la première fois dans une session de navigateur

  • L'entrée mise en cache a une date d'expiration, mais elle a expiré

  • L'utilisateur a demandé une mise à jour de la page en cliquant sur le bouton Actualiser ou en appuyant sur F5

Si l'entrée en cache a une date de dernière modification, IE l'envoie dans l'en-tête If-Modified-Since d'un message de demande GET:

GET /images/logo.gif HTTP/1.1
Accept: */*
Referer: http://www.google.com/
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.google.com

Le serveur vérifie l'en-tête If-Modified-Since et répond en conséquence. Si le contenu n'a pas été modifié depuis la date / heure spécifiée, il répond avec un code d'état 304 et un message de réponse contenant uniquement des en-têtes:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: GWS/2.1
Content-Length: 0
Date: Thu, 04 Oct 2004 12:00:00 GMT

La réponse peut être rapidement téléchargée car elle ne contient aucun contenu et oblige IE à lire les données dont il a besoin à partir du cache. En fait, c'est comme une redirection vers le cache du navigateur local.

Si l'objet demandé a réellement changé depuis la date / heure dans l'en-tête If-Modified-Since, le serveur répond avec un code d'état de 200 et fournit la version modifiée de la ressource.

La source
Translate

Cette question a une meilleure réponseicisur le site d'échange de piles des webmasters.

Plus d'informations, qui sont également citées dans le lien ci-dessus, sont disponibles surhttpwatch

Selon l'article:

Il existe un certain nombre de situations dans lesquelles Internet Explorer doit vérifier si une entrée mise en cache est valide:

  • L'entrée mise en cache n'a pas de date d'expiration et le contenu est accédé pour la première fois dans une session de navigateur
  • L'entrée mise en cache a une date d'expiration, mais elle a expiré
  • L'utilisateur a demandé une mise à jour de la page en cliquant sur le bouton Actualiser ou en appuyant sur F5

    entrez le code ici

La source
Leave a Reply
You must be logged in to post a answer.
A propos de l'auteur