My previous blog post, Cache them if you can, suggests that current cache sizes are too small - especially on mobile. Given this concern about cache size a relevant question is: If a response is compressed, does the browser save it compressed or uncompressed? Compression typically reduces responses by 70%.
l'auteur suggère de gérer son cache en javascript pour la partie intelligente = ne recharger la page que lorsque quelque chose a changé. Ca fait un bout de temps que j'y pense, mais j'hésite à mettre ce genre de chose en prod
Je parle de détails et de ce que je rencontre dans mes lectures, et j'en oublie le principal. alors voilà, si vous ne devez retenir qu'une chose c'est d'utiliser des dates d'expiration explicites sur vos contenus.
Il s'agit d'informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n'a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d'autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément.
Safari a de sérieuses limitations sur le cache. Yahoo! avait déjà débusqué les limites de la version iphone : les fichiers ne doivent pas dépasser 25 ko une fois décompressés et le total doit être strictement inférieur à 500 ko. Ces limitations semblent raisonnables pour un téléphone mais ce téléphone navigue souvent sur des sites classiques, avec une bande passante très réduite.
Le cache HTTP permet aux visiteurs de ne pas re-télécharger les pages ou les éléments de pages qui l'ont déjà été. C'est un des meilleurs mécanismes pour accélérer l'accès du navigateur au contenu mais il est mis en échec par de nombreux cas.
Librairie de chargement asynchrone de fichiers JavaScript. Elle est légère et rapide, facile à prendre en main et volontairement succinte.
À tester et comparer face à d'autres solutions plus complètes, telles que RequireJS, head.js, $scriptjs ou encore LabJS.
via @DirtyF
y'a bien un spécialiste qui va nous pondre un comparatif un de ces quatres, ça commence à faire beaucoup mais c'est bon signe pour la performance, à adapter toujours en fonction du contexte de toute façon.
moi en tout cas ça me parle.
à faire attention : comme pour d'autres loaders, il faut que le cache soit bien configuré car il fait une requête pour mettre en cache, et une 2nde requête pour exécuter, normalement depuis le cache. Si le cache n'est pas bien configuré (que veux dire "bien" : au moins 10 minutes d'expiration ?), la ressource sera téléchargée deux fois.