Intérêt des sprites?

[Sephi-Chan]

Il gagne en rapidité à cause de la règle des 2 requêtes http en parallèle maximum, si tu as 10 icones, il en téléchargera que deux et devra attendre qu'une se finisse pour lancer les autres. Le sprite résous pour partie ce problème.

Cela fait bien longtemps que les navigateurs ne se limitent pas à 2 requêtes HTTP en parallèle. La moyenne semble plutôt être à 6 requêtes parallèles par domaine avec une limite globale (allant de 10 à 60). On retrouve ici l'intérêt d'avoir plusieurs noms de domaines vers le même site, pour les assets.

Le rendu progressif n'a aucun intérêt de mon point de vue : le jeu/site est afficher ou il ne l'ai pas (je me fiche de tout ce qui est intermédiaire, ce n'est pas un état satisfaisant du système).

Pourtant, un téléchargement progressif du contenu utile est intéressant et donne une meilleure expérience à l'utilisateur : il voit l'interface apparaître rapidement car le fichier est vite téléchargé. La majorité du sprite n'est pas utile à un nouveau visiteur qui arrive sur la page, car il contient beaucoup de choses utiles seulement à ceux qui ont lancé le jeu à proprement parler. C'est pourquoi il est parfois plus stratégique de créer plusieurs sprites : un pour l'interface des pages hors-jeu, un pour le jeu en lui-même, etc. Ça évite en plus d'invalider tout le sprite pour certains changement qui seraient autrement cantonnés à leur sprite.

Avec HTTP 2 (et déjà SPDY), les sprites appartiendront au passé, tout comme la concaténation.
Si aujourd'hui tu n'utilises pas de générateurs, ce n'est même pas la peine de s'y mettre.

Tu peux développer? ça m’intéresse

HTTP2 (déjà disponible sur certains navigateurs) supporte plein de fonctionnalités qui rendent la majorité des pratiques d'optimisation caduques. Parmi ces fonctionnalités : la compression des headers (qui réduit leur volume de 85%), le multiplexage de plusieurs requêtes dans une seule connexion, le push d'assets depuis le serveur (ça donne donc un contrôle sur le cache du navigateur), etc.

Le gros avantage de tout ça, c'est que ça devient bien plus simple et intelligent et qu'on peut se reposer sur le navigateur sans trop se poser de questions. Ça nous évite d'invalider 500 Ko de Javascript juste pour un peu de code qui change (c'est aussi pour ça que je séparais le code Javascript des frameworks et le code de mon application dans 2 fichiers concaténés et minifiés séparés).

Les sprites PNG restent intéressants pour regrouper de petites images où la somme des poids est plus importante que le sprite qui les rassemble. Mais à nouveau, ça pose la question du regroupement stratégique dans des sprites. Je pense qu'il est plus pertinent de lâcher du leste et de laisser le navigateur récupérer ce dont il a besoin : il le sait mieux que nous.

[Xenos]

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.

[Argorate]

Il y a un guide de passage de http 1 à 2 ?

j'ai lu notamment qu'on pouvait envoyer le css avant que le client ne le demande, en multiplexage. Comment ça se passe concrètement pour faire ça?

Pour les sprites, n'en n'utilise pas si c'est ce que tu veux^^

[L'Omniscient]

J'ai un peu regardé ce qu'était un sprite, mais je ne comprends pas bien. Ce sont des images en opacité pour faire un effet de profondeur ?

[Sephi-Chan]

Vraiment un peu, alors. :p

Les sprites CSS sont des images que l'on rassemble sur une seule (pour éviter de multiplier les requêtes HTTP), et qu'on affiche en background-image de blocs grâce à la propriétés background-position.

Tu peux jetter un œil à l'article de Alsacréations pour en savoir plus.