Que pensez-vous du fait de stocker des images en LocalStorage (js) ?

[Argorate]

Bonjour,

je viens de découvrir une technique intéressante, plutôt que d'utiliser le cache des navigateurs qui peut etre vider et qui est difficilement contrôlable, le fait de stocker des images directement en localstorage.
Ça semble très rapide, puisque ça évite les requêtes http qui demande "es-ce que mon fichier est à jour" même si on l'a en cache. Et puis tout a fait controller.

Qu'en pensez-vous? Bonne mauvaise pratique? Dans quelle mesure?


D'ailleurs, quelle taille maximale est alloué au localstorage d'un domaine?

[Prélude]

Tu auras quelques réponses (voir toutes) sur cet article : http://www.alsacreations.com/article/lir...orage.html
Cet article date de 2012.
Il est bon de prendre en compte les mobiles qui n'ont pas forcément une mémoire quasi infinie (La place étant limité à 5Mo par domaine) par rapport aux desktop.

[niahoo]

Qu'est-ce que tu as besoin de contrôler ?

[Argorate]

Dans mon cadre, les smartphone ne sont pas un outils pour jouer.
Sinon je me demande si y a moyen de détecter qu'on a plus de place en localstorage?

Sinon pour le contrôle, les gens peuvent vider le cache par exemple et donc refaire DL beaucoup d'image pour rien. Sans compter l'économie de requête http comme je le disais.

[Xenos]

"Difficilement contrôlable", par qui? Par le webmaster? Oui, c'est normal.
Le navigateur est toujours le mieux placer pour gérer les choses., parce qu'il n'est pas dans dans le scope du site (le webmaster n'a pas à s'occuper de la maintenance ou de la mise à jour du navigateur), qu'il implémente les nouveaux standards une et une seule fois pour tous les sites (code once), et qu'il sera bien plus apte à prendre les bonnes décisions sur la base du contexte de navigation (est-ce un appareil mobile? tactile? à petit écran? à faible mémoire? etc) que le site et son webmaster.

Pour moi, c'est donc clairement une mauvaise idée de faire ainsi, car:
• Tu vas te retapper du code qui est déjà dans les navigateurs
• Tu vas foutre le caillon dans tes pages en incluant des javascript de-ci de-là qu'il te faudra ensuite réutiliser correctement (pratiquement, tu vas devoir bannir les tag <img/> au profit de <div/> que tu gères toi-même, niveau évolutivité, c'est mort)
• Tu ne vas rien gagner par rapport à ce que la norme de cache HTTP propose (une date d'expiration sur tes images et hop, le serveur ne sera même pas contacté s'il n'y en a pas besoin)
• Tu vas rater certains concepts comme les URIs (si ton image change, l'URI change, ça peut être sa query string ou autre chose)
• Tu vas avoir des effets colatéraux monstrueux (tu gères le caches d'image, mais le cache de page? Le mode offline du navigateur?)
• Tu vas dépasser la capa maximale du localStorage (environ 10Mo, et alsacreation dit 5Mo)
• Tes images ne seront pas cachées par les proxies (je me demande même si tu ne vas pas sur-solliciter ton serveur en faisant ça, en passant à coté des CDN par exemple).


Donc, heu... non. C'est pas une bonne idée. Si ton soucis est "j'ai changé ma ressource (image, page web, n'importe quoi) donc si elle est en cache les joueurs ne vont pas la voir", change l'URI (puisque la ressource a changée). Soit une URI est dynamique et donc non cachée (ex: page dynamique PHP ou autre), soit l'URI est statique et donc cachée (et on la change quand la ressource change).

Je finis en ajoutant que respecter une norme (comme le cache http) n'est pas là pour casser les pruneaux, mais pour harmoniser le travail des développeurs sur la planète. N'essaie pas de by-passer une norme quand tu n'arrives pas à en faire ce que tu veux: c'est toujours une mauvaise idée (surtout sur le long terme).

[Edité parce que le chocolat, ça calme ]

[Sephi-Chan]

Je pense que c'est une mauvaise idée car ça nécessite du travail, du code et donc de la complexité pour un bénéfice nul. Les navigateurs et les serveurs font très bien leur boulot, encore plus quand il s'agit de servir des ressources statiques : un outil pour renommer les fichiers avec le MD5 de leur contenu est bien suffisant.