Tester la vitesse de chargement du site web avec webpagetest.org

Le sujet de la vitesse de chargement n’est pas nouveau : dès les débuts du web, le temps de chargement était un facteur important pour le succès d’un site web. La bande passante des connexions internet était si faible — rappelons-nous : les modems 56k étaient souvent le summum à la fin des années 1990 ; aujourd’hui, les connexions de 100 MBit et plus ne sont pas rares — que quelques centaines de kilo-octets constituaient déjà la limite supérieure pour une page permettant un temps de chargement décent.

Avec l’augmentation de la bande passante, la situation dans le domaine des ordinateurs de bureau s’est, du moins théoriquement, quelque peu détendue. L’utilisation croissante des terminaux mobiles et des écrans de plus en plus grands avec une haute résolution (à l’époque, fin des années 1990, par exemple 19″ avec 1 200 x 800 pixels, aujourd’hui, par exemple 27″ avec 2 560 x 1 440 pixels) place les exploitants de sites web dans une situation similaire à celle d’autrefois — c’est un peu le même problème que celui des batteries de smartphones : les batteries sont de plus en plus performantes, mais les appareils consomment de plus en plus d’énergie.

Aujourd’hui, le temps de chargement prend une nouvelle dimension : les moteurs de recherche, Google en tête, intègrent le temps de chargement dans le calcul de l’index. Pour simplifier : plus un site web charge lentement, plus il sera affiché loin dans les résultats de recherche. C’est à partir de ce moment-là que le sujet a touché les exploitants de sites web professionnels et qu’une véritable course contre la montre a commencé. État des lieux en 2026 : Google évalue l’expérience de chargement principalement via les Core Web Vitals — Largest Contentful Paint (LCP, quand le plus grand contenu visible est chargé), Interaction to Next Paint (INP, rapidité de réaction de la page aux saisies) et Cumulative Layout Shift (CLS, stabilité visuelle du contenu lors du chargement). C’est un facteur de classement parmi d’autres ; un contenu de qualité reste primordial.

Il existe plusieurs niveaux sur lesquels les optimisations peuvent se faire sentir. D’une part, ceux qui concernent la connexion en elle-même, ou la « puissance » — comparaison automobile : le nombre de chevaux, si la voiture est aérodynamique, son poids… D’autre part, si un site web est bien construit, évitant les chargements inutiles d’éléments — comparaison automobile : le conducteur ; conduit-il de manière optimale, connaît-il le parcours ou doit-il s’arrêter à tous les feux ? Il existe certainement de meilleures comparaisons que celle de la voiture 😉 Quoi qu’il en soit, les deux niveaux sont expliqués plus en détail dans les paragraphes suivants.

• Infrastructure : en général, le fait que le site web soit exploité sur un serveur d’hébergement partagé ou un serveur dédié joue un rôle. La vitesse commence dès la connexion internet du centre de données et la manière dont les routeurs du fournisseur connectent les différents serveurs. Il en résulte non seulement la vitesse, mais aussi ce que l’on appelle le Time to first Byte, une mesure du temps nécessaire pour que le premier octet arrive du serveur au client.
• Serveur web : le serveur web joue également un rôle dans l’optimisation. De manière générale, les serveurs web avec Nginx sont plus rapides qu’Apache — ce n’est pas forcément le cas, avec un peu de travail de configuration, Apache peut aussi s’envoler. Mais le changement de logiciel n’est pas le seul à apporter de la vitesse. Des paramètres tels que Keep-Alive permettent également de ne pas avoir à renégocier la connexion au serveur web après chaque requête.
• La mise en cache est un sujet complexe, car il existe du cache à de nombreux niveaux (CDN, proxy inverse HTTP comme Varnish Cache, cache local, cache de base de données comme memcached ou Redis, …). Le caching fait partie des options les plus efficaces pour réduire le temps de chargement, selon la manière dont il est utilisé. Il convient de noter que tout ne peut pas toujours être mis en cache — les pages à haute fréquence de modification, comme les portails d’actualités, souhaitent que les visiteurs voient toujours les derniers articles.

Voici en bref la signification des 6 points :

1. First Byte Time : Temps de réception du premier octet du serveur web. Cette valeur peut être influencée principalement au niveau de l’hébergement, par exemple par la mise en cache. La valeur dépend de l’environnement d’hébergement physique (centre de données, serveur) et de la charge actuelle des systèmes.
2. Keep-alive enabled : Option du serveur web qui permet de maintenir la connexion ouverte entre le serveur et le navigateur, évitant ainsi de devoir renégocier le handshake TCP à chaque fois. Une page web comporte souvent 100 éléments ou plus à charger — une optimisation apparemment mineure peut donc déjà avoir un impact. Avec HTTP/2 et HTTP/3, de nombreux fichiers sont de toute façon chargés en parallèle via une seule connexion aujourd’hui.
3. Compress transfer : également un paramètre du serveur web. Le serveur web peut transmettre les données de manière compressée, de sorte que moins de données doivent être transférées. Les navigateurs modernes sont désormais tous capables de gérer le transfert de données compressées.
4. Compress images : ici, les exploitants de sites web sont sollicités. L’indicateur montre à quel point les images chargées sont compressées. Est-il possible de réduire la taille (sans perte de qualité) ?
5. Cache static content : les éléments affichés proviennent-ils du cache ou ont-ils été générés fraîchement par le serveur web ?
6. Effective use of CDN : les contenus sont-ils diffusés par un CDN (Content Delivery Network) ?

Dans le tableau supérieur, d’autres valeurs sont à lire, qui doivent être comprises comme le résultat du test de vitesse. Ici, la vitesse d’affichage du site web est divisée en étapes individuelles afin de mieux comprendre où les temps de chargement se produisent.