13 min de lecture
Codes de redirection HTTP expliqués : de 301 à 308
Ce que signifie chaque code de statut 3xx : 301, 302, 303, 307 et 308 comparés (permanence, méthode, cache, SEO), avec des exemples nginx, Apache et PHP.
Lire l’articleOutil de redirection gratuit
Testeur de latence des redirections
Chaque redirection impose aux visiteurs un aller-retour supplémentaire avant que la vraie page ne se charge. Voyez précisément combien de temps prend chaque saut de la chaîne, sous forme de diagramme en cascade (waterfall).
Mesures
Le réseau edge de Cloudflare valide toujours les certificats : cette option ne permet donc pas de contourner la vérification. Les problèmes de certificat sont signalés dans le résultat.
Envoyé avec la première requête, 16 Ko maximum. Un corps JSON est envoyé en application/json, les autres sous forme de formulaire, sauf si vous définissez un en-tête Content-Type.
De 1 à 50. Les navigateurs s’arrêtent après 20 redirections.
Les sites peuvent rediriger différemment les téléphones, les robots d’exploration et les bots d’aperçu de liens.
En-têtes de requête personnalisés 0/20
Envoyés avec chaque requête de la chaîne.
Aucun en-tête personnalisé.
Saisissez une valeur pour envoyer cet en-tête. Les valeurs d’en-têtes ne sont jamais enregistrées.
Suivre les balises <meta http-equiv="refresh"> et les en-têtes Refresh trouvés dans les pages HTML.
Suivre les redirections simples et inconditionnelles, comme location.href = "…", dans les scripts de la page.
Les paramètres sont mémorisés dans ce navigateur. Les cookies, les valeurs d’en-têtes et le corps de la requête POST ne sont jamais enregistrés.
Pourquoi la latence des redirections compte
Une redirection est une requête supplémentaire à part entière. Le navigateur doit résoudre l’hôte suivant, ouvrir une connexion, négocier le TLS pour un nouveau domaine et attendre le serveur, tout cela avant même de pouvoir demander la page elle-même. Un saut sur le même hôte peut prendre quelques dizaines de millisecondes, alors qu’une chaîne passant par un raccourcisseur, un domaine de suivi et une règle HTTP vers HTTPS peut facilement ajouter une demi-seconde ou plus, en particulier sur les réseaux mobiles.
Le temps de redirection précède tout le reste : il s’ajoute donc directement au Time to First Byte (TTFB) et au Largest Contentful Paint (LCP). C’est pour cette raison que Lighthouse et PageSpeed Insights signalent les redirections sur le document principal.
Comment les temps sont mesurés
Pour chaque saut, TrueURL mesure le temps écoulé entre l’envoi de la requête et l’arrivée des en-têtes de réponse. Cela inclut la résolution DNS et l’établissement des connexions TCP et TLS lorsqu’une nouvelle connexion est nécessaire, ainsi que le temps de traitement du serveur, mais pas le téléchargement du corps de la page. Le diagramme en cascade affiche les sauts dans l’ordre, ce qui fait ressortir le plus lent.
Les mesures sont effectuées depuis le centre de données Cloudflare qui exécute votre vérification, généralement le plus proche de vous, et non depuis votre appareil. Elles montrent la rapidité de réponse de chaque serveur, mais les vrais visiteurs ajoutent leur propre latence réseau à chaque saut. Répétez la mesure pour lisser les variations : la première peut inclure des caches DNS vides et de nouvelles connexions, alors que les suivantes sont généralement plus proches du régime normal.
À partir de quand une redirection est-elle lente ?
À titre indicatif, voici l’échelle que TrueURL utilise pour colorer le temps de chaque saut :
- Moins de 200 ms par saut : rapide, typique d’une redirection servie par un nœud edge de CDN ou par une simple règle de serveur web.
- De 200 à 600 ms : acceptable, courant pour un serveur d’applications ou pour une redirection vers un autre domaine qui nécessite une nouvelle connexion TLS.
- 600 ms ou plus : lent. La redirection est probablement générée par une application lourde, comme un CMS qui charge des extensions ou interroge une base de données, plutôt que par une simple règle.
La meilleure optimisation consiste à supprimer purement et simplement les sauts. Ensuite, répondez aux redirections au plus près du visiteur : une règle appliquée sur le CDN ou en edge répond bien plus vite qu’une application qui doit démarrer uniquement pour envoyer une 301.
Comment accélérer les redirections
- Faites pointer vos liens directement vers l’URL finale, sur votre site comme dans vos e-mails, vos annonces et vos profils sur les réseaux sociaux, pour que la plupart des visiteurs ne passent jamais par une redirection.
- Regroupez les règles HTTP vers HTTPS, d’hôte et de slash en un seul saut ; le Vérificateur de redirection HTTPS vous indique si c’est déjà le cas.
- Gérez les redirections dans la configuration de votre CDN, de votre répartiteur de charge ou de votre serveur web plutôt que dans l’application.
- Envoyez un en-tête HSTS pour que les visiteurs qui reviennent sur votre site évitent complètement la redirection HTTP vers HTTPS.
- Évitez d’empiler les raccourcisseurs de liens et les redirections de suivi.
Guides
Questions fréquentes
De combien une redirection ralentit-elle une page ?
Cela dépend du serveur et de la distance, mais chaque saut représente un aller-retour complet : généralement quelques dizaines de millisecondes pour une redirection edge sur le même hôte, et plusieurs centaines pour une redirection vers un nouveau domaine ou depuis une application lente. Les réseaux mobiles en ajoutent davantage. Mesurez votre propre chaîne ci-dessus pour le savoir.
Pourquoi les temps diffèrent-ils de ceux des outils de développement de mon navigateur ?
TrueURL mesure depuis un centre de données Cloudflare, qui dispose généralement d’une connexion plus rapide vers le serveur cible que votre appareil. Votre navigateur peut aussi réutiliser des connexions, éviter une redirection grâce à HSTS ou utiliser une 301 en cache. Servez-vous de ces chiffres pour comparer les sauts entre eux, et non comme une prédiction exacte de ce que vit chaque visiteur.
Pourquoi le premier saut est-il beaucoup plus lent que les autres ?
La première requête vers un hôte inclut généralement la résolution DNS et une nouvelle connexion TCP et TLS, et les sauts suivants sur le même hôte peuvent réutiliser une partie de ce travail. Si c’est un saut ultérieur qui est lent, examinez ce que fait ce serveur pour produire la redirection.
Faut-il lancer la vérification plusieurs fois ?
Oui, si vous voulez des chiffres fiables. Une mesure isolée varie selon les conditions du réseau et la charge du serveur. Répétez la vérification quelques fois et retenez la valeur typique plutôt qu’une valeur aberrante ; les caches réchauffés par la première exécution rendent souvent les suivantes plus rapides.
La latence des redirections a-t-elle un impact sur le SEO ?
Indirectement. Le temps de redirection s’ajoute au Time to First Byte et au Largest Contentful Paint pour les visiteurs qui arrivent par la redirection, et le LCP fait partie des Core Web Vitals (signaux Web essentiels) de Google. Sur les grands sites, des redirections lentes réduisent aussi le nombre de pages qu’un robot d’exploration peut récupérer dans le même laps de temps.
Le temps de chaque saut correspond-il au temps de chargement total de la page ?
Non. C’est le temps écoulé jusqu’à l’arrivée des en-têtes de réponse de ce saut. La page finale doit ensuite encore télécharger son HTML, ses styles, ses scripts et ses images : le temps de redirection est donc un délai qui s’ajoute au chargement normal.