Optimiser son code PHP ne sert à rien
18 mars 2008 par zero-zombie
Aux détours de mes recherches sur Google, il m’arrive parfois de tomber sur des articles qui ne servent à rien. Voilà une catégorie spécialement sans intérêt : les conseils d’optimisation du code PHP.
Bien sûr, l’optimisation est importante… si l’on sait pourquoi on optimise et dans quel but. Mais les optimisations dont il est question là concernent des points de détail sans intérêt puisqu’ils compromettent la lisibilité du code, sont réalisés dans des conditions aberrantes et n’offrent qu’un gain ridicule. Un exemple : http://m-fernandez.developpez.com/articles/php/bench/
Qui a besoin de faire des optimisations à ce niveau en PHP ? Afin de voir une minuscule différence, l’auteur du bench est obligé de réaliser 3 millions d’itérations… mais qui fait 3 millions d’itérations pour afficher une page web ?
“Oui mais quand même, c’est un gain ?”
Franchement, non. Le temps passé à optimiser ou à relire un code moins lisible est une perte réelle, alors qu’une différence de temps d’exécution de 0.00001 seconde grâce à des efforts supplémentaires n’est pas un gain.
Pour optimiser une application web, on cherche avant tout à limiter l’utilisation de la base de données et optimiser les requêtes, à être à jour au niveau logiciel (la prochaine version de PHP, la 5.3 est assez prometteuse à ce niveau), utiliser des solutions “clean” (un cache d’opcode comme APC, par exemple) et limiter les échanges serveur.
Au lieu de réaliser des micro optimisations, il est nettement plus intéressant de se concentrer sur les évolutions du langage. Certaines personnes utilisent encore PHP4, ce que je trouve ahurissant en 2008 et songent tout juste à passer à PHP5. Pour ma part, je me prépare à PHP6 et je fais évoluer mon ancien code pour pouvoir l’utiliser peu après sa sortie et ainsi profiter des gains de performances annoncés, mais aussi de toutes les simplifications qui découleront du support natif d’UTF-8.
Mais revenons à l’optimisation, quelles sont les choses qui font réellement gagner du temps d’exécution ?
Les premières recommandations qui me viennent à l’esprit sont :
- Vérifier que la structure de la base de données est correcte et qu’il y a bien des indexes sur les champs qui en ont besoin (ceux sur lesquels se font les liaisons et les recherches
- Utiliser au mieux mémoire du serveur en réglant la mémoire allouée au cache MySQL dans my.ini (par exemple)
- Utiliser un cache d’opcode PHP comme je l’ai déjà signalé ci-dessus. C’est l’affaire de quelques minutes et le gain est très net. D’ailleurs, c’est tellement indispensable que PHP6 intégrera APC d’office.
- Optimiser vos images. Eh oui, c’est toujours un point important, ADSL ou non : le serveur travaille pour envoyer une image.
- Utiliser les capacités de clipping des navigateurs actuels pour faire des pseudos sprites CSS. En vous creusant un peu la tête, vous pouvez réduire énormément le nombre d’images nécessaires dans une page.
- Transférez au maximum les balises IMG décoratives communes à toutes vos pages dans des styles. Vous limiterez ainsi les références aux images et éviterez beaucoup d’appels serveurs. Du reste, vous aurez un code bien plus claire en séparant la partie graphique du code HTML proprement dit.
Et n’oubliez jamais que si les optimisations serveurs vous concernent en tant que développeur/administrateur d’un serveur, le visiteur ne verra généralement d’amélioration que pour les améliorations concernant s’adressant au navigateur : poids et nombre des fichiers liés, principalement. Pour diminuer le poids de vos pages, pensez non seulement à gzipper vos pages HTML à la volée, mais aussi vos fichiers JS (et même CSS, éventuellement). La méthode est expliquée sur cette page pleine de bon sens, point n°6.


[…] quelques benchmarks qui illustrent ce que j’écrivais dans l’article intitulé “Optimiser son code PHP ne sert à rien” : au lieu de chercher les petites optimisations, il vaut mieux passer son temps à faire […]