Parmi les études disponibles comparant les performances de sites web, dont la présentation
High Performance Web Sites
de Steve Souders (Google Inc.) à Web2.0 Expo et ses nombreuses versions similaires reprises sur les blogs,
on lit régulièrement que le temps de réponse du serveur ne compte que pour une part minime (5-20%) du temps d'attente final du visiteur, et l'on n'y trouve
par conséquent qu'à majorité des conseils (si bons soit-ils) relatifs à l'efficacité du rendu des pages par le navigateur.
Mais ces études quantitatives concernent généralement le top-10 des sites web (amazon.com, google.com, myspace.com, yahoo.com, youtube.com, etc.) qui d'une part font particulièrement appel à de nombreux
scripts et feuilles de styles, et d'autre part ont déjà profité de l'optimisation requise côté serveur (tant hardware que software).
Optimiser la résolution et le poids des images, compresser, zipper, compacter ses librairies Javascript et ses fichiers CSS, ordonner ses scripts et les requêtes HTTP au sein d'une page,
sont donc des
pratiques à connaître pour un développeur front-end,
mais elles concernent pour la plupart les
ressources externes à une page HTML (ou PHP dans cet exemple) ;
elles facilitent donc le rendu final d'une page par le navigateur,
mais n'accélèrent en rien le prime accès à la page, la
première réponse du serveur.
Combien de temps un visiteur attend-t-il après avoir cliqué sur un résultat de recherche ou un lien externe vers votre site avant d'abandonner et de passer au suivant,
pensant que le lien est mort ou que le serveur ne répondra plus? Une fois même arrivé sur votre site, combien de pages lentes aura-t-il la "patience" de visiter?
Sans oublier les robots d'indexation, Google & cie, qu'on ne peut risquer de faire attendre, voire même d'atteindre un « Timeout serveur » (listé dans le Top-5 des
facteurs de ranking négatif par SEOmoz.org)
et pour lesquels seule la page HTML importe.
Si l'implémentation back-office, souvent basée pour des sites à taille moyenne sur des CMS open-source aux performances variables (et souvent mauvaises, cf. Wordpress ou Joomla),
peut (à la limite) se passer d'un affichage rapide, le front-office se doit absolument impeccable. Or, avec un peu de trafic, plus le serveur est lent, plus le serveur est... lent.
Plus sa charge augmente, plus il devient indisponible aux requêtes qui s'accumulent et tend à répondre sous une durée interminable, sans compter le nombre maximum de
connexions actives sur le serveur MySQL vite épuisé.
Il existe donc, pour chaque installation, un seuil de requêtes serveur qui, s'il est dépassé, entraîne une hausse exponentielle de charge
et mène au crash. Pour cette raison, un site "suffisamment rapide" pour le visiteur peut encore gagner à être "plus rapide" si cette différence lui permet de survivre à d'importants
pics de visites, et éventuellement de fonctionner sur un système physique plus simple qu'il ne le demanderait autrement (économie de coûts d'hébergement).
Les points abordés ici peuvent ainsi concerner tous les sites web, mais spécialement les sites petits à moyens, sur hébergements mutualisés, ou même sur "serveurs dédiés hébergeant plusieurs sites",
qui peuvent déjà subir X facteurs de ralentissement et ne peuvent bénéficier d'une architecture serveur complexe.
Pour ceux-là, et pour tous, en dehors du choix d'un framework ou d'un CMS performant, quelques idées d'optimisation pour 1. une économie sur les coûts d'hébergement, que ça soit le contenu
lui-même du site qui augmente ou bien son nombre de visiteurs (extensibilité, ou "scalability"), et 2. une meilleure expérience utilisateur et un gain de trafic.
