Optimiser l’affichage d’un jeu web en HTML5 – un petit projet in

Salut la communauté !

Je bosse actuellement sur un petit projet web en HTML5/CSS/JS – un mini-jeu de logique inspiré du style Mahjong Shanghai kostenlos (rien de commercial, juste pour m’amuser et tester mes compétences).
J’aimerais optimiser le rendu graphique, surtout sur mobile, car j’ai remarqué que les animations CSS et le redimensionnement des tuiles deviennent un peu lourds quand le canvas est trop grand.

Ma question : vous auriez des astuces ou bonnes pratiques pour améliorer les performances d’un jeu basé sur des éléments visuels nombreux (images, tuiles, etc.) sans sacrifier la fluidité ?
Je pensais peut-être passer par requestAnimationFrame() ou jouer sur le will-change, mais je ne suis pas sûr de la meilleure approche.

Merci d’avance pour vos idées !
Et si certains d’entre vous ont déjà fait des mini-jeux type puzzle ou Mahjong-like, je suis preneur de retours d’expérience
Modifié par Emerald1 (24 Oct 2025 - 05:24)

Bonjour,

Mon expérience en la matière est un jeu de puzzle, donc assez proche du jeu de "Shanghai".

A priori, pas besoin de requestAnimationFrame() pour quelques centaines de tuiles (avec les machines de moins de 10 ans, ça commence par exemple vraiment à ramer quand on déplace genre un millier d'images dans la page). Et je ne vois pas trop d'ailleurs ce que tu pourrais gagner avec ça dans ton cas.

will-change est à utiliser vraiment en tout dernier recours. Normalement, tu ne devrais pas en avoir besoin (ou uniquement pour corriger des bugs sur certains vieux navigateurs, ce qui arrive par exemple avec de vieux safaris quand on a beaucoup d'images SVG). Mais même en bricolant avec will-change, c'est assez difficile en fait de gagner vraiment en fluidité par rapport à ce que les navigateurs sont capables de faire de leur côté.

Le plus important, c'est de bien optimiser le code (on ne fait que le nécessaire), car on a vite fait de faire des boucles plus ou moins inutiles, ou du traitement d'images à la volée alors qu'on aurait pu faire autrement, en particulier au démarrage. Ce n'est qu'ensuite, si ça ne suffit toujours pas, qu'on peut imaginer des combines à base de fonctions js ou de css plus ou moins ésotériques que tu citais. Mais je pense que quand on commence à avoir besoin de ces combines, c'est qu'on en train de faire n'importe quoi.

Il faut aussi faire attention à tous les redimensionnements divers et variés qu'on peut être amené à mettre en place pour s'adapter à la taille de l'écran. Par exemple, il faut éviter d'utiliser des wagons de <div> inclus les uns dans les autres, ayant des tailles nécessitant des redimensionnements, genre un <div> qui est réduit d'un facteur 2 inclus dans un <div> qui est étendu d'un facteur 3. Idéalement d'ailleurs, il faudrait ne laisser dans le html que les balises nécessaires, c'est à dire zéro <div>.

Parfois aussi, quand toute la surface du jeu n'est pas affichée à l'écran, on peut avoir intérêt à provisoirement supprimer du DOM les éléments graphiques non visibles. Pour un jeu de "Shanghai", c'est peu probable que ce soit intéressant de mettre ça en place.

Aussi, je conseille d'utiliser du svg autant que possible (ce n'est pas forcément plus rapide, mais c'est beaucoup plus beau car ça ne pixélise pas).

Certains pourraient te conseiller d'utiliser des workers (des procédures qui se lancent en parallèle et qui utilisent le fait que les ordinateurs sont maintenant multi-coeurs, donc capables d'exécuter ces procédures en parallèle). Mais lorsqu'on manipule des images, le résultat est souvent décevant avec les workers (selon mon expérience), car ce qu'on gagne en parallélisant les calculs, on a vite fait de le reperdre rien qu'avec le temps que ça met à transmettre les données aux workers (ceux-ci ne pouvant pas utiliser le DOM directement). Et les données concernant les images, c'est tout de suite gros. C'est à tester néanmoins dans ton cas, car on ne peut pas dire a priori si ça va gagner ou perdre du temps !

Amicalement,
Modifié par parsimonhi (24 Oct 2025 - 09:28)