Nous avons vu la compression, la minification, les images, le cache, voici une check-list qui reprend un peu tout ça. Il en existe déjà, mais j’aimerais en faire une qui tienne compte de notre domaine bien spécifique : les jeux web amateurs.
Et puis, comme je n’aime pas être sectaire, je parlerais des autres cas. Voilà, tout le monde sera content !

Enfin, je parlerais de ces fameux 20% qui demandent 80% de travail : il y a encore beaucoup de choses à faire pour optimiser un site et on est loin d’avoir tout dit !

Spécificités liées aux jeux web amateurs

Déjà, le simple fait d’annoncer le terme « amateur » nous limite un peu dans les possibilités. Je ne crois pas que les amateurs soient réellement près à investir des sommes importantes dans un CDN de qualité, surtout si derrière le serveur n’a pas la puissance suffisante pour supporter des milliers de joueurs simultanés.

Bien souvent (je dirais 90% des cas), les jeux web amateurs sont hébergés sur des serveurs mutualisés. Il sera donc difficile de faire des modifications liées au serveur.

Enfin, ce n’est pas parce qu’un jeu attire 10 visiteurs par jour qu’il ne faut pas les chouchouter ! Un joueur content sera un joueur qui restera et vos joueurs sont votre meilleure publicité.

Voici donc ma check-list, par ordre d’importance :

  1. compression GZip
  2. gestion du cache
  3. les fichiers JavaScript en bas
  4. regroupement des fichiers JS / CSS
  5. minification JS / CSS
  6. optimisation des images
  7. pas de script inline (JavaScript ou CSS)
  8. sprite
  9. minification HTML
  10. indiquez la taille des images et ne les redimensionnez pas en HTML

Cette liste est à adaptée en fonction de vos spécificités. Mais elle représente bien les besoins pour un site amateur hébergé en mutualisé.

Pour ceux qui souhaitent aller plus loin, vous pouvez rajouter :

  • domain sharding
  • CDN

Et pour tout le monde

Je pense sincèrement qu’il n’y a pas de check-list parfaite adaptée à tous les sites. Je suis persuadé que chaque site est un cas particulier et qu’il faut adapter ses connaissances en fonction de différents critères.
J’irais même plus loin en disant que la check-list que je viens de proposer est le strict minimum à mettre en place quelque soit le site, mais que l’ordre est à adapter en fonction des contraintes et des besoins.

Par exemple, pour un site dont le public est international, l’utilisation d’un CDN sera très certainement un point à mettre en premier.
Si vous avez des pages contenant beaucoup d’images, peut-être que l’utilisation d’un domain sharding sera bénéfique. Mais peut-être que vous pourrez utilisez des sprites et limiter ainsi le chargement à une seule image ?

Sprites Might & Magic

Sprites Might & Magic

Un exemple : le jeu Might & Magic – Heroes Kingdoms de Ubisoft. Dans ce jeu, les développeurs ont utilisés beaucoup de sprites afin de limiter les accès réseau. Ils ont également mis leurs sprites sur un domain sharding. Sauf que là, ils ont mis toutes leurs images sur le même domain sharding. Ils auraient peut-être dû mettre une 1 sur 2 par exemple.

Ce jeu, qui a beaucoup d’images à charger avant de pouvoir commencer à jouer, a choisi de mettre un écran de chargement qui permet à l’utilisateur de patienter. C’est également une bonne solution. Il ne faut pas que cet écran prenne plus de temps à charger que les images nécessaires à la première visualisation de l’écran de jeu.

Et les 20% restant

Je vous l’ai dit au début de cette série d’articles : les 80 premiers pourcentages de résultats s’obtiennent avec 20% de travail. Le reste est très pointilleux, et demande beaucoup de travail.

Aussi, il faut bien comprendre les enjeux de l’optimisation d’un site et se poser les bonnes questions au bon moment : est-ce vraiment nécessaire de pousser très loin l’optimisation ?

Et si vous voulez pousser vraiment plus loin, voici une petite liste de points à vérifier. Ce n’est qu’une simple liste. Elle ne demande qu’à être complétée et adaptée par vos soins.

Imbrication des « div » : plus vous allez imbriquer vos éléments et plus le code va être complexe à interpréter par le navigateur. Essayez donc, dès que c’est possible, de minimiser les imbrications.

Rapidité de JavaScript : cela paraît une évidence, mais on y pense pas toujours. Il faut optimiser les fichier JavaScript car ils sont exécutés sur le poste client et peuvent considérablement ralentir le site, notamment si vous visez les mobiles.

Chargement asynchrone : si vous utilisez Google Analytics, pensez à vérifier que vous utilisez bien le dernier script car il est asynchrone. Il ne ralentira pas votre site si le serveur de Google est lent. Vous pouvez également charger les publicités, lorsque cela est possible, en asynchrone (au passage, je vais proposer un code asynchrone pour ma régie PBeM Exchange).

Cache de vos pages PHP : si vous avez la possibilité de mettre en cache certaines de vos pages PHP, n’hésitez surtout pas à le faire. Est-ce que votre page d’accueil change à chaque visiteur ? Si ce n’est pas le cas, vous pouvez la mettre en cache et ne plus avoir à faire d’appel SQL. Votre serveur vous remerciera ! Et si votre page complète ne peut-être mise en cache, vous pouvez très certainement mettre des sections uniquement.

PHP accélérateur : là, c’est au niveau du serveur que ça se passe. Il permettent de conserver en mémoire le résultat de la compilation des scripts PHP pour les appels ultérieurs. En fonction de votre OS et de votre serveur web, vous avez le choix : APC, eAccelerator, XCache, …

Minification HTML : cela paraît aussi évident, mais simplement réduire les espaces et les sauts de ligne d’un fichier HTML vous fera très certainement gagner quelques millisecondes. Si vous en avez l’occasion, regardez le code d’une page de Google. Vous verrez à quoi peu ressembler une page HTML minifiée.

Dimension des images : n’oubliez surtout pas d’indiquer les dimensions des images dans votre code HTML. Et ne redimensionnez pas les images via le HTML. Si vous devez utiliser des miniatures, faites de vraies miniatures, ne prenez pas les images en indiquant une dimension inférieure.

Les tableaux : n’utilisez pas de tableau pour faire votre mise en page. Les tableaux doivent être utilisés pour des données tabulaires. Au niveau du rendu, le navigateur attendra d’avoir complètement chargé le contenu du tableau avant d’afficher quoique ce soit.

Respectez les règles du W3C : Et oui, en respectant ces règles, vous respectez la façon dont fonctionnent les navigateurs. Du coup, votre code devrait être interprété plus rapidement. Et puis, vous y gagnerez en visibilité, en maintenance et en portabilité.

PNG 24bits / 8bits : vérifiez si vous ne pouvez pas vous passer du format PNG 24bits. Est-ce que vous utilisez vraiment la transparence ? Est-ce que autant de couleurs sont nécessaires ? Faites des tests. Vous pouvez gagner facilement 75% du poids de vos images.

Commentaires conditionnels : si vous les utilisez, placez un commentaire conditionnel vide dans le HEAD. En effet, IE bloque le chargement parallèle pendant le chargement de la première CSS.

CSS print : votre feuille de style CSS pour le print n’est certainement pas nécessaire tant que la page n’est pas affichée. Du coup, vous pouvez la mettre à la fin du fichier ce qui permettra à des navigateurs comme IE6 ou IE7 d’afficher quand même la page. Attention à la chargée via du JavaScript en asynchrone ou alors, indiquez dans le même fichier CSS un @media pour isoler les règles liées au print.

Dégradés et bords arrondis : maintenant que CSS3 est là, autant l’utiliser ! Faites des dégradés à l’aide de CSS3 et les bords arrondis également. Votre charte graphique sera un peu dégradées sur les anciens navigateurs. Vérifiez simplement que cela ne soit pas gênant pour l’utilisation du site.

Serveur : en fonction du nombre de visiteurs ou de vos applications, augmentez la puissance de votre serveur. Multipliez les serveurs (http / SQL / statiques / dynamique). Sachez également que le PHP sous IIS est quand même un peu plus lent que sous Apache. Si vous avez vraiment besoin de beaucopu de puissance, passez peut-être sous un serveur type Nginx ou Lighttpd.

Backbone : hein ? C’est quoi donc ça ?! C’est le réseau que vous utilisez. Enfin, que votre serveur va utiliser. Si vous êtes chez un provider de mauvaise qualité, la bande passante sera limitée et partagée avec les autres utilisateurs. D’où l’intérêt d’être hébergé chez un provider sérieux. Maintenant, pour avoir testé plusieurs providers, le prix n’annonce pas toujours la qualité. Écoutez ce qui se dit, regardez qui est hébergé et vérifiez les temps d’accès sur du long terme. C’est un travail à long terme qui demande beaucoup de temps et de connaissances.

Conclusion

L’expérience ne remplacera jamais les simples listes et c’est pourquoi il y a des experts en la matière. Et comme nous sommes dans un domaine qui évolue chaque jour, l’expert doit savoir se remettre en question chaque jour et prendre le temps de faire de veille. J’estime à 50% le temps destiné à la veille pour un expert.

Chaque cas est particulier si vous souhaitez pousser à fond les optimisations. Et dans tous les cas, posez vous d’abord la question : « est-ce que ça vaut la peine d’aller si loin ? »

La liste que j’ai donné est minimaliste. Tout le monde devrait pouvoir en tenir compte et la mettre en place. La suite dépend de votre placement, de vos visiteurs, de vos ambitions ou simplement est-il question de vous faire plaisir. Je suis confronté chaque jour à ce dilemme qui consiste à se faire plaisir ou à faire en sorte qu’un client soit content. J’opte bien souvent pour le premier cas, le second suivant en général.

J’ai ouvert une section performance sur mon forum, je vous invite à venir y poser vos questions ou à donner vos solutions et vos astuces.

Et si vous souhaitez aller plus loin, je vous invite à vous inscrire au groupe Web Performance sur Diigo.

Share This