À quoi ça sert?
Il existe déjà une technique bien établie appelée mise en cache côté client. Qu'est-ce que le stockage local HTML5 apporte dans ce cas quel cache est manquant?
Vous pouvez avoir une sorte d'application étrange qui doit charger dynamiquement des morceaux de code JavaScript afin que vous ne puissiez pas utiliser efficacement le cache, mais c'est un cas extrêmement rare.
Soyez également conscient d'une autre chose. Les navigateurs ont des politiques spécifiques pour le cache, et la plupart des navigateurs sont assez bons pour bien gérer le cache (supprimer uniquement le contenu plus ancien, etc.). En implémentant votre cache fait maison, vous empêchez les navigateurs de le gérer correctement. Non seulement elle peut être critiquée seule, mais elle vous blessera aussi tôt ou tard. Exemple: lorsque les utilisateurs d'une application Web signalent des bogues, vous répondez souvent en leur demandant de vider leur cache. Je ne sais pas ce que vous demanderez dans votre cas, car l'effacement du cache ne résoudra jamais les problèmes avec votre application Web.
En réponse à votre premier montage (votre deuxième montage étant hors sujet):
Je connais le cache du navigateur, il y aura encore une vérification de l'accès aux en-têtes
Vous semblez manquer de compréhension de la mise en cache du navigateur. C'est pourquoi il est essentiel de comprendre comment cela fonctionne avant de commencer à mettre en œuvre votre propre mécanisme de mise en cache fait maison . Réinventez votre propre roue uniquement lorsque vous comprenez suffisamment les roues existantes et que vous avez une bonne raison de ne pas les utiliser. Voir point 1 de ma réponse à la question "Réinventer la roue et ne pas la regretter" .
Lorsque vous fournissez des données via HTTP, vous pouvez spécifier quelques en-têtes liés au cache:
Last-Modified
précise quand le contenu a été modifié,
Expires
spécifie quand le navigateur doit demander au serveur si le contenu a changé .
Ces deux en-têtes permettent au navigateur de:
- Évitez de télécharger le contenu encore et encore. Si
Last-Modified
est défini sur le mois dernier et que le contenu a déjà été téléchargé aujourd'hui quelques heures auparavant, il n'est pas nécessaire de le télécharger à nouveau.
- Évitez d'interroger la date de dernière modification du fichier. Si
Expires
d'une entité de cache est le 5 mai e 2014, vous n'avez pas d'émettre une requête GET ni en 2011, ni en 2012 ou 2013, puisque vous savez que le cache est mise à jour.
Le second est essentiel pour les CDN. Lorsque Google diffuse JQuery à un visiteur de Stack Overflow ou cdn.sstatic.net
diffuse des images ou des feuilles de style utilisées par Stack Overflow, il ne souhaite pas que les navigateurs recherchent une nouvelle version à chaque fois. Au lieu de cela, ils servent ces fichiers une fois, définissent la date d'expiration sur quelque chose d'assez longtemps, et c'est tout.
Voici par exemple une capture d'écran de ce qui se passe lorsque j'arrive sur la page d'accueil de Stack Overflow:
Il y a 15 fichiers à servir. Mais où sont toutes ces 304 Not Modified
réponses? Vous n'avez que trois demandes de contenu qui ont changé. Pour tout le reste, le navigateur utilise la version mise en cache sans faire de demande à aucun serveur .
Pour conclure, vous devez vraiment réfléchir à deux fois avant d'implémenter votre propre mécanisme de cache, et surtout trouver un bon scénario où cela peut être utile . Comme je l' ai dit au début de ma réponse, je peux trouver une seule: où vous servez des morceaux de JavaScript afin de les utiliser à travers, OMG, eval()
. Mais dans ce cas, je suis presque sûr qu'il existe de meilleures approches qui sont soit:
- Plus efficace en utilisant les techniques de cache standard, ou
- Plus facile à entretenir.