IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Démarche de diagnostic et d'optimisation pour améliorer les performances d'un site Web.

Image non disponible


précédentsommairesuivant

III. Améliorer la gestion de votre bande passante

Si vous disposez d'un site Internet à fort trafic ou d'un serveur avec une faible bande passante, vous pouvez apporter des optimisations consistant à réduire le flux qui transite entre le site et le navigateur du visiteur. Pour cela, il est possible :

  • d'utiliser des systèmes de cache ;
  • d'éviter d'envoyer ou de déporter l'envoi de fichiers ;
  • ou encore de réduire la taille et le nombre des fichiers échangés.

Précision sur les différents temps d'attente :

Avant de commencer, il faut différencier deux types différents d'attente :

  • le temps de connexion ;
  • et le temps de latence.

Un navigateur Internet doit recevoir l'ensemble du code HTML (DOM) du serveur avant de pouvoir afficher le contenu. Pour chaque élément, contenu, image, vidéo, etc., le navigateur se connecte au serveur grâce au protocole TCP/IP. Ce processus prend en moyenne 70 ms pour un serveur proche et peut aller à plus de 300 ms pour le réseau mobile. C'est le temps de connexion.

À cela, il faut ajouter le temps de latence du serveur qui ne répondra pas toujours instantanément, car il traite les demandes dans l'ordre d'arrivée.

Ces temps sont irréductibles. Aussi, les navigateurs récents établissent simultanément plusieurs connexions avec le serveur. Ceci permet de paralléliser les temps d'attente.

Sur une page HTML classique, 70 % du temps d'affichage n'est pas le temps de téléchargement, mais le temps nécessaire à la connexion auquel s'ajoute le temps de latence, la meilleure des optimisations est donc de réduire le nombre de requêtes au serveur.

BON À SAVOIR : il est possible, si vous avez une architecture comprenant plusieurs serveurs, que les dialogues entre ces derniers impactent vos performances. Même si ce cas est très peu probable, il est bon de s'en souvenir si vous ne trouvez pas d'où viennent vos problèmes de performance, notamment si les serveurs sont distants physiquement.

III-A. Système de cache HTTP

Les systèmes de cache permettent d'éviter de recharger des éléments déjà téléchargés. Ceci permet d'avoir des allers-retours serveur beaucoup plus rapides ou même de les éviter.

Les navigateurs des visiteurs gèrent leur propre cache. À part quelques options configurables par l'utilisateur, le fonctionnement de ce cache est défini par les paramètres du serveur. L'intérêt est de profiter du cache du navigateur pour éviter de récupérer les fichiers et donc limiter la bande passante utilisée par les navigateurs.

III-A-1. Gestion des ETag

SYMPTÔMES : la bande passante de votre site est saturée, ou le premier chargement des pages est lent pour les visiteurs.

SOLUTION : par défaut, la balise HTTP ETag (entity tag) est activée, elle permet de ne pas télécharger deux fois les mêmes fichiers. Chaque ressource statique (image, CSS, JS) possède un identifiant unique pour une date de modification donnée. Ainsi, lors d'un second chargement de la page, le navigateur enverra l'ETag au serveur qui répondra soit par un code 302 Found (trouvé, donc non modifié) soit par un 200 OK (envoi du fichier). Ce système n'évite pas les allers-retours client-serveur, mais évite de renvoyer le contenu des fichiers, et donc évite la consommation de bande passante ainsi que le traitement que doit effectuer le serveur.

Attention : si vous avez une architecture avec plusieurs serveurs, vous devez utiliser cette option avec précaution. Dans ce cas, l'ETag est différent pour chaque serveur. Il est possible que cette balise augmente la bande passante plutôt que de la réduire. C'est pourquoi certains outils de mesure vous conseillent de la désactiver.

III-A-2. Date d'expiration d'une ressource

SYMPTÔMES : malgré les ETags en place, le chargement d'une page reste lent. Vous voyez dans Firebug qu'un grand nombre de fichiers est chargé par page et que le temps d'affichage de votre page est principalement du temps de latence.

SOLUTION : pour éviter le temps de latence, il existe, pour le serveur Apache, le mod_expire. Il ajoute un en-tête HTTP « Expires » qui indique la date d'expiration d'une ressource au navigateur. Tant que cette date n'est pas atteinte, le navigateur utilisera directement les données qu'il a en cache. Il n'y a donc plus aucun temps d'attente.

La stratégie la plus efficace est donc de mettre une durée de vie illimitée et de renommer la ressource lorsqu'elle est modifiée.

Exemple d'utilisation :

À chaque modification d'un fichier, on en change le nom : style.1.0.css devient style.1.1.css. Il est aussi possible de modifier l'URL d'appel en passant un paramètre fictif : style.css?c=1 devient style.css?c=2.

BON À SAVOIR : ce procédé est très performant après le chargement de la première page qui ne peut bénéficier du cache. De plus, il faut privilégier la réutilisation des ressources dans les différentes pages. Par exemple : utiliser dans toutes les pages un même et unique fichier CSS.

III-B. Réduire le nombre des fichiers

SYMPTÔMES : vous voyez dans Firebug qu'un grand nombre de fichiers est chargé par page et que le temps d'affichage de votre page est principalement du temps de latence.

III-B-1. Limiter le nombre de fichiers CSS et JS

Il est possible de regrouper les fichiers CSS ou JS en un seul. Plusieurs outils en ligne offrent ce service.

BON À SAVOIR : cependant, si vous utilisez un framework ou un CMS, vérifiez que celui-ci ne propose pas un mode d'agrégation.

III-B-2. Regrouper les images - Sprite

Il s'agit ici de regrouper les images du thème qui sont couramment utilisées en une seule. Cette technique s'appelle « Sprite ». L'avantage est de n'utiliser qu'un nombre réduit d'images. En revanche, il faudra, via une feuille de style, afficher l'image en background et la positionner.

NOTE : idéalement une page de votre site sera composée :

  • 1 feuille de style CSS ;
  • 1 feuille de JavaScript JS ;
  • 3 à 6 images pour le thème ;
  • les éléments « dynamiques » et spécifiques de la page.

III-C. Réduire la taille des fichiers

SYMPTÔMES : la bande passante de votre site est saturée, ou le premier chargement des pages est lent pour les visiteurs.

III-C-1. Réduire la taille des images

Si vous avez des images qui ne font pas partie intégrante du thème, vous devez les réduire au maximum, éviter de charger des images trop grandes (donc d'un poids important). Il est préférable de les réduire ou d'utiliser des mécanismes automatiques de mise à l'échelle. Une image ne devrait jamais dépasser 500 ko (sauf exception).

BON À SAVOIR : un outil en ligne permet de compresser un peu plus vos images sans détériorer la qualité. N'hésitez pas à l'utiliser sur vos images avant de les mettre en ligne : http://www.smushit.com/ysmush.it/

NOTE : vous trouverez facilement sur le web de nombreux articles traitant ce thème (GIF vs. PNG, PNG8, etc.).

III-C-2. Limiter le poids des fichiers - Compression Gzip

Les fichiers HTML, CSS et JavaScript sont des fichiers texte et donc particulièrement adaptés à une compression ZIP importante. Le temps nécessaire à cette décompression est négligeable pour le visiteur. En réduisant les flux envoyés aux utilisateurs, vous réaliserez une économie de bande passante.

BON À SAVOIR : ce gain de bande passante s'effectue au détriment d'une consommation accrue de CPU (la compression utilise de la puissance serveur).

III-C-3. Limiter le poids des fichiers - Minimify

Une autre possibilité pour limiter le poids de vos fichiers CSS et JavaScript est de les minimiser. La minimisation supprime les retours à la ligne, les tabulations ainsi que les commentaires. La lecture de ces fichiers devient donc quasiment impossible, mais ce n'est pas un problème en production.

BON À SAVOIR : la plupart des bibliothèques JavaScript sont disponibles en version « minimisée ». Elles sont donc plus rapides à charger.

Par exemple, la version 1.4.4 min de jQuery pèse 76.6 ko tandis que la version normale (de développement) pèse 178 ko.

III-D. Déporter des ressources

SYMPTÔMES : vous avez effectué toutes les modifications précédentes, mais le temps d'affichage de votre page est toujours long et l'augmentation de la bande passante de votre serveur est impossible. Vous pouvez alors utiliser une solution multiserveurs.

III-D-1. Multisites

Déployer son site sur plusieurs noms de domaine (ou sous-domaines) permet à l'utilisateur de charger plusieurs fichiers simultanément sur plusieurs serveurs. En effet, le navigateur ouvre un nombre de connexions défini par nom de domaine. Ainsi avec 2 serveurs on ouvre 2 fois plus de connexion.

Le nombre de connexions simultanées ouvertes dépend de votre navigateur. Internet Explorer 6 n'ouvre que 2 connexions simultanées, là où Firefox 3 en ouvre 8.

Si votre page contient une vingtaine d'images/fichiers CSS/fichiers JavaScript, sous Internet Explorer 6, elles seront réparties sur 2 connexions seulement, soit 10 ressources chargées en série et non en parallèle.

En répartissant les ressources sur 2 noms de domaine différents, il est possible que le navigateur ouvre jusqu'à 4 connexions (ou 16 pour Firefox). Donc deux fois plus rapide pour charger la page.

Pour autant, il ne faut pas non plus tomber dans l'excès inverse en possédant un grand nombre de domaines. Tout accès à un nouveau domaine entraîne des temps de recherche au serveur DNS (Domain Name System server, Serveur de nom de domaine, temps de « recherche » du serveur). Que le serveur soit le même ou non, ce temps sera incompressible. De plus, le fait de multiplier les noms de domaine peut entraîner une complexité de maintenance. Il est donc important de calibrer le rapport nombre de ressources/nombre de domaines.

III-D-2. Externaliser les ressources - CDN (Content Delivery Network)

Si la bande passante est saturée, le CDN permet de stocker une page complète pour la restituer à l'utilisateur le plus rapidement possible sans passer par le serveur web. C'est une sorte de cache déporté, donc qui ne charge pas le serveur principal. Deux outils open source se démarquent : Varnish & Squid.

Un service plus évolué permet de géolocaliser les destinataires : ce système repose sur un mécanisme de routage afin d'utiliser les serveurs « les plus proches » pour lui fournir les données de la page dont il a besoin. Akamai est le leader du marché.

NOTE : Google offre une sorte de CDN (en offrant une URL pour le téléchargement des bibliothèques JavaScript standard). Cette solution est un peu anecdotique.

III-D-3. ESI (Edge Site Includes)

Norme maintenue par le consortium W3C. Elle permet de « reconstituer » une page web grâce à des balises dans la page qui offrent la possibilité de charger la partie « statique » directement du serveur CDN, et la partie « dynamique » du serveur web.

Exemple : si votre site possède une page où l'utilisateur sera identifié avec son nom, il vous est impossible de la stocker dans le CDN, car elle sera différente pour tous les utilisateurs. L'ESI permet d'identifier cette zone générée dynamiquement pour stocker l'ensemble du contenu de la page sauf le nom utilisateur. Ce dernier sera récupéré directement du serveur web par le CDN qui l'agrégera dans la page envoyée au client.

III-E. Dernières techniques

SYMPTÔMES : votre serveur répond bien, mais vous cherchez à optimiser le temps d'affichage de la page pour augmenter la réactivité du site perçue par vos visiteurs.

III-E-1. Chronologie de chargement

C'est une chose généralement connue, mais dont les détails et les implications ne sont pas toujours bien mesurés : une page web est constituée de nombreux composants, qui sont chargés les uns après les autres par le navigateur.

Il faut s'assurer que la page peut être consultée de manière confortable, même si le temps de chargement est long. L'idée est d'ordonner le téléchargement des éléments en fonction de leur importance pour l'utilisateur. Par exemple, les bibliothèques JavaScript peuvent être mises en bas de page.

NOTE : cette optimisation ne concerne pas directement les performances, mais a un vrai impact sur l'impression de vitesse pour l'utilisateur.

III-E-2. Page Speed, module Apache

Google fournit un module Apache nommé Page Speed permettant d'accélérer la transaction serveur-client. Cet outil permet d'appliquer un certain nombre de filtres sur les pages HTML, les fichiers CSS et JavaScript, les images PNG et JPEG. Ces filtres permettent d'automatiser de nombreuses optimisations sans avoir à parcourir l'ensemble du code du projet. Les gains en performance peuvent être très importants sur certains sites.

BON À SAVOIR : l'outil peut-être très consommateur des ressources serveur (processeur et mémoire). Il est donc préférable de faire très attention en utilisant cette solution.

III-E-3. Précision sur les solutions présentées

Il existe encore d'autres méthodes pour optimiser la gestion de votre bande passante comme ouvrir des connexions persistantes, utiliser des balises meta HTML pour inclure des ressources directement dans le code HTML… Mais celles-ci peuvent devenir rapidement compliquées à mettre en place. C'est pourquoi il faudra d'abord privilégier les techniques proposées dans les autres parties avant de les prendre en considération.


précédentsommairesuivant

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2020 The Coding Machine. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.