Quelle est la différence entre le code d'état HTTP 200 (cache) et le code d'état 304?

201

J'utilise le plug-in "Page Speed" de Google pour Firefox pour accéder à mon site Web.

Certains des composants de ma page sont indiqués comme état HTTP:

200 200 (cache) 304

Par la "vitesse de la page" de Google.

Ce qui me dérange, c'est la différence entre 200 (cache) et 304.

J'ai rafraîchi la page plusieurs fois (mais je n'ai pas effacé mon cache) et il semble toujours que mon favicon.ico et quelques images sont status = 200 (cache) tandis que d'autres images ont le statut http 304.

Je ne comprends pas pourquoi la différence.

MISE À JOUR :

En utilisant Google "Page Speed", je reçois un "200 (cache)" pour http://example.com/favicon.ico ainsi que http://cdn.example.com/js/ga.js

Mais, je reçois un statut http "304" pour http://cdn.example.com/js/combined.min.js

Je ne comprends pas pourquoi j'ai deux fichiers JavaScript situés dans le même répertoire / js /, l'un renvoyant un état http 304 et l'autre renvoyant un code d'état 200 (cache).

http caching httpwebrequest http-status-codes cache-control Hank
la source

Réponses:

220

Les éléments avec le code "200 (cache)" ont été remplis directement à partir du cache de votre navigateur, ce qui signifie que les demandes d'origine pour les éléments ont été renvoyées avec des en-têtes indiquant que le navigateur pourrait les mettre en cache (par exemple, à date future Expiresou en- Cache-Control: max-agetêtes), et que au moment où vous avez déclenché la nouvelle demande, ces objets mis en cache étaient toujours stockés dans le cache local et n'avaient pas encore expiré.

Les 304s, par contre, sont la réponse du serveur après que le navigateur a vérifié si un fichier a été modifié depuis la dernière version qu'il avait mise en cache (la réponse étant "non").

Pour des performances Web optimales, il vaut mieux définir un futur lointain Expires:ou un en- Cache-Control: max-agetête pour tous les actifs, puis lorsqu'un actif doit être modifié, changer le nom de fichier réel de l'actif ou ajouter une chaîne de version aux demandes de cet actif. Cela élimine le besoin de faire une demande, sauf si l'actif a définitivement changé de la version dans le cache (pas besoin de cette réponse 304). Google a plus de détails sur l'utilisation correcte de la mise en cache à long terme .

Ben Regenspan
la source
2
Alors, quoi de mieux du point de vue de la vitesse ... "200 (cache)" ou "304" messages d'état http?
Hank
22
200 cache. Quelques bonnes notes à ce sujet ici: developer.yahoo.com/performance/rules.html#expires . Vous voulez un délai d'expiration aussi long que possible sur vos actifs, mais vous devez équilibrer cela avec le fait que vous perdez un certain contrôle de cette façon. Une chose que vous pouvez faire est de définir des expirations durables sur les fichiers, puis, si nécessaire, d'incrémenter un numéro de version d'actif pour ces fichiers. Par exemple, vous pouvez inclure style.css? V1 et incrémenter l'élément <link> dans style.css? V2 en cas de modifications.
Ben Regenspan
1
Justice, alors pourquoi Firebug signale-t-il que pour le ga.js est extrait du cache local (status = 200 cache) alors que le combiné.min.js signale un statut http 304. Ce qui est étrange, c'est que les deux fichiers sont du même type de fichier (JavaScript) et résident dans le même répertoire de serveur. On pourrait penser que les deux seraient soit 200 ou 304, et pas différents
Hank
8
Les en max-age- agetêtes et combinés peuvent également entraîner 200 résultats (cache) s'il ageest inférieur à max-age. La seule exception est lorsque l'utilisateur clique sur le bouton d'actualisation du navigateur, auquel cas un en-tête 304 est envoyé.
yitwail
2
HTML5 Boilerplate recommande de ne pas utiliser la méthode de chaîne de requête de cache-busting - il est préférable de changer href, url,et les srcréférences à chaque fichier pour inclure une « empreinte » (soit un hachage du fichier ou un simple numéro incrémentée), puis dire au serveur pour enlever cette empreinte digitale et simplement servir style.cssou autre chose. Si vous ne pouvez pas faire cela sur le serveur, demandez à votre système de génération de renommer les fichiers réels avec l'empreinte digitale.
iono
62

200 (cache) signifie que Firefox utilise simplement la version mise en cache localement. C'est le plus rapide car aucune demande au serveur Web n'est effectuée.

304 signifie que Firefox envoie une demande conditionnelle "If-Modified-Since" au serveur Web. Si le fichier n'a pas été mis à jour depuis la date d'envoi par le navigateur, le serveur Web renvoie une réponse 304 qui indique essentiellement à Firefox d'utiliser sa version mise en cache. Il n'est pas aussi rapide que 200 (cache) car la demande est toujours envoyée au serveur Web, mais le serveur n'a pas à envoyer le contenu du fichier.

Pour votre dernière question, je ne sais pas pourquoi les deux fichiers JavaScript dans le même répertoire retournent des résultats différents.

James Lawruk
la source
18

Cela m'a aussi jeté longtemps. La première chose que je vérifierais est que vous ne rechargez pas la page en cliquant sur le bouton d'actualisation, qui émettra toujours une demande conditionnelle de ressources et renverra 304s pour de nombreux éléments de la page. Au lieu de cela, montez dans la barre d'URL, sélectionnez la page et appuyez sur Entrée comme si vous veniez de taper à nouveau la même URL, cela vous donnera un meilleur indicateur de ce qui est mis en cache correctement. Cet article explique très bien la différence entre les demandes conditionnelles et inconditionnelles et la façon dont le bouton d'actualisation les affecte: http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about- conditionnel-http-requests-and-the-refresh-button.aspx

Cabot
la source
1
Je ne peux même pas décrire le temps que j'ai passé à essayer de comprendre 304 l'état des demandes à CDN. Bien que vous répondiez à une question un peu différente, vous méritez une prime :-)
Peeech
Vous avez raison: la différence dans les codes est liée au fait que vous rechargez ou pas la même page. Si je recharge une page, je vois dans le moniteur réseau du navigateur un code 304. Mais, si j'accède à une autre URL, qui utilise ces mêmes fichiers, je vois dans le moniteur réseau du navigateur un code 200 (à partir du cache). Dans mon cas, l'autre URL n'était qu'une chaîne de requête ajoutée à l'URL d'origine (la page était essentiellement les mêmes).
aldemarcalazans
8

HTTP 304 n'est "pas modifié". Votre serveur Web indique au navigateur "ce fichier n'a pas changé depuis la dernière fois que vous l'avez demandé". Alors qu'un HTTP 200 indique au navigateur "voici une réponse réussie" - qui doit être renvoyée lorsque c'est la première fois que votre navigateur accède au fichier ou la première fois qu'une copie modifiée est accédée.

Pour plus d'informations sur les codes d'état, consultez http://en.wikipedia.org/wiki/List_of_HTTP_status_codes .

richleland
la source
C'est aussi ce que je comprends ... c'est pourquoi j'ai déclaré dans mon article d'origine que j'avais actualisé ma page plusieurs fois et que j'obtenais toujours le "200 (cache)" pour le même favicon.ico et les JavaScript que j'inclus. Très étrange
Hank
2
200 ne signifie en fait pas mis en cache, cela signifie simplement OK. Les chances sont que la configuration de votre serveur ne dit pas explicitement au navigateur de mettre en cache vos fichiers ico et js, ce qui lui ferait retourner un code d'état de 200.
richleland
Ce n'est pas le cas b / c sur certains de mes JavaScript, je reçois un 304 et autres JavaScript j'obtiens un "200 (cache)". Tout le JavaScript réside dans le même répertoire de serveur Web example.com/js/
Hank
Je dois ajouter que 200 (cache) signifie simplement qu'il est mis en cache localement et ne fait pas de demande au serveur, ce qui sera plus rapide que d'aller au serveur et d'obtenir une réponse 304.
richleland
J'ai mis à jour mon message d'origine pour afficher mon site en direct et le JavaScript en question. S'il vous plaît voir mon message d'origine mis à jour.
Hank
2

Pour votre dernière question, pourquoi? Je vais essayer d'expliquer avec ce que je sais

Une brève explication de ces trois codes de statut en termes simples.

  • 200 - succès (demandes du navigateur et obtention du fichier du serveur)

Si la mise en cache est activée sur le serveur

  • 200 (du cache mémoire) - fichier trouvé dans le navigateur, donc le navigateur ne va pas demander au serveur
  • 304 - le navigateur demande un fichier mais il est rejeté par le serveur

Pour certains fichiers, le navigateur décide de demander au serveur et pour certains, il décide de lire à partir des fichiers stockés (mis en cache). Pourquoi est-ce ? Chaque fichier a une date d'expiration, donc

Si un fichier n'est pas expiré, le navigateur utilisera le cache (200 cache).

Si le fichier a expiré, le navigateur demande au serveur un fichier. Fichier de vérification du serveur aux deux endroits (navigateur et serveur). Si le même fichier est trouvé, le serveur refuse la demande. Selon le protocole, le navigateur utilise le fichier existant.

regardez cette configuration nginx

location / {
    add_header Cache-Control must-revalidate;
    expires     60;
    etag on;

    ...
}

Ici, l'expiration est définie sur 60 secondes, donc tous les fichiers statiques sont mis en cache pendant 60 secondes. Donc, si vous demandez à nouveau un fichier dans les 60 secondes, le navigateur lira de la mémoire (200 mémoires). Si vous demandez après 60 secondes, le navigateur demandera le serveur (304).

J'ai supposé que le fichier n'est pas modifié après 60 secondes, dans ce cas, vous en obtiendriez 200 (c'est-à-dire que le fichier mis à jour sera récupéré sur le serveur).

Par conséquent, si les serveurs sont configurés avec des en-têtes (stratégies) d'expiration et de mise en cache différents, l'état peut différer.

Dans votre cas, vous utilisez cdn, l'objectif principal de cdn est la haute disponibilité et la livraison rapide. Ils utilisent donc plusieurs serveurs. Même s'il semble que les fichiers se trouvent dans le même répertoire, cdn peut utiliser plusieurs serveurs pour fournir du contenu u, si ces serveurs ont des configurations différentes. Ces statuts peuvent alors changer. J'espère que ça aide.

Saahithyan Vigneswaran
la source
Le 304 - Non modifié n'est pas un "rejet" par le serveur. C'est le serveur qui déclare au client "pour la version que vous demandez, je sais qu'elle n'est pas modifiée, vous n'avez pas vraiment besoin du fichier". Techniquement, 304 est l'un des codes de réponse de "redirection". Il dit au client "de l'obtenir de votre propre cache".
Bob Kuhar