Je préviens tout de suite, c'est pas pour cracher sur les devs : c'est du code amateur, ça se sent, je passe au-dessus, et je ne connais pas non plus toutes les contraintes techniques derrière. Le but, c'est d'apporter un point de vue technique.
Bref, je tombe donc sur un appel au fichier http://www.jdr-delain.net/jeu/style_vue.php et j'ai un tas de remarques à faire là dessus.
- un php au lieu d'un css, donc il nécessite un traitement côté serveur potentiellement inutile
- un "no-cache" et une date d'expiration dans le passé dans les headers, donc vraiment aucun cache navigateur, et des appels inutiles à ce fichier
Ensuite, je note que, nécessairement, le format implique que chaque appel doit tout recalculer en fonction du personnage que l'on a sélectionné (et pas que de l'étage choisi)
Je veux bien croire qu'il y a une nécessité d'avoir une marge, mais, tout de même : quel est l'intérêt de générer autant de ligne de css pour rien ?
De plus, il y a des définitions redondantes : toutes les td.v1 à td.v999 sont exactement les mêmes que td.1 à td.999.
Exemple :
Ensuite, en regardant dans la vue d'un autre personnage (qui n'est pas au même étage), je me rends compte que des parties peuvent être mutualisées, dont les décors et les lieux.td.v398{
background:url('http://images.jdr-delain.net/f_2_398.png');
width:28px;height:28px;border : 0px;}
...
td.398{
background:url('http://images.jdr-delain.net/f_2_398.png');
width:28px;height:28px;border : 0px;}
Pour terminer, spéciale dédicace à la personne qui a mis un script google analytics à la fin du fichier, qui ne sert strictement à rien.
Aux problèmes des solutions.
Tout d'abords, extraire tout ce qui peut être mutualisé dans un fichier statique à part (comme "vue_globale.css"), avec les informations sur les décors et les lieux.
Ensuite, dédoublonner les styles pour les cases (td.vXX et td.XX) :
Ce qui représente une économie considérable (par rapport au fichier) : s'il faut une boucle for pour chaque série, alors cela n'en fait plus qu'une seule à la place de deux, et côté client, analyser 3000 lignes à la place de 6000, c'est toujours mieux (même si c'est du chipotage).td.v398, td.398{
background:url('http://images.jdr-delain.net/f_2_398.png');
width:28px;height:28px;border : 0px;}
Voire supprimer complètement l'une des deux versions et n'en garder qu'une.
Toujours dans l'optique d'éviter des lignes et informations inutiles, il serait bon de faire un écrémage sur les styles des cases : sur les styles utiles (avec des images, donc, et pas des fichiers inexistants), je n'en ai compté qu'une 20aine d'utile à chaque fois. Cela change peut-être en fonction du niveau, mais je doute que, pour une map, il faille utiliser plus de 150 styles de cases différentes.
Le mieux serait de créer un fichier css séparé pour chaque niveau du jeu : ils ne donnent strictement aucune information particulière sur le jeu (ou alors c'est de la paranoïa mal placée), et des fichiers css peuvent être mis en cache. Le mieux, ce serait carrément de les mettre sur un autre sous-domaine (comme pour les images) pour éviter de transmettre d'inutiles informations de cookies et autre.
De plus, en cas de mise à jour d'un niveau, il n'y a qu'un seul fichier à modifier, pas de bases de données à modifier, etc. etc.
Il y a un tas d'autres trucs à traiter sur ce fichier je pense, mais c'est déjà un bon point.
Bref, je pense que la balance entre fonctionnalité et performance est beaucoup trop en défaveur de performance.
Et puis ça me permettrait de perdre moins de temps dans mes recherches d'images.
