Comment forcer browser à recharger les fichiers CSS/JS?

mise à Jour: Réécrit pour tenir compte des suggestions de Jean Millikin et da5id . Cette solution est écrite en PHP, mais doit être facilement adaptée à d'autres langues.

mise à Jour 2: Incorporant les commentaires des Nick Johnson que l'original .htaccess regex peut causer des problèmes avec des fichiers comme json-1.3.js . La Solution est de réécrire seulement si il y a exactement 10 chiffres à la fin. (Car 10 chiffres couvrent tous les horodateurs du 9/9/2001 au 11/20/2286.)

tout d'Abord, nous utilisons la règle de réécriture suivante .htaccess:

RewriteEngine on
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ . [L]

maintenant, nous écrivons la fonction PHP suivante:

/**
 *  Given a file, i.e. /css/base.css, replaces it with a string containing the
 *  file's mtime, i.e. /css/base.1221534296.css.
 *  
 *  @param $file  The file to be loaded.  Must be an absolute path (i.e.
 *                starting with slash).
 */
function auto_version($file)
{
  if(strpos($file, '/') !== 0 || !file_exists($_SERVER['DOCUMENT_ROOT'] . $file))
    return $file;

  $mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $file);
  return preg_replace('{\.([^./]+)$}', ".$mtime.$1", $file);
}

maintenant, où que vous incluez votre CSS, changez-le de ceci:

<link rel="stylesheet" href="/css/base.css" type="text/css" />

à ceci:

<link rel="stylesheet" href="<?php echo auto_version('/css/base.css'); ?>" type="text/css" />

de Cette façon, vous n'avez jamais il faut modifier à nouveau la balise de lien, et l'utilisateur verra toujours le dernier CSS. Le navigateur sera en mesure de mettre en cache le fichier CSS, mais lorsque vous apportez des modifications à votre CSS, le navigateur le verra comme une nouvelle URL, de sorte qu'il n'utilisera pas la copie mise en cache.

cela peut aussi fonctionner avec des images, favicons, et JavaScript. Fondamentalement, tout ce qui n'est pas généré dynamiquement.

côté Client Simple Technique

en général, la mise en cache est bonne.. Il y a donc quelques techniques, selon que vous réglez le problème vous-même pendant que vous développez un site web, ou que vous essayez de contrôler le cache dans un environnement de production.

Généralités les visiteurs de votre site web n'auront pas la même expérience que vous avez lorsque vous développez le site. Puisque le visiteur moyen vient à le site moins souvent (peut-être seulement quelques fois par mois, sauf si vous êtes un Google ou hi5 réseaux), puis ils sont moins susceptibles d'avoir vos fichiers en cache, et cela peut être suffisant. Si vous voulez forcer une nouvelle version dans le navigateur, vous pouvez toujours ajouter une chaîne de requête à la demande, et remonter le numéro de version lorsque vous apportez des modifications majeures:

<script src="/myJavascript.js?version=4"></script>

cela assurera que tout le monde obtienne le nouveau fichier. Cela fonctionne parce que le navigateur regarde l'URL du fichier pour déterminer s'il y a une copie en cache. Si votre serveur n'est pas configuré rien à faire avec la chaîne de requête, il sera ignoré, mais le nom ressemble un nouveau fichier dans le navigateur.

d'un autre côté, si vous développez un site web, vous ne voulez pas changer le numéro de version à chaque fois que vous enregistrez un changement à votre version de développement. Que serait fastidieux.

donc pendant que vous développez votre site, un bon truc serait d'automatiquement générer un paramètre de chaîne de requête:

<!-- Development version: -->
<script>document.write('<script src="/myJavascript.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>

ajouter une chaîne de requête à la requête est un bon moyen de modifier une ressource, mais pour un simple site Web, cela peut être inutile. Et rappelez-vous, la mise en cache est une bonne chose.

il est également intéressant de noter que le navigateur n'est pas nécessairement radin sur la conservation des fichiers en cache. Les navigateurs ont des politiques pour ce genre de chose, et ils jouent habituellement selon les règles établies dans la spécification HTTP. Lorsqu'un le navigateur fait une requête à un serveur, une partie de la réponse est un en-tête EXPIRES.. une date qui indique au navigateur combien de temps il doit être gardé en cache. La prochaine fois que le navigateur tombe sur une requête pour le même fichier, il voit qu'il a une copie dans le cache et regarde la date D'expiration pour décider s'il doit être utilisé.

alors croyez-le ou non, c'est en fait votre serveur qui rend ce cache de navigateur si persistant. Vous pouvez ajuster les paramètres de votre serveur et changer les en-têtes EXPIRES, mais la petite technique que j'ai écrite ci-dessus est probablement une façon beaucoup plus simple pour vous de le faire. Puisque la mise en cache est bonne, vous voulez généralement mettre cette date très loin dans le futur (un "en-tête far-future Expires"), et utiliser la technique décrite ci-dessus pour forcer un changement.

si vous êtes intéressé par Plus d'informations sur HTTP ou comment ces requêtes sont faites, un bon livre est" Sites Web de haute Performance " par Steve Souders. C'est une très bonne introduction sur le sujet.

Google mod_pagespeed le plugin pour apache fera de l'Auto-version pour vous. C'est vraiment lisse.

il analyse HTML à sa sortie du serveur web (fonctionne avec PHP, rails, python, HTML statique -- anything) et réécrit les liens vers CSS, JS, les fichiers image afin qu'ils incluent un code id. Il sert les fichiers aux URL modifiées avec un contrôle de cache très long sur eux. Lorsque les fichiers changent, il change automatiquement les URLs de sorte que le navigateur a pour récupérer à nouveau. Cela fonctionne simplement, sans aucune modification de votre code. Il minifiera même votre code en sortant aussi.

au lieu de changer la version manuellement, je vous recommande d'utiliser un hachage MD5 du fichier CSS actuel.

donc votre URL serait quelque chose comme

http://mysite.com/css/[md5_hash_here]/style.css

vous pouvez toujours utiliser la règle de réécriture pour supprimer le hachage, mais l'avantage est que maintenant vous pouvez définir votre politique de cache à" cache forever", car si L'URL est la même, cela signifie que le fichier est inchangé.

vous pouvez alors écrire un shell simple script qui calculera le hachage du fichier et mettra à jour votre balise (vous voudrez probablement le déplacer dans un fichier séparé pour inclusion).

exécutez simplement ce script à chaque fois que CSS change et vous êtes bon. Le navigateur ne rechargera vos fichiers que lorsqu'ils seront modifiés. Si vous faites une édition et que vous la supprimez, il n'y a pas de peine à trouver la version vers laquelle vous devez retourner pour que vos visiteurs ne se téléchargent pas.

Je ne sais pas pourquoi vous avez tant de peine à mettre en œuvre cette solution.

Tout ce que vous devez faire si obtenir le timestamp modifié du fichier et l'ajouter comme un querystring au fichier

En PHP, je le ferais comme:

<link rel="stylesheet" href="mycss.css?v=<?php echo filemtime('mycss.css') ?>"/>

filemtime est une fonction PHP qui renvoie le fichier timestamp modifié.

vous pouvez simplement mettre ?foo=1234 à la fin de votre importation css / js, en changeant 1234 pour être ce que vous voulez. Jetez un coup d'oeil à la source so html pour un exemple.

L'idée étant que le ? les paramètres sont rejetés / ignorés sur la requête de toute façon et vous pouvez changer ce nombre lorsque vous lancez une nouvelle version.

Note: il y a un certain argument concernant la façon exacte dont cela affecte cache. Je crois que l'essentiel est que les requêtes GET, avec ou sans paramètres devraient être cachables, donc la solution ci-dessus devrait fonctionner.

cependant, c'est à la fois le serveur web de décider s'il veut adhérer à cette partie de la spécification et le navigateur que l'utilisateur utilise, car il peut juste aller de l'avant et demander une nouvelle version de toute façon.

j'ai entendu"auto versioning". La méthode la plus courante est d'inclure le mtime du fichier statique quelque part dans L'URL, et de le supprimer en utilisant des gestionnaires de réécriture ou des confs URL:

voir aussi:

• actifs Automatique gestion des versions dans Django
• Version Automatique vos fichiers CSS et JavaScript

la trentaine de réponses existantes est un bon conseil pour un site web circa 2008. Cependant, quand il s'agit d'une application moderne single page application (SPA), il pourrait être temps de repenser certaines hypothèses fondamentales... spécifiquement l'idée qu'il est souhaitable que le serveur web ne serve que la version unique, la plus récente d'un fichier.

Imaginez que vous êtes un utilisateur qui a la version M D'un SPA chargé dans votre navigateur:

1. votre pipeline CD déploie la nouvelle version N de l'application sur le serveur
2. vous naviguez dans le SPA, qui envoie un XHR au serveur pour obtenir /some.template
   • (votre navigateur n'a pas rafraîchi la page, donc vous utilisez toujours la version M )
3. Le serveur répond avec le contenu de /some.template - voulez-vous qu'il retourne la version M ou N du modèle?

si le format de /some.template a changé entre les versions M et N (ou le fichier a été renommé ou autre) vous ne voulez probablement pas la version N du modèle envoyé au navigateur qui exécute l'ancienne version M du parser .†

Web apps rencontrer ce genre de problème lorsque les deux conditions suivantes sont remplies:

• les ressources sont demandées de façon asynchrone après le chargement initial de la page
• L'application de la logique suppose choses (qui peuvent changer dans les versions futures) sur le contenu d'une ressource

une fois que votre application a besoin de servir plusieurs versions en parallèle, résoudre la mise en cache et "rechargement" devient trivial:

1. : /v<release_tag_1>/…files… , /v<release_tag_2>/…files…
2. définir les en-têtes HTTP pour laisser les navigateurs mettre en cache des fichiers pour toujours
   • (ou mieux encore, mettez tout en CDN)
3. mettre à jour toutes les étiquettes <script> et <link> , etc. pour pointer vers ce fichier dans l'un des versionnées dirs

cette dernière étape semble délicate, car elle pourrait nécessiter d'appeler un constructeur D'URL pour chaque URL dans votre code côté serveur ou côté client. Ou vous pouvez simplement faire un usage intelligent de la <base> étiquette et changer la version actuelle en un seul endroit.

† Une façon de contourner cela est d'être agressif pour forcer le navigateur à recharger tout quand une nouvelle version est disponible. Mais pour le bien de laisser toutes les opérations en cours à complet, il peut encore être plus facile de prendre en charge au moins deux versions en parallèle: v-current et v-previous.

N'utilisez pas foo.css?version=1! Les navigateurs ne sont pas censés mettre en cache des URLs avec des variables GET. Selon http://www.thinkvitamin.com/features/webapps/serving-javascript-fast , bien que IE et Firefox ignorent ceci, Opera et Safari ne le font pas! Au lieu de cela, utiliser des foo.v1234.css, et utiliser des règles de réécriture à dépouiller le numéro de version.

pour ASP.NET 4.5 et plus vous pouvez utiliser script bundling .

la requête http://localhost/MvcBM_time/bundles/AllMyScripts?v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81 est pour le paquet AllMyScripts et contient une paire de chaîne de requête v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2n1pkvb81. La chaîne de requête v a un token de valeur qui est un identifiant unique utilisé pour la mise en cache. Aussi longtemps que le paquet ne change pas, le ASP.NET l'application demandera le paquet AllMyScripts en utilisant ce token. Si n'importe quel fichier dans le les changements de faisceau, le ASP.NET le cadre d'optimisation générera un nouveau token, garantissant que les requêtes de navigateur pour le paquet obtiendront le dernier paquet.

il y a d'autres avantages à empaqueter, y compris une performance accrue sur les charges de première page avec minification.

la directive RewriteRule a besoin d'une petite mise à jour pour les fichiers js ou css qui contiennent un point de notation versioning à la fin. Par exemple: json-1.3.js.

j'ai ajouté une classe de négation de points [^.] pour l'expression rationnelle .nombre. est ignoré.

RewriteRule ^(.*)\.[^.][\d]+\.(css|js)$ . [L]

post Intéressant. Après avoir lu toutes les réponses ici combinées avec le fait que je n'ai jamais eu de problèmes avec les chaînes de requête "bidon" (que je ne sais pas pourquoi tout le monde est si réticent à utiliser cela) je suppose que la solution (qui supprime le besoin de règles de réécriture apache comme dans la réponse acceptée) est de calculer un hachage court du contenu du fichier CSS (au lieu du datetime du fichier) comme un querystring bidon.

il en résulterait ce qui suit:

<link rel="stylesheet" href="/css/base.css?[hash-here]" type="text/css" />

bien sûr, les solutions datetime font aussi le travail dans le cas de l'édition D'un fichier CSS, mais je pense qu'il s'agit du contenu du fichier css et non du fichier datetime, alors pourquoi mélanger ces deux-là?

dans Laravel (PHP) Nous pouvons le faire de manière claire et élégante (en utilisant la modification de fichier timestamp):

<script src="{{ asset('/js/your.js?v='.filemtime('js/your.js')) }}"></script>

et similaires pour CSS

<link rel="stylesheet" href="{{asset('css/your.css?v='.filemtime('css/your.css'))}}">

merci à Kip pour sa solution parfaite!

Je l'ai étendu pour l'utiliser comme un Zend_view_Helper. Parce que mon client d'exécuter sa page sur un hôte virtuel j'ai aussi étendu.

J'espère que ça aidera quelqu'un d'autre aussi.

/**
 * Extend filepath with timestamp to force browser to
 * automatically refresh them if they are updated
 *
 * This is based on Kip's version, but now
 * also works on virtual hosts
 * @link /q/how-to-force-browser-to-reload-cached-css-js-files-40142/".$mtime.$1", $filePath);
        } else {

            // fetch directory of index.php file (file from all others are included)
            // and get only the directory
            $indexFilePath = dirname(current(get_included_files()));

            // check if file exist relativ to index file
            if (file_exists($indexFilePath . $filePath)) {

                // get timestamp based on this relativ path
                $mtime = filemtime($indexFilePath . $filePath);

                // write generated timestamp to path
                // but use old path not the relativ one
                return preg_replace('{\.([^./]+)$}', ".$mtime.$1", $filePath);
            } else {

                return $filePath;
            }
        }
    }

}

Santé et merci.

Voici une solution JavaScript pure

(function(){

    // Match this timestamp with the release of your code
    var lastVersioning = Date.UTC(2014, 11, 20, 2, 15, 10);

    var lastCacheDateTime = localStorage.getItem('lastCacheDatetime');

    if(lastCacheDateTime){
        if(lastVersioning > lastCacheDateTime){
            var reload = true;
        }
    }

    localStorage.setItem('lastCacheDatetime', Date.now());

    if(reload){
        location.reload(true);
    }

})();

ce qui précède cherchera la dernière fois que l'Utilisateur a visité votre site. Si la dernière visite a eu lieu avant la publication du nouveau code, il utilise location.reload(true) pour forcer le rafraîchissement de la page à partir du serveur.

j'ai habituellement ceci comme le tout premier script dans le <head> donc il est évalué avant toute autre charge de contenu. Si un rechargement doit se produit, c'est à peine perceptible pour l'utilisateur.

j'utilise le stockage local pour stocker l'horodatage de la dernière visite sur le navigateur, mais vous pouvez ajouter des cookies au mix si vous cherchez à prendre en charge les anciennes versions D'IE.

vous pouvez forcer une "session-wide caching" si vous ajoutez la session-id comme paramètre d'espionage du fichier js/ css:

<link rel="stylesheet" src="myStyles.css?ABCDEF12345sessionID" />
<script language="javascript" src="myCode.js?ABCDEF12345sessionID"></script>

si vous voulez une mise en cache à l'échelle de la version, vous pouvez ajouter du code pour imprimer la date du fichier ou similaire. Si vous utilisez Java, vous pouvez utiliser une étiquette personnalisée pour générer le lien d'une manière élégante.

<link rel="stylesheet" src="myStyles.css?20080922_1020" />
<script language="javascript" src="myCode.js?20080922_1120"></script>

dites que vous avez un fichier disponible à:

/styles/screen.css

vous pouvez soit ajouter un paramètre de requête avec des informations de version sur L'URI, par exemple:

/styles/screen.css?v=1234

ou vous pouvez préparer des informations de version, par exemple:

/v/1234/styles/screen.css

IMHO la deuxième méthode est meilleure pour les fichiers CSS car ils peuvent se référer à des images en utilisant des URLs relatives ce qui signifie que si vous spécifiez un background-image comme ainsi:

body {
    background-image: url('images/happy.gif');
}

son URL sera effectivement:

/v/1234/styles/images/happy.gif

cela signifie que si vous mettez à jour le numéro de version utilisé, le serveur traitera cela comme une nouvelle ressource et n'utilisera pas une version mise en cache. Si vous basez votre numéro de version sur Subversion/CVS/etc. révision cela signifie que les changements aux images référencées dans les fichiers CSS seront remarqués. Cela n'est pas garanti avec le premier schéma, i.e. L'URL images/happy.gif relative à /styles/screen.css?v=1235 est /styles/images/happy.gif qui ne contient pas toute information de version.

j'ai implémenté une solution de mise en cache en utilisant cette technique avec des servlets Java et je traite simplement les requêtes /v/* avec un servlet qui délègue à la ressource sous-jacente (i.e. /styles/screen.css ). En mode développement, j'ai défini des en-têtes de mise en cache qui demandent au client de toujours vérifier la fraîcheur de la ressource avec le serveur (ce qui donne typiquement un 304 si vous déléguez au DefaultServlet et au .css de Tomcat , .js , .js , etc. le fichier n'a pas changé) alors que dans le mode de déploiement j'ai placé des en-têtes qui disent "cache forever".

vous pouvez simplement ajouter un nombre aléatoire avec l'url CSS/JS comme

example.css?randomNo=Math.random()

pour ASP.NET je suppose que la solution suivante avec des options avancées (mode de débogage / libération, versions):

fichiers Js ou Css inclus de cette manière:

<script type="text/javascript" src="Scripts/exampleScript<%=Global.JsPostfix%>" />
<link rel="stylesheet" type="text/css" href="Css/exampleCss<%=Global.CssPostfix%>" />

Global.JsPostfix et Global.CssPostfix est calculé de la manière suivante dans Global.asax:

protected void Application_Start(object sender, EventArgs e)
{
    ...
    string jsVersion = ConfigurationManager.AppSettings["JsVersion"];
    bool updateEveryAppStart = Convert.ToBoolean(ConfigurationManager.AppSettings["UpdateJsEveryAppStart"]);
    int buildNumber = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision;
    JsPostfix = "";
#if !DEBUG
    JsPostfix += ".min";
#endif      
    JsPostfix += ".js?" + jsVersion + "_" + buildNumber;
    if (updateEveryAppStart)
    {
        Random rand = new Random();
        JsPosfix += "_" + rand.Next();
    }
    ...
}

N'ont pas trouvé l'approche DOM côté client créant dynamiquement l'élément de noeud de script (ou css):

<script>
    var node = document.createElement("script"); 
    node.type = "text/javascript";
    node.src = 'test.js?'+Math.floor(Math.random()*999999999);
    document.getElementsByTagName("head")[0].appendChild(node);
</script>

Google chrome a l'option Hard Reload ainsi que Empty Cache et Hard Reload .Vous pouvez cliquer et tenir le bouton Recharger (en mode inspection) pour en sélectionner un .

j'ai récemment résolu ce problème en utilisant Python. Ici le code (devrait être facile à adopter à d'autres langues):

def import_tag(pattern, name, **kw):
    if name[0] == "/":
        name = name[1:]
    # Additional HTML attributes
    attrs = ' '.join(['%s="%s"' % item for item in kw.items()])
    try:
        # Get the files modification time
        mtime = os.stat(os.path.join('/documentroot', name)).st_mtime
        include = "%s?%d" % (name, mtime)
        # this is the same as sprintf(pattern, attrs, include) in other
        # languages
        return pattern % (attrs, include)
    except:
        # In case of error return the include without the added query
        # parameter.
        return pattern % (attrs, name)

def script(name, **kw):
    return import_tag("""<script type="text/javascript" """ +\
        """ %s src="/%s"></script>""", name, **kw)

def stylesheet(name, **kw):
    return import_tag('<link rel="stylesheet" type="text/css" ' +\
        """%s href="/%s">', name, **kw) 

ce code ajoute essentiellement l'horodatage des fichiers comme paramètre de requête à L'URL. L'appel de la fonction suivante

script("/main.css")

résultera en

<link rel="stylesheet" type="text/css"  href="/main.css?1221842734">

l'avantage est bien sûr que vous ne devez jamais changer votre html à nouveau, en touchant le fichier CSS déclenchera automatiquement un l'invalidation du cache. Fonctionne très bien et la surcharge n'est pas perceptible.

pour mon développement, je trouve que chrome a une excellente solution.

https://developer.chrome.com/devtools/docs/tips-and-tricks#hard-reload

avec les outils de développement ouverts, il suffit de cliquer longtemps sur le bouton rafraîchir et de laisser aller une fois que vous passez sur "Empty Cache and Hard Reload".

C'est mon meilleur ami, et c'est un moyen super léger pour obtenir ce que vous voulez!

je suggère de mettre en œuvre le processus suivant:

• version vos fichiers css/js chaque fois que vous déployez, quelque chose comme: écran.1233.css (le nombre peut être votre révision SVN si vous utilisez un système de contrôle de version)

• rapetisser à optimiser le temps de chargement

j'ai mis un hachage MD5 du contenu du fichier dans son URL. De cette façon, je peux définir une date d'expiration très longue, et ne pas avoir à s'inquiéter des utilisateurs ayant de vieux JS ou CSS.

j'ai aussi calculé cela une fois par fichier à l'exécution (ou sur les changements de système de fichier) donc il n'y a rien de drôle à faire au moment de la conception ou pendant le processus de construction.

si vous utilisez ASP.NET MVC alors vous pouvez vérifier le code dans mon autre réponse ici .

Désolé d'avoir ramené un fil mort.

@ TomA est juste.

à l'Aide "querystring" méthode ne sera pas mis en cache, tel que cité par Steve Souders ci-dessous:

...ce Squid, un proxy populaire, ne cache pas les ressources avec un querystring.

@ TomA suggestion d'utiliser le style.TIMESTAMP.css est bien, mais MD5 serait beaucoup mieux car seulement lorsque le contenu a été réellement changé, le MD5 change aussi.

pour un environnement Servlet Java, vous pouvez consulter la bibliothèque Jawr . La page de fonctionnalités explique comment il gère la mise en cache:

Jawr fera de son mieux pour forcer vos clients à mettre en cache les ressources. Si un navigateur demande si un fichier a été modifié, un en-tête 304 (non modifié) est renvoyé sans contenu. D'un autre côté, avec Jawr vous serez sûr à 100% que les nouvelles versions de vos paquets sont téléchargées par tous les clients. Chaque URL à votre les ressources comprendront un préfixe généré automatiquement et basé sur le contenu qui change automatiquement chaque fois qu'une resurce est mise à jour. Une fois que vous aurez déployé une nouvelle version, L'URL du paquet changera également, de sorte qu'il sera impossible qu'un client utilise une ancienne version mise en cache.

la bibliothèque fait aussi minification js/css, mais vous pouvez l'éteindre si vous ne le voulez pas.

si vous utilisez un navigateur moderne, vous pouvez utiliser un fichier manifest pour indiquer aux navigateurs quels fichiers doivent être mis à jour. Cela ne nécessite aucun en-tête, aucune version dans les urls, etc...

Pour plus de détails, voir: Voir: https://developer.mozilla.org/nl/docs/Web/HTML/Applicatie_cache_gebruiken#Introduction

j'ajoute cette réponse comme une trame argentée http://www.silverstripe.org réponse spécifique que je cherchais et que je n'ai jamais trouvée mais que j'ai trouvé en lisant: http://api.silverstripe.org/3.0/source-class-SS_Datetime.html#98-110

espérons que cela aidera quelqu'un en utilisant un modèle SilverStripe et en essayant de forcer recharger une image mise en cache sur chaque page visite / rafraîchissement. Dans mon cas, c'est une animation gif qui seuls les jeux une fois et par conséquent ne rejouent pas après avoir été mis en cache. Dans mon modèle j'ai simplement ajouté:

?$Now.Format(dmYHis)

à la fin du chemin du fichier pour créer un horodatage unique et forcer le navigateur à le traiter comme un nouveau fichier.

il semble que toutes les réponses ici suggèrent une sorte de versioning dans le schéma de nommage, qui a ses inconvénients.

les navigateurs doivent être bien conscients de ce qu'il faut cacher et de ce qu'il ne faut pas cacher en lisant la réponse des serveurs Web, en particulier les en - têtes http-pendant combien de temps cette ressource est-elle valide ? cette ressource a-t-elle été mise à jour depuis que je l'ai récupérée ? etcetera.

si les choses sont configurées "correctement", il suffit de mettre à jour les fichiers de votre application devrait (à un moment donné) rafraîchir les caches du navigateur. Vous pouvez par exemple configurer votre serveur web pour dire au navigateur de ne jamais mettre en cache des fichiers (ce qui est une mauvaise idée).

Une explication plus approfondie de la façon dont cela fonctionne est ici https://www.mnot.net/cache_docs/#WORK