Tester la vitesse de votre site et comprendre ce qui le ralentit

Gratuit, sans inscription, résultat en moins d’une minute.

Ce que « site lent » veut dire pour un visiteur à Douala

Un visiteur ne mesure rien. Il perçoit le délai entre son clic et le moment où il peut lire quelque chose. Ce délai se décompose en quatre étapes, toutes visibles dans une analyse technique.

1. La résolution DNS : traduire votre nom de domaine en adresse IP.
2. L’établissement de la connexion, poignée de main TLS comprise pour le HTTPS.
3. Le temps de réflexion du serveur avant d’envoyer le premier octet.
4. Le téléchargement puis l’affichage de la page et de ses ressources.

Sur une connexion mobile camerounaise, les deux premières étapes coûtent déjà plusieurs centaines de millisecondes. Il devient alors décisif de ne pas gaspiller les suivantes : un serveur qui met deux secondes à répondre ajoute son retard à une latence que vous ne maîtrisez pas.

Le TTFB, ou le temps que met le serveur à réfléchir

Le temps jusqu’au premier octet mesure l’intervalle entre la requête et le début de la réponse. C’est l’indicateur le plus honnête sur la qualité d’un hébergement, parce qu’il isole le travail du serveur du poids de la page.

Un TTFB élevé ne se répare jamais en compressant des images. Il vient du serveur : trop de sites sur la même machine, absence de cache d’opcode PHP, requêtes de base de données non optimisées, ou version de PHP dépassée. Sur nos plateformes, le temps de réponse constaté tourne autour de 200 ms grâce au stockage NVMe, à l’isolation des comptes et à un OPcache correctement dimensionné.

Tester la vitesse de votre site web : ce que mesure l’analyse

Le test gratuit se place du côté du réseau, là où se joue la première impression. Il vous donne :

• le temps de réponse du serveur, mesuré sur plusieurs requêtes successives ;
• la version du protocole HTTP servie : HTTP/1.1, HTTP/2 ou HTTP/3 selon la configuration du serveur ;
• la compression appliquée aux réponses textuelles, Gzip ou Brotli ;
• la chaîne de redirections traversée avant d’atteindre la page finale ;
• les en-têtes de cache, qui décident si un visiteur récurrent retélécharge tout ou rien.

Ces mesures sont complémentaires d’un outil comme PageSpeed, qui juge le rendu dans le navigateur. L’un vous dit si votre serveur est lent, l’autre si votre page est lourde. Confondre les deux conduit à optimiser pendant des semaines le mauvais bout de la chaîne.

Les cinq causes de lenteur les plus fréquentes

1. Aucun cache de pages. Chaque visite reconstruit intégralement la page en PHP et en base de données, alors que le contenu n’a pas changé depuis des jours.
2. Trop d’extensions. Un site WordPress avec quarante extensions charge quarante fois du code à chaque requête, y compris pour afficher une page de contact.
3. Images au format d’origine. Une photo de 4 Mo redimensionnée en CSS reste une photo de 4 Mo pour le visiteur, et pèse lourd sur un forfait mobile.
4. Version de PHP ancienne. Le passage d’une version obsolète à PHP 8.x fait souvent gagner un tiers du temps de génération, sans toucher au code.
5. Voisinage saturé. Sur un hébergement mutualisé sans isolation, un site voisin qui consomme tout le processeur ralentit le vôtre sans que rien chez vous n’ait changé.

Les deux premières causes se corrigent sans dépenser un franc. La dernière ne se corrige pas : elle se change d’hébergeur.

Compression, cache et protocole : les gains les plus rentables

La compression. Le HTML, le CSS et le JavaScript se compriment de soixante-dix à quatre-vingts pour cent. Brotli fait mieux que Gzip sur les mêmes fichiers ; nos serveurs le servent par défaut. Une page de 300 Ko tombe ainsi sous les 80 Ko réellement transmis, ce qui compte sur une connexion mobile.

Le cache navigateur. Des en-têtes corrects évitent au visiteur de retélécharger le logo et la feuille de style à chaque page. Le gain est nul sur la première visite et considérable sur les suivantes.

Le protocole. HTTP/1.1 traite les requêtes les unes après les autres. HTTP/2 les multiplexe sur une seule connexion, ce qui supprime l’essentiel de l’attente quand une page appelle trente fichiers ; il est actif par défaut sur tous nos comptes. HTTP/3, plus récent, s’appuie sur un transport différent pour mieux résister aux pertes de paquets ; l’analyse vous indique simplement si votre serveur actuel l’annonce.

Latence et distance : la part que vous ne maîtrisez pas

Un serveur situé en Europe répond à Yaoundé avec un délai incompressible dû à la distance physique et au trajet des câbles. Cette latence s’ajoute à chaque aller-retour : résolution DNS, connexion, négociation TLS, requête. Une page qui déclenche de nombreux aller-retours paie cette taxe plusieurs fois.

Trois leviers atténuent le phénomène. Réduire le nombre de requêtes, en regroupant les fichiers et en supprimant les scripts inutiles. Utiliser un réseau de diffusion pour les images et les fichiers statiques, qui les rapproche du visiteur. Et, quand la clientèle est majoritairement locale, choisir un hébergement web au Cameroun pour raccourcir le trajet dès la première requête.

Enfin, une page rapide qui affiche un avertissement de sécurité ne convertit personne. Contrôlez aussi votre certificat SSL : une chaîne de certification incomplète oblige certains navigateurs à faire une requête supplémentaire avant même d’afficher la page.

Questions fréquentes

À lire aussi