Citation :Le changement des sprites en prod n'arrive presque jamais, par contre des nouveaux visiteurs qui télécharge l'ensemble de ton design est un événement avec un très grosse proba
Pas d'accord: le cas "le joueur est nouveau" ne va arriver qu'une et une seule fois (je parle bien du joueur, pas du visiteur, cf la remarque de Sephi), alors que le cas "le joueur assiste à plusieurs mises à jour" va arriver plusieurs fois (sinon, cela veut dire que le jeu n'est pas mis à jour, ou que les joueurs s'en vont trop vite pour y assister).
Je peux te dire que la mise à jour des sprites est courante dans un site véritablement "actif": au taff, on a des demandes tous les jours pour des features, bugfix, etc, et la sprite a déjà subit 4 mises à jour en mois de 6 mois. Après, pour un jeu amateur, la dynamique est moins importante, mais du coup si le site n'est pas dynamique (donc, a peu de joueurs finalement), est-ce bien utile de vouloir sous-exploiter la bande passante en faisant une "optimisation" de ce style?
Pour HTTP2, j'ai vu qu'il était supporté dans Apache, et dans tous les navigateurs (oui, même IE, bien que ce ne soit que pour Windows 10+). C'est une bonne nouvelle
PS: Je rejoins Sephi sur le rendu progressif, d'autant que si la connexion est lente (seul cas où la sprite se justifierait), le rendu progressif devient essentiel (ce qui invalide finalement l'utilisation de cette sprite!)
PSS: si le cache sature, la sprite peut devenir anti-optimisante. Supposons 2 sites faisant chacun des sprites, et un cache ne pouvant contenir les 2 sprites en même temps. Alors la sprite entière sera retéléchargée à chaque visite de l'un ou de l'autre des deux sites. Avec 1 fichier par ressource, à moins d'avoir toutes les images sur la même page, le trafic se réduirait. C'est un cas pas si atypique que cela si on considère les mobiles, ou les éventuels cache de CDN/Proxies.