web-dev-qa-db-fra.com

est-il réaliste d'utiliser le stockage local HTML5 pour stocker CSS et JavaScript

L'idée est d'utiliser le stockage local HTML5 pour stocker les CSS et JavaScript fréquemment consultés.

Par exemple (pseudo-code):

 var load_from_cdn = true; 
 if (détecter le stockage local) 
 {
 if (cache de css, js trouvé) 
 {
 charger le cache de stockage local 
 load_from_cdn = false; 
} 
} 
 if (load_from_cdn) 
 {
 document. écrire ('<script> ...'); 
}

Est-ce possible ou réaliste?

Je connais le cache du navigateur, il y aura encore une vérification de l'accès aux en-têtes,
Je suppose qu'aucun accès HTTP n'est meilleur (dans ma pensée )

PS: Il semble que le stockage local ne supporte que paire clé-valeur, quelqu'un peut-il le prouver?
(mieux avec quelques exemples)

html5optimization
23
ajreal

Il est absolument correct d'utiliser le stockage local pour stocker JS et CSS. Cependant, le stockage local a une limitation de 5 Mo par domaine. Vous devrez peut-être reconsidérer cette stratégie.

Pour le Web de bureau, vous pouvez utiliser le cache du navigateur par défaut pour faire l'affaire. Définissez simplement la réponse HTTP JS & CSS pour qu'elle puisse être mise en cache. C'est simple et facile.

Pour le Web mobile, la latence est élevée. Il est donc essentiel de réduire les demandes HTTP. Donc, avoir JS & CSS dans les URL externes est optimal. Il serait préférable d'avoir JS & CSS en ligne. Cela réduit les requêtes HTTP, mais gonfle le contenu HTML. Alors quoi? Comme vous l'avez dit, utilisez le stockage local!

Lorsqu'un navigateur visite le site pour la première fois, JS & CSS sont mis en ligne. Le JS a également deux autres tâches: 1) Stocker JS et CSS dans le stockage local; 2) Définissez un cookie pour signaler que JS et CSS sont dans le stockage local.

Lorsque le navigateur accède au site pour la deuxième fois, le serveur a obtenu le cookie et sait que le navigateur a déjà associé JS & CSS. Ainsi, le rendu HTML a JS en ligne pour lire JS et CSS à partir du stockage local et l'insérer dans l'arborescence DOM.

C'est l'idée de base de la création de la version mobile de bing.com. Vous devrez peut-être prendre en compte le contrôle de version JS et CSS lors de son implémentation en production.

Merci

11
Morgan Cheng

Le navigateur ne le fait-il pas déjà pour vous, et probablement mieux?

33
Bryan Boettcher

À 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 ce qui manque de mise en cache?

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 il peut être critiqué seul, mais cela nuira également vous 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 d'abord, avant de commencer à implémenter 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 le 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 Spécifie 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 maie, 2014, vous n'avez à émettre aucune demande GET ni en 2011, ni en 2012 ou 2013, car vous savez que le cache est à 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, fixent la date d'expiration à 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:

A screenshot of Stack Overflow timeline in Chrome shows 15 files, 3 being requested, 12 being served from cache directly with no requests to remote servers

Il y a 15 fichiers à servir. Mais où sont toutes ces réponses 304 Not Modified? 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 ne peux en trouver qu'un: où vous servez des morceaux de JavaScript pour les utiliser via 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.
23
Arseni Mourzenko

La mise en cache locale côté client devrait être bien plus optimisée que l'utilisation du stockage local HTML5. Assurez-vous simplement que votre javascript et CSS sont dans des fichiers externes et que votre page devrait se charger beaucoup plus rapidement via le cache du navigateur que d'essayer de les extraire du stockage local et de les exécuter vous-même.

En outre, le navigateur peut commencer à charger des ressources externes au fur et à mesure que la page commence à se charger, avant de pouvoir réellement commencer à exécuter javascript dans cette page pour ensuite obtenir vos ressources à partir du stockage local HTML5.

De plus, vous avez quand même besoin de code dans la page pour charger à partir du stockage local HTML5, alors il suffit de mettre tous vos JS dans un fichier JS externe et cachable.

7
jfriend00

Au lieu de réinventer la roue, utilisez simplement la fonctionnalité hors ligne HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

5
ZippyV

Vous obtiendrez de bien meilleures performances en utilisant un réseau de diffusion de contenu (CDN) comme bibliothèque de codes de Google . Prévu de manière réfléchie, la majorité de vos fichiers JS et CSS devraient se trouver dans le cache de chaque visiteur avant de toucher votre site pour la première fois. Réduisez le reste.

Vous pouvez toujours comparer la mise en cache du navigateur à votre solution HTML5 roulée à la main. Mais je parie que la mise en cache native va battre le pantalon.

2
cczona

Utiliser localStorage est rapide (euh)! Mon test a montré

  • Chargement de jQuery depuis CDN: Chrome 268ms , FireFox: 200ms
  • Chargement de jQuery depuis localStorage: Chrome 47 ms , FireFox 14 ms

Je suppose que l'enregistrement de la requête HTTP apporte déjà un gros avantage de vitesse. Tout le monde ici semble être convaincu du contraire, alors veuillez me prouver le contraire.

Si vous voulez tester mes résultats, j'ai créé une petite bibliothèque qui met en cache les scripts dans localStorage. Découvrez-le sur Github https://github.com/webpgr/cached-webpgr.js ou copiez-le simplement à partir de l'exemple ci-dessous.

La bibliothèque complète:

function _cacheScript(c,d,e){var a=new XMLHttpRequest;a.onreadystatechange=function(){4==a.readyState&&(200==a.status?localStorage.setItem(c,JSON.stringify({content:a.responseText,version:d})):console.warn("error loading "+e))};a.open("GET",e,!0);a.send()}function _loadScript(c,d,e,a){var b=document.createElement("script");b.readyState?b.onreadystatechange=function(){if("loaded"==b.readyState||"complete"==b.readyState)b.onreadystatechange=null,_cacheScript(d,e,c),a&&a()}:b.onload=function(){_cacheScript(d,e,c);a&&a()};b.setAttribute("src",c);document.getElementsByTagName("head")[0].appendChild(b)}function _injectScript(c,d,e,a){var b=document.createElement("script");b.type="text/javascript";c=JSON.parse(c);var f=document.createTextNode(c.content);b.appendChild(f);document.getElementsByTagName("head")[0].appendChild(b);c.version!=e&&localStorage.removeItem(d);a&&a()}function requireScript(c,d,e,a){var b=localStorage.getItem(c);null==b?_loadScript(e,c,d,a):_injectScript(b,c,d,a)};

Appeler la bibliothèque

requireScript('jquery', '1.11.2', 'http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js', function(){
    requireScript('examplejs', '0.0.3', 'example.js');
});
2
select