Introduction
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
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 ?"
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 ?"
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.
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"
- 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"
- 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
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 !
Merci pour le post, on attend la suite.
RépondreSupprimerReste 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