Qu’est-ce que le RTT et pourquoi est-ce important ?
Le temps d’aller-retour (RTT) mesure le trajet d’un signal jusqu’à l’autre extrémité et son retour. Ce n’est pas le temps de réponse complet : DNS, connexion, traitement serveur et transfert peuvent s’y ajouter. Les requêtes parallèles n’additionnent pas nécessairement un RTT chacune à la suite.
Comment le RTT influence les Web Vitals
- LCP : le HTML et les ressources critiques peuvent retarder l’affichage du contenu principal.
- INP : mesure la réponse jusqu’à l’image suivante, pas la fin d’une requête asynchrone. Les résultats peuvent tarder malgré un bon INP ; mesurez les deux délais.
- TTFB : inclut plus qu’un RTT, notamment la connexion et le traitement. Ce n’est pas un Core Web Vital.
- CLS : une ressource tardive peut déplacer la mise en page si son espace n’est pas réservé. Un RTT élevé seul ne prouve pas un décalage.
Causes fréquentes d’un RTT élevé
- Serveur d’origine distant ou trajet supplémentaire entre CDN et backend.
- Requêtes dépendantes ou redirections en chaîne.
- Nouvelles connexions au lieu d’une réutilisation possible.
- Ressources tierces critiques découvertes tardivement.
- Traitement serveur lent, qui peut ressembler à un problème réseau dans le temps total.
Comment réduire le RTT en pratique
- Comparez les régions et envisagez un CDN ou un traitement proche du public. Vérifiez quelles réponses sont réellement servies en périphérie.
- Testez HTTP/2 et HTTP/3 là où ils sont disponibles. Ils ne suppriment pas la distance ; HTTP/2 reste soumis au blocage TCP.
- Mettez en cache les ressources statiques versionnées. Pour HTML et API, respectez confidentialité et fraîcheur.
- Utilisez
<link rel="preconnect">,dns-prefetchet preload de polices uniquement pour les ressources critiques confirmées. Ils ne réduisent pas le RTT physique. - Retirez les requêtes inutiles et différez le JavaScript non critique. Le chargement différé convient à certains contenus hors écran, pas à l’image LCP.
- Réduisez les redirections et réutilisez connexions ou sessions TLS. Vérifiez 0-RTT et les réglages de certificat pour l’environnement réel.
Examiner le RTT avec les résultats de Milten
- Comparez RTT, latence serveur et débit par origine dans les conditions du test.
- Examinez les indications de ressources et la cascade, surtout avant LCP/FCP. Une indication absente est une piste à vérifier.
- Séparez traitement serveur et délai de transport.
- Répétez les scans après publication. Pour comparer des lieux, vérifiez les régions disponibles et gardez des conditions équivalentes.
Vérifications à effectuer
- Identifier l’origine lente et la chaîne critique.
- Vérifier le protocole navigateur–périphérie et, si nécessaire, périphérie–origine.
- Ajouter seulement des indications utiles de connexion ou de préchargement.
- Réduire les redirections en conservant l’URL finale prévue.
- Respecter confidentialité et fraîcheur avec le cache ou stale-while-revalidate.
- Comparer plusieurs essais équivalents et les données de visites réelles.
Commencer par mesurer
Sur milten.io, lancez Speed Scanner, examinez les constats réseau et choisissez un goulot d’étranglement confirmé. Conservez le résultat initial et les conditions, apportez un changement ciblé et comparez à nouveau.
