Accéder au contenu principal

Optimiser les performances d'un site web

Introduction

J'ai récemment eu à améliorer les performances d'une application web d'entreprise hébergée en France et accessible depuis l'étranger par réseau interne. Cette problématique m'a conduit à approfondir la nature même du protocole HTTP et à découvrir de nombreuses règles d'optimisation des performances d'un site ou applicatif web.

Beaucoup de réflexions sont inspirées par les Best Practices des développeurs Yahoo! que je vous conseille vivement de lire.

Ce dossier sera découpé en plusieurs chapitres s'intéressant à un point précis d'optimisation. Si certains aspects sont décrits de manière simplifiée, je vous invite à suivre les références externes pour des informations plus détaillées.

Le contexte

Il est très simple : un internaute (l'utilisateur) accès à un site ou application web hébergé sur un ordinateur distant (le serveur). Il utilise son navigateur Internet favori (le client).

Les pages de notre site sont classiques, constituées d'éléments de nature diverses :
  • du contenu pouvant être généré dynamiquement (PHP, JSP, ASP...)
  • des scripts javascripts (notamment des librairies tierces comme Prototype)
  • des images constituant l'interface graphique
  • une ou plusieurs feuilles de style CSS
Nous cherchons à optimiser le temps de chargement de ces pages, s'étendant de l'appel à la page (clic sur un lien, saisie d'URL) au chargement complet des pages.

1e partie - L'échange HTTP

Pour localiser les différents leviers d'action à notre disposition, il est nécessaire d'avoir une compréhension globale des échanges HTTP qui s'effectuent entre le client et le serveur.

Conversations...

Supposons que notre utilisateur a demandé l'accès à la page index.php du site http://www.monsite.com.

Nous nous plaçons dans la situation la moins favorable : cet utilisateur n'a jamais consulté notre site.

Voici la chronologie des évènements :
en bleu les opérations effectuées côté client
en orange les opérations effectuées côté serveur

#1 Le client résout le nom de domaine
- Client : "Je cherche monsite.com, quelle est son adresse ?"

Rappelons que les noms de domaine ne sont que des raccourcis plus faciles à retenir pour nous que des adresses IP.
Le navigateur, lui, a besoin de connaitre l'adresse IP du serveur distant, pour savoir à qui envoyer sa demande d'accès à la page : transformer monsite.com en 111.222.333.444.

De la même façon que nous consultons les pages Jaunes pour connaitre le numéro du livreur de pizzas, lui consulte ses serveurs DNS pour connaitre l'adresse du serveur.

#2 Le client établit une connexion TCP/IP avec le serveur ==>
- Client : "Bonjour serveur monsite.com, pouvons-nous ouvrir le dialogue ?"

Première prise de contact, l'établissement du canal de communication. Pour plus de précisions sur la nature de l'échange, je vous invite à consulter cet article de Wikipedia. Retenez simplement que l'établissement de cette connexion a un coût en temps.

Nous verrons dans un prochain article que les configurations actuelles permettent une réutilisation des connexions existantes.


<== #3 Le serveur accepte la connexion avec le client
Serveur : "Oui. Parlons."

Le serveur accuse réception et accepte l'échange à venir.

#4 Le client envoie sa requête HTTP ==>
- Client : "Je suis Firefox 3 pour Windows. Je sais parler en HTTP 1.1 et suis même capable de récupérer des flux compressés. Je souhaite récupérer ta page index.php"

Le navigateur se présente, informe le serveur de ses capacités, et demande la récupération de la page.

#5 Le serveur traite la demande
- Serveur, pour lui-même : "Ce client veut la page index.php, générons la immédiatement"

<== #6 Le serveur répond à la demande
- Serveur : "J'ai réussi à effectuer cette requête. Voici le contenu demandé, c'est un fichier de type text/html qui pèse 50 Ko, qui a été modifié le 10 Mars 2009"

Le serveur constitue une enveloppe décrivant les informations renvoyées (les entêtes de réponse) et envoie au client les données demandées.

#7 Le client traite les données reçues
- Client, pour lui-même : "j'ai trouvé 10 images, 2 fichiers javascripts et 2 feuilles de style. Allons donc récupérer ces éléments."

Le navigateur interprète le flux reçu, et répète les étapes #1 à #7 pour tous les éléments qui y sont référencés (fichiers javascripts, images...) jusqu'à leur traitement complet.

Les durées significatives

La transcription simplifiée de cet échange met en valeur les différents temps de traitement que nous allons essayer d'optimiser dans les prochains chapitres.

Globalement, 3 axes d'amélioration se dessinent :
Véhiculer les données plus vite
Il est d'abord question ici de la simple performance des lignes utilisées. Si pour un site Internet public il est impossible de maitriser le débit de la connexion de l'utilisateur, dans un réseau d'entreprise des technologies logicielles et matérielles peuvent être utilisées pour améliorer les performances du réseau.

Si nous n'irons pas plus loin sur les questions d'architecture réseau, il est utile de garder à l'esprit la notion de latence réseau. Si l'on s'intéresse généralement au débit constaté (le volume de données reçues par unité de temps), celui-ci est fortement impacté par le délai de transmission d'un signal d'une extrémité à l'autre de la ligne, qu'on appelle latence.

Dans le cas de notre site Web, ça signifie qu'à volume de données égal, plus d'échanges signifie plus de délai. Nous verrons comment réduire ce phénomène.

Autre facette de l'envoi plus rapide des données, la génération des pages transmises (étape #5). On touche ici au travail d'optimisation du moteur applicatif, qui passe par de bonnes pratiques de codage, la réécriture de requêtes SQL, ou encore l'utilisation de cache côté serveur.
Ces techniques sont intimement liées à la nature de l'application web, mais ont le même objectif : réduire le temps de génération des pages.
Véhiculer moins de données
C'est une évidence logique qu'il est bon de rappeler : moins il y a de données à transmettre, plus le temps de chargement global de la page se fait rapidement.

Envoyer moins de données, c'est :
  • ne pas envoyer d'éléments "inutiles"
  • diminuer le volume des éléments utiles envoyées, sans perte de contenu pour l'utilisateur
Des articles publiés prochainement seront consacrés à cette baisse de volume transmis.
Véhiculer les données plus intelligemment
Enfin, nous verrons que certaines bonnes pratiques de conception découlent directement de certains mécanismes du protocole HTTP, en jouant par exemple sur l'ordre des éléments dans la page ou leur conception même.


Dans le prochain article, nous entrerons dans le vif du sujet avec les premières règles à appliquer pour optimiser les performances de son site web.

La suite : prochainement !

Commentaires

  1. Merci pour le post, on attend la suite.
    Reste plus qu'à mesurer le temps de chargement de la page avec des outils type netvigie ou equivalent pour gérer les modifications et les benefices.

    Merci

    RépondreSupprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

Les outils d'analyse de requêtes HTTP

L'analyse des échanges HTTP entre navigateur et serveur web est un bon moyen de détection des opérations les plus consommatrices en temps, soit celles qui impactent le plus le temps de chargement global d'une page.
Tour d'horizon des outils gratuits existants :
Outils en ligneD'une utilisation simple et rapide, ces outils proposent une vision synthétique des échanges à travers une chronologie précise des opérations, ainsi que le détail des requêtes et réponses HTTP. Toutefois, ils ne proposent généralement pas les mêmes options qu'un navigateur, notamment en terme de gestion de cache.
site-perf.comPingdom tools
L'analyse de ce blog par Pingdom tools
Plugins navigateurs
Ces outils s'intègrent à votre navigateur, ce qui vous permet de simuler exactement les situations de configurations de vos visiteurs.
FirefoxLe compagnon idéal est l'extension livehttpheaders, outil de capture des requêtes et réponses HTTP
Firebug propose également une analyse complète, avec une…

Tester son site sous les versions d'Internet Explorer 6, 7, 8

Si la mort prochaine de la version 6 d'Internet Explorer est annoncé un peu partout ces derniers temps, il n'empêche que l'univers des navigateurs (et particulièrement celui d'IE) avance bien plus lentement que ne naissent les normes et se développent les technologies.

Assurer la compatibilité de ses sites web avec les différentes versions d'Internet Explorer demeure un casse-tête, et chacun sait qu'il est maintenant quasiment impossible de faire coexister plusieurs versions d'IE sur son PC.