Group items tagged

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%.

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.

Pas pris encore le temps de tester ce nouvel outil mais j'aime bien la philosophie, je suis preneur de vos retours.

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.

Deux règles principales pour la performance des sites web sont de réduire le nombre de requêtes HTTP et de limiter la taille des données qu'on télécharge. Malheureusement ces deux règles entre parfois en conflit. Si je fais un gros fichier unique pour toutes mes CSS, je vais inclure des règles qui seront inutiles pour la page courante, et qui augmenteront inutilement la taille totale à télécharger.

Probablement déjà bookmarké.

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

La directive Cache-Control est une vrai mine d'or pour la gestion du cache, au risque même de faire un peu fourre-tout. Aujourd'hui je m'intéresse surtout aux notions de document public et de document privé.

"Les 3 caches ? C'est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront."

"Les 3 caches ? C'est comme les 3 coquillages : on peut faire sans, mais les gens du futur se moqueront."