L’impact des redirections HTTP sur vos performances web

par | Avr 5, 2021 | Non classé

Boris Rogier

Boris Rogier

Co-founder

How HTTP redirects impact web performance

 

L’impact des redirections HTTP sur vos performances web

Les redirections HTTP sont fréquentes ; et elles ont un impact sur les performances de vos sites et web apps. Cet article explique ce que sont les redirections HTTP, comment elles fonctionnent et quel est leur impact sur l’expérience des utilisateurs.

Qu’est-ce qu’une redirection HTTP ?

La toute première chose à savoir est ce que sont les redirections HTTP et comment elles fonctionnent.

Comme son nom l’indique, la redirection HTTP fait référence au fait que la requête d’un client vers le contenu web d’un certain serveur peut être redirigée vers un autre endroit.[/vc_column_text][vc_single_image media= »2257″ media_width_percent= »100″][vc_column_text]Comme illustré ici, le client demande le contenu de l’emplacement /doc. Le serveur répond avec le code d’état HTTP 301 (Moved Permanently) et fournit le nouvel emplacement /doc_new. Le client doit alors lancer une nouvelle requête HTTP vers ce nouvel emplacement.

Quand une redirection HTTP est-elle utile ?

Il existe différentes raisons pour lesquelles vous pouvez utiliser les redirections HTTP.

Tout d’abord, vous pouvez utiliser les redirections pour garantir la diffusion d’un contenu actualisé :

  • Vous pouvez étendre la portée de votre site en redirigeant les demandes adressées à yourcompany.com vers www.yourcompany.com
  • Vous souhaitez adapter la structure du contenu de votre site web et n’avez aucun contrôle sur les liens de tiers vers ce contenu.
  • Votre organisation a fusionné avec une autre et vous avez déménagé vers un autre domaine. Vous voulez vous assurer que les liens existants ou les signets des utilisateurs vous atteindront toujours.

Deuxièmement, vous pouvez utiliser les redirections pour diffuser un contenu qui s’adapte au mieux aux appareils et à l’emplacement des utilisateurs. Par exemple, vous pouvez rediriger tous les utilisateurs d’appareils mobiles qui accèdent au site de votre entreprise (yourcompany.com) vers la version optimisée pour les mobiles (m.yourcompany.com). Vous pouvez également personnaliser les services fournis en fonction de la localisation de l’utilisateur.

Enfin, vous pouvez utiliser les redirections pour des raisons de sécurité. Par exemple, vous souhaitez certainement rediriger toutes les demandes HTTP vers les connexions HTTPS sécurisées correspondantes !

Les différents types de redirections HTTP

Il existe deux grandes catégories de redirections : côté serveur et côté client.

Redirections côté serveur

Dans une redirection côté serveur, le serveur utilise des codes de statut HTTP spécifiques pour demander au client de rediriger la demande vers l’autre URL.

Les codes de redirection les plus utilisés sont résumés dans le tableau suivant :[/vc_column_text][vc_single_image media= »2289″ media_width_percent= »100″][vc_column_text]

Redirections côté client

Comme alternative aux redirections HTTP déclenchées au niveau du serveur, deux autres techniques de redirection peuvent être utilisées :

  • Redirections HTML avec <meta> l’élément
  • Redirections JavaScript via le DOM

Ces techniques sont toutes deux des redirections côté client.

L’un des avantages de ces techniques est que vous ne devez pas contrôler le serveur pour qu’il fonctionne.

Le principal inconvénient est qu’elles ne peuvent pas être utilisées pour tous les types de ressources. La redirection HTML, par exemple, ne fonctionne qu’avec le HTML, et pas pour des contenus comme les images ou d’autres types.

L’impact des redirections HTTP sur les performances web

La redirection des demandes des clients vers d’autres lieux peut avoir un impact important sur les performances.

Analysons ce qui se passe lorsqu’un utilisateur accède d’abord à un site web en HTTP et est redirigé vers la connexion sécurisée HTTPS correspondante.

Les différentes étapes de connexion sont les suivantes :

  1. Le client envoie une requête DNS pour obtenir l’adresse IP du serveur.
  2. Le client établit une connexion TCP avec le serveur.
  3. Le serveur traite la demande et renvoie le code de statut de redirection HTTP.
  4. Le serveur envoie le reste du contenu de la réponse HTTP au client (pas grand-chose car il s’agit d’une pure instruction de redirection).
  5. Étant donné que la redirection implique une connexion HTTPS sécurisée, le client doit établir une nouvelle connexion TCP avec le serveur.
  6. Le client établit la connexion sécurisée par le biais du processus de prise de contact TLS et envoie la demande du contenu requis.
  7. Le serveur traite la demande et renvoie une réponse (code de statut 200 OK) au client.
  8. Le serveur envoie le reste du contenu de la réponse HTTP au client.

[/vc_column_text][vc_single_image media= »2272″ media_lightbox= »yes » media_width_percent= »100″][vc_column_text]Pendant les quatre premières étapes, l’utilisateur ne voit rien s’afficher à l’écran. Selon les conditions du réseau, les performances du service DNS, ainsi que les performances du serveur, cela peut avoir un impact considérable sur l’expérience de l’utilisateur final.

Il est donc important de surveiller ce type d’événements de redirection.

Comment les redirections sont rapportées dans l’API de navigation temporelle du W3C

L’API de navigation temporelle du W3C fournit le moment de la redirection comme l’une des mesures de la performance du Web.[/vc_column_text][vc_single_image media= »2277″ media_lightbox= »yes » media_width_percent= »100″][vc_column_text]Le temps de redirection est défini par le temps passé entre les événements redirectStart et redirectEnd (lorsque ces événements existent).

OK, à première vue, cela semble assez clair. Mais comme nous l’avons vu précédemment, la redirection implique souvent deux sessions TCP consécutives. D’après l’API de navigation temporelle, nous voyons que l’événement DNS et TCP se produit après l’événement de redirection potentiel. Alors comment cela fonctionne-t-il ?

Eh bien, voyons voir :[/vc_column_text][vc_single_image media= »2280″ media_lightbox= »yes » media_width_percent= »100″][vc_column_text]A partir de cet exemple de chronologie, vous pouvez remarquer que :

  • La session initiale complète de l’utilisateur HTTP fait partie du calcul de la durée de la redirection.
  • Les mesures individuelles de la session HTTP initiale (DNS, TCP, …) sont « perdues ». Elles ne sont pas rapportées séparément et l’API ne fournit rien concernant cette première requête HTTP.

Qu’en est-il des redirections HTTP multiples et consécutives ?

Toutes les sessions qui mènent à la demande finale feront partie du calcul du moment de la redirection, comme illustré ci-dessous :[/vc_column_text][vc_single_image media= »2281″ media_lightbox= »yes » media_width_percent= »100″][vc_column_text]

Prochaines étapes

Si vous avez trouvé cet article instructif, vous aimerez certainement nos autres articles sur le contrôle des performances web.
vous vous demandez comment cela peut être rapporté par la solution de Kadiska, jetez un coup d’œil ici !

Share this post

Newsletter

All our latest network monitoring and user experience stories and insights straight to your inbox.