Les protocoles http et le SEO – Partie 1 – Le http/2

Pour comprendre le http/2, il est important d’avoir une notion de ce qu’est le http. De manière très simplifiée, c’est un protocole, c’est-à-dire une méthodologie de dialogue, et dans le cas du http une méthodologie de dialogue serveur – client. Ce protocole est nommé HyperText Transfer Protocol. Différents protocoles existent et cohabitent selon leur utilisation, le FTP pour les transferts de fichiers, le SMTP et POP pour le mail…

Ce protocole, âgé de plus de 15 ans fonctionne encore très bien, mais dans un contexte où les pages web sont de plus en plus lourdes et surtout font appel à de plus en plus de ressources externes (Js – Css – Images – fontes), il fallait une méthode plus optimale de transfert de données.

Quelles sont les limites du http/1

Le http/1.1 et le http/2 fonctionnent globalement de la même manière. Lorsqu’on tape une URL, une connexion est établie puis un transfert démarre jusqu’à l’obtention totale des éléments nécessaires à l’affichage de la page.

Mais ces transferts ont des limites :

  • Les requêtes sont claires et ne sont pas compressées. 
  • Les requêtes sont limitées et on constate l’apparition de goulots d’étranglement dans les transferts. C’est pourquoi on pouvait préconiser d’héberger ses ressources sur plusieurs serveurs afin de mettre des tâches en parallèle afin de contourner cette limite. Notamment les images et fontes sur des CDN ou sous-domaines.

Ce protocole bridant les webperf globales, il était temps de trouver une alternative à ce protocole. C’est en 2015 que le labo d’études http working group dévoile le http/2. Ce labo dit s’être basé sur des recherches de Google et plus particulièrement le projet Speedy (SPDY).

Quels sont les avantages du http/2

Toute requête contient un en-tête, et celui-ci est généralement répété de nombreuses fois pendant les différents échanges de données. Il est certain que l’efficacité de ces échanges joue un rôle décisif dans les webperf. Le http/2 règle ce problème en réduisant la redondance et en compressant cet en-tête qui peut être bloquant pour le chargement des pages. Il renforce également la sécurité en s’assurant que le cookie n’a pas été modifié à des fins malicieuses. Et le contenu de la page a, lui aussi, profité d’une gestion plus sécurisée. Effectivement, le contenu était échangé en clair sur le protocole http/1.1, laissant une porte ouverte à de nombreuses failles de sécurité et menaçant la confidentialité des données échangées, avec le http/2 le contenu de la page transite aujourd’hui en binaire. Et en implémentant le Https, ces données binaires sont chiffrées afin d’apporter une couche supplémentaire de sécurité.

Ces améliorations sont les bienvenues, mais ce qui motive au passage en http/2, c’est surtout la possibilité de charger en parallèle un grand nombre de ressources. Car, en moyenne, 71 ressources sont chargées sur chaque page, on comprend donc bien que si l’on attend d’avoir chargé une ressource dans sa totalité avant de démarrer le chargement de la deuxième, les temps de chargement risquent de se trouver très allongés. À l’origine, le http/1.1 pouvait charger 2 à 3 ressources en parallèle, cette limite a été repoussées à 6 ressources pouvant être chargées à la fois. Le http/2 propose, lui, 1 seule connexion… mais multiplexée : plusieurs requêtes peuvent être gérées au sein de la même connexion. Il n’y a théoriquement pas de limite au nombre de ressources mises en parallèle, en tout cas, ce ne sera pas le protocole qui limitera le nombre de ressources chargées simultanément. Il faut également noter que dans certains cas, le http/2 n’est pas implémenté dans son intégralité et que certaines ressources restent chargées en http/1.1, on parle donc de taux de support du http/2. Dans ce cas, on peut tester quelles ressources sont chargées dans quel protocole et prendre des mesures afin de passer ce score à 100%.

Impact du http/2 en SEO

D’un point de vue purement SEO, le http/2 n’avait, il n’y a pas si longtemps, que peu d’avantages étant donné que le Googlebot ne le gérait pas jusqu’à novembre 2020. Un débat existait alors pour savoir si les données comportementales justifient un passage au nouveau protocole bien que Google n’en eût pas l’utilité. Et il pouvait même être contre-productif dans certains cas ou le site en question utilisait uniquement le http/2, car celui-ci pouvait alors rencontrer des problèmes évidents de crawl. Il faut noter que Google a annoncé qu’un site en http/2 ne ressentira aucun impact en termes de crawl.

Mais s’il y a un point où Google a toujours été clair et qui est de plus en plus présent dans la communication officielle, c’est qu’il faut avant toute chose, se préoccuper de vos utilisateurs. Et vos utilisateurs utilisent maintenant leur smartphone en priorité dans leur navigation. Et la navigation mobile a un inconvénient, l’instabilité de la connexion et possiblement un débit inférieur. Donc les webperf sont plus qu ‘importantes si vous voulez garder vos utilisateurs sur votre site.

La seconde communication importante en ce moment concerne les Core Web Vitals, et là aussi le http/2 à du sens, notamment pour l’optimisation du LCP (largest contentful paint). Car à moins d’optimiser tous vos templates pour charger l’élément le plus large le plus rapidement possible, le plus simple reste toujours d’avoir une page performante dans son intégralité. Cette performance sera, de toute manière, répercutée sur l’élément le plus large.

Faut-il adopter le http/2 ?

Il n’est probablement pas utile de vous rappeler l’importance d’avoir des performances solides sur votre site. Ce qui est certain, c’est que l’effort à fournir pour passer en http/2 est marginal comparé au gain en performances. 67% du web des ressources échangées sur le web se font en http/2, ce qui est relativement peu pour une technologie qui a déjà fait ses preuves depuis plusieurs années. Mais la question se pose tout de même, car il serait possiblement plus intéressant de passer en http/3 ?