Lors de la navigation sur mon site, mon navigateur charge les fichiers JS à partir du cache, mais pas les fichiers CSS. Cela se produit à la fois en exécutant un serveur local et sur le site en direct (pour moi et apparemment pour les autres utilisateurs, ce qui est apparent puisque les journaux montrent principalement des fichiers .css en cours de chargement).
J'ai essayé les autres solutions ( exemple ): je clique sur des liens hypertexte (pas d'actualisation) et mes outils de développement Chrome n'ont pas coché" Désactiver le cache ".
Voici la requête initiale (en utilisant CTRL + F5 pour une actualisation matérielle):
Le retour à cette page crée une autre demande:
(Remarque: il n'y a pas de Cache-Control envoyé dans la deuxième requête, ce qui prouve que je n'ai effectivement pas rafraîchi)
Comme prévu, le serveur répond avec un 304 Not-Modified pour le fichier .css, mais je ne comprends pas du tout pourquoi il fait un voyage vers le serveur (remarque ci-dessous, le fichier .js est récupéré sans requête du serveur ).
Je pense que vous pouvez examiner le problème de première main sur votre propre ordinateur en accédant à https://up.codes . J'utilise Chrome 71.0.
Pourquoi les fichiers CSS ne sont-ils pas mis en cache?
4 Réponses :
Vérifiez l'attribut de compilation de votre web.config, si son:
<compilation debug=â€trueâ€/>
CSS sera continuellement téléchargé par les clients à chaque demande de page vue et non mis en cache localement dans le navigateur.
Si elle est définie sur false, la ressource n'est téléchargée qu'une seule fois sur le client et y est mise en cache.
Consultez ce post: Chrome ne mettra pas en cache les fichiers CSS. Les fichiers .js fonctionnent bien
Merci d'avoir répondu! Malheureusement, je n'utilise pas IIS comme dans la réponse liée, mais plutôt Flask (Python). Mais en fait, je pense que ce problème est indépendant de la technologie du serveur. Il y a un problème avec mon en-tête de réponse, avec Chrome ou avec ma compréhension du fonctionnement de la mise en cache.
Chrome utilise plusieurs types de caches.
Blink (le moteur de rendu utilisé par Chrome) utilise un cache mémoire et un cache disque. Il utilise ce cache pour les images, les polices et les fichiers js. Tant qu'un fichier de ce type est toujours dans le cache mémoire ou le cache de fichiers, il sera chargé à partir de là et ignorer l'API WebRequest, cela signifie qu'aucun appel n'est effectué vers le serveur.
Je ne sais pas exactement pourquoi les fichiers css ne sont pas mis en cache par Blink, mais c'est la raison pour laquelle vous voyez une requête HTTP pour les fichiers css et non pour ceux js.
Notez que si, pour une raison quelconque, le fichier js est expulsé du cache mémoire et du cache disque, vous verrez également une requête HTTP pour les fichiers js.
Merci, c'est bon à savoir, en particulier comme point de départ pour explorer le code source de Chromium si cela se produit. Étrangement, tous les autres sites semblent fonctionner correctement (par exemple, les fichiers CSS de Stack Overflow indiquent (à partir du cache disque) dans la colonne "Size").
Votre serveur a répondu avec un cookie de session différent lors de la demande de ces fichiers css, et votre en-tête défini avec Vary: Cookie, ce qui a poussé le navigateur à renvoyer la demande en raison du changement de cookie de session.
Merci, vous avez raison! En effet, les requêtes .css avaient différents cookies envoyés tandis que les requêtes .js envoyaient le même cookie. Je ne sais pas pourquoi, mais c'était une solution facile de modifier l'en-tête Vary pour ne pas avoir de Cookie dans lequel je voir ci-dessous pour le cas de Flask.
@Allen a trouvé le problème (l'en-tête Vary inclus cookie et le cookie changeait entre les requêtes), mais je vais montrer comment corrigez-le pour le cas de Flask pour la postérité. Vous pouvez utiliser le @ app.after_request () code> hook pour vous assurer que Flask n'ajoute pas de cookie lorsqu'il atteint cette ligne :
@app.after_request
def add_header(response):
url = request.url
if ('.css' in url or '.js' in url or '.svg' in url or '.png' in url or
'.gif' in url) :
# Flask adds to the header `Vary: cookie` meaning the client should
# re-download the asset if the cookie changed. If you look at the Flask
# source code that comes next after the below return, it will add
# `Vary: cookie` if and only if session.accessed is true.
session.accessed = False
return response
vous devez utiliser nginx comme serveur frontal pour gérer ces fichiers statiques. docs.gunicorn.org/en/stable/deploy.html
@Allen - Ce n'est pas mutuellement exclusif avec cette réponse. Dans mon cas, j'ai nginx devant l'application flask configuré comme une mise en cache, avec des chemins d'application spécifiques ( / static , dans mon cas) ayant un paramètre proxy_cache_timeout extrêmement long . De cette façon, vous pouvez simplement utiliser le serveur intégré pour les tests, et la version déployée bénéficie toujours d'un frontal rapide.
Je n'ai pas compris quelle est votre question et ce dont vous avez besoin? Personne ne vous répondra sans cela. Souhaitez-vous l'écrire, s'il vous plaît.
@Bharata, ok j'ai clarifié la question en bas, merci.
@Garrett Je viens de vérifier votre site et tous vos fichiers css ont été mis en cache très bien de mon côté. J'obtiens également le statut 304 - NON MODIFIÉ pour tous après la première fois que je les ai téléchargés. Êtes-vous sûr de ne pas avoir défini de mode de débogage de votre côté qui oblige tous les actifs à être retéléchargés? Je vois que vos en-têtes de requête contiennent "Cache-Control: no-cache" ...
@m_katsifarakis, merci, j'ai ajouté un paragraphe / une image pour clarifier. On dirait que nous avons le même comportement. Je reçois également un 304 lorsque j'atteins le serveur lors de la deuxième requête, mais je ne veux pas du tout être une requête.
@m_katsifarakis, la première requête a en effet un "Cache-Control: no-cache" car j'ai fait un hard refresh (CTRL + F5) pour la première. J'aurais également pu simplement ouvrir Incognito et accéder à la page pour la première fois - à la deuxième demande, le problème se manifeste toujours.
Je ne comprends toujours pas ce que vous aimeriez avoir. Voulez-vous savoir pourquoi cela se produit OU (pas et) voulez-vous savoir comment obtenir cela ... [votre souhait]? Après avoir répondu à la question, vous ne pouvez pas poser une deuxième question. Souhaitez-vous le décrire, s'il vous plaît.
@Bharata, j'aimerais que les fichiers CSS soient chargés à partir de la mémoire au lieu de faire une demande pour que mon site se sente plus rapide. Je voudrais savoir comment faire cela ou savoir pourquoi cela se produit pour que je puisse y remédier.
Que signifie
(de moi ...), est-ce "de mémoire"?Lors du rechargement, je n'obtiens que l'url principale et la police google chargées avec 200 tout le reste avec 304 du cache.
vous pouvez forcer votre navigateur à utiliser le dernier css en ajoutant quelque chose comme yourfile.css? microtime = 23394824. Est-il possible qu'il y ait un? après votre fichier css?
@David, oui, exactement, qui est tronqué de
(du cache mémoire). Intéressant pour votre comportement de rechargement. Ainsi, lorsque vous rechargez, pour le fichierglobal.css, qu'est-ce qui apparaît dans la colonne "Taille" de l'onglet Réseau DevTools?@ User23332, c'est vrai, c'est exactement ce que je fais pour appliquer le dernier CSS. Vous remarquerez dans les DevTools que j'ai une chaîne de requête ajoutée aux fichiers CSS (et JS) ressemblant à:
? V = d04f0cc. Le but ici est que le navigateur charge les fichiers CSS à partir du cache jusqu'à ce que la chaîne de requête change.@Garrett, cette ressource peut vous être utile: css-tricks.com/strategies -for-cache-contournement-css
@Garret vous devriez le vérifier dans différents navigateurs, y compris la modification des paramètres de cache. Donc, il obtiendrait une longue liste si je le faisais et que je le publiais ensuite.
@Garret J'ai remarqué ce comportement dans Chrome et Safari sur plusieurs sites, pas seulement le vôtre. Les en-têtes de contrôle du cache me semblent tous corrects, mais pour une raison quelconque, ils indiquent un déclenchement du serveur. Je ne comprends pas vraiment pourquoi, mais cela semble omniprésent dans mon rapide coup d'œil.