Introduction

En 1991, la première version documentée du protocole requête-réponse HTTP (HTTP 0.9) a été introduite. Depuis lors, le Web s'est considérablement développé et, 24 ans plus tard, la version la plus récente du protocole de transfert hypertexte (HTTP/2) a été publiée en 2015, introduisant une multitude d'avantages possibles pour les performances du site lorsqu'elle est correctement mise en œuvre.

Cet article s'adresse aux référenceurs souhaitant implémenter HTTP/2 dans le cadre de leurs initiatives d'optimisation de la vitesse des pages.

HTTP/2 est un sujet extrêmement riche qui pourrait être discuté en détail. Il existe une multitude d'informations en ligne sur HTTP/2 et ses avantages plus larges pour les utilisateurs finaux et les développeurs, mais avant de vous retrouver immergé dans la richesse des informations autour de HTTP/2, assurez-vous d'obtenir les informations dont vous avez besoin. Cela commence par se poser les bonnes questions :

1. Quel impact cela aura-t-il directement sur l'optimisation des moteurs de recherche et/ou la vitesse des pages ?
2. Une recommandation peut-elle être faite à partir de l'insight ?
3. La recommandation peut-elle être mise en œuvre de manière réaliste ?

Ces questions vous aident à vous demander « ce que je fais est-il efficace et précieux ? » et finalement vous mettre dans une meilleure position pour évaluer comment HTTP/2 peut aider à améliorer un site Web.

En raison de la nature étendue du sujet, il existe une grande quantité de connaissances autour de HTTP/2 qui n'est pas nécessaire pour essayer de comprendre l'importance du référencement. Le principal avantage de HTTP/2 pour le référencement est la vitesse de page.

Pour vous aider à naviguer dans la richesse des informations en ligne, voici une introduction à HTTP/2, décrivant l'évolution de HTTP 1.1 à Spdy compatible HTTP de Google et finalement à HTTP/2.

Comprendre comment le web a évolué permettra de mettre en évidence les améliorations qui lui ont été apportées suite à l'ajout du protocole HTTP/2.

Comment Google évalue-t-il la vitesse des pages ?

Pour voir comment Google évalue la vitesse de la page, ne cherchez pas plus loin que les rapports sur l'expérience utilisateur de Chrome . Ces rapports fournissent des mesures de l'expérience utilisateur sur la manière dont les utilisateurs utilisent les destinations populaires sur le Web. Ceci est alimenté à l'aide de mesures clés d'engagement des utilisateurs (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) et est également pris en charge via des outils communs tels que Page Speed ​​Insights, Public Google Big Query Project, Lighthouse et Web Page Test. L'utilisation de ces mesures et outils peut aider à apporter d'éventuelles améliorations autour de la vitesse de la page.

Introduction à HTTP/2

HTTP 1.1

En 2015, HTTP 1.1 était devenu obsolète. L'époque où les pages/sites Web étaient construits/s'appuyaient sur du HTML, du CSS et du JavaScript de base, ainsi que sur de nombreuses ressources et différents frameworks, était révolue. L'ère pré-2015 était basée sur l'idée que vous étiez limité à une demande par connexion TCP. Cela a conduit à des situations où les clients Web avaient plusieurs ressources en file d'attente pour le téléchargement, provoquant une congestion du réseau et des temps de chargement des pages lents.

HTTP/2 a été conçu pour cibler trois principaux domaines d'amélioration afin d'atténuer les problèmes évoqués ci-dessus :

• Simplicité
• Haute performance
• Robustesse

Avantages SEO pour HTTP/2

La vitesse de page est probablement la principale raison pour laquelle les référenceurs envisageraient d'implémenter HTTP/2 sur leurs propres sites Web ou sur ceux de leurs clients. Page Speed ​​/ Performance est un ensemble de mesures qui constituent un facteur de classement depuis 2010 pour les requêtes Desktop. En raison de l'augmentation de l'utilisation des appareils mobiles, en juillet 2018, Google a officiellement annoncé que Page Speed ​​deviendrait un facteur de classement pour Mobile.

HTTP/2 fournit 3 fonctionnalités principales qui peuvent être utilisées lors de l'optimisation des sites pour Page Speed :

1. Multiplexage
2. Poussée du serveur
3. Priorisation des flux

Multiplexage

Le multiplexage permet à un client Web d'inclure plusieurs requêtes dans une seule connexion TCP, ce qui réduit la charge du serveur et réduit la congestion du réseau.

Les clients Web modernes (Chrome, Firefox, Safari et Opera) utilisant les anciens protocoles HTTP 1/1.1 ont une limite par défaut sur le nombre de connexions TCP simultanées par nom d'hôte. Par conséquent, un client Web utilisant HTTP 1/1.1 peut facilement avoir des difficultés avec la congestion TCP. Avec les clients Web modernes, ce problème est résolu à l'aide du multiplexage, qui peut apporter certaines des améliorations les plus significatives à la vitesse de la page.

L'avantage du multiplexage est illustré ci-dessous en comparant HTTP/1.1 et HTTP/2, montrant le comportement typique lorsque le multiplexage HTTP/2 est et n'est pas activé.

( WebpageTest, HTTP/1.1, aucun multiplexage démontré )

( WebpageTest, HTTP/2, multiplexage démontré )

Dans les images ci-dessus, une cascade basée sur les performances est utilisée pour démontrer le chargement des ressources entre un utilisateur (qui demande les ressources) et le serveur (qui répond quelles ressources) d'une page Web. Généralement, les ressources de page incluent HTML, JavaScript, CSS et images. La cascade basée sur les performances montre le moment exact où une ressource spécifique est appelée, téléchargée et rendue dans le client, ce qui est essentiel pour découvrir, évaluer et analyser les problèmes de vitesse de page sur un site. Comme le montre l'image ci-dessus "HTTP/2", toutes les ressources commencent à se télécharger simultanément sans qu'aucune ressource ne commence à se charger à un point différent. Comme HTTP/2 utilise le multiplexage et ne repose plus sur l'envoi d'une seule requête sur une seule connexion TCP, plusieurs ressources peuvent être téléchargées en même temps, comme indiqué ci-dessus. En revanche, comme le montre l'image "HTTP/1.1", les ressources ne sont pas téléchargées simultanément car elles ne peuvent pas utiliser la fonctionnalité de multiplexage. Le navigateur moderne moyen sous HTTP/1.1 est capable d'avoir simultanément 6 connexions, mais l'avantage de la mise en œuvre de HTTP/2 est qu'une poignée de main TCP n'est pas nécessaire pour chaque requête alors que quel que soit le nombre de connexions pouvant s'exécuter simultanément avec HTTP/1.1 une première le processus de connexion doit être complété à chaque fois. Par conséquent, ils commencent à se télécharger à différents moments, ce qui entraîne un chargement de page plus long pour l'utilisateur.

( Diagramme Upwork HTTP/1.1 vs HTTP/2 )

Les robots de recherche tels que Google et Bing ne bénéficient pas directement de la mise en œuvre de HTTP/2. Comme décrit ci-dessus, le principal avantage de ces optimisations pourrait être la vitesse de page. Par conséquent, bien que la mise en œuvre de HTTP/2 n'affecte pas directement le robot de recherche, elle peut avoir un impact sur la vitesse de la page, qui est un facteur de classement direct pour les requêtes Google for Desktop depuis 2010 et les requêtes mobiles depuis juillet 2018. Par conséquent, il est essentiel que les sites Web ne fournissent pas une expérience lente pour les utilisateurs, car Google peut supprimer les performances en affectant les classements ou, plus récemment, en signalant aux utilisateurs que votre site peut être lent.

Poussée du serveur

Server Push permet au serveur ou au réseau périphérique spécifique d'envoyer des ressources aux clients Web lorsqu'elles n'ont pas été demandées par le client. Pour comprendre le fonctionnement du serveur push, il est tout d'abord important de comprendre le modèle demande-réponse suivi par un site Web. Un utilisateur demande une page à partir d'un site Web et le serveur répond avec le contenu/la ressource demandé(e).

Imaginez un site dont tous les styles sont définis dans une feuille de style externe appelée styles.css. Lorsque l'utilisateur demande le squelette HTML de la page (disons dans ce cas index.html), le push du serveur peut "pousser" le CSS à l'utilisateur juste après avoir commencé à envoyer la réponse à index.html.

( S mashing Magazine, Server Push )

Avant de comprendre comment Server Push peut aider à améliorer Page Speed, il est important de comprendre comment un navigateur fonctionne avec différentes ressources telles que les images, CSS et JavaScript pour apparaître dans votre navigateur. Vous voyez, le navigateur envoie des instructions sur la façon de télécharger des images, des ressources CSS et JavaScript. Lorsque vous visitez un site Web pour la première fois, vous effectuez généralement une requête GET, qui est le fichier .html. Une fois ce fichier .html reçu, le navigateur le parcourt pour le comprendre, puis peut effectuer des requêtes GET supplémentaires en fonction du contenu du fichier HTML.

Comment Server Push aide-t-il à améliorer la vitesse de la page ?

Grâce à l'utilisation de Server Push, le nombre de requêtes GET nécessaires à partir du navigateur (allers-retours) est réduit et les retards de rendu qui entraînent une augmentation des temps de chargement des pages sont évités. Cela peut considérablement améliorer le temps de rendu du client Web, ce qui permet à la page Web d'apparaître plus rapidement pour les utilisateurs, leur offrant ainsi une bien meilleure expérience.

Bien que Server Push n'ait pas d'impact direct sur la façon dont Googlebot explore votre site, ou même d'autres robots d'exploration, l'avantage SEO est obtenu grâce à des améliorations des facteurs centrés sur l'utilisateur tels que First Paint et First Meaningful Content.

À l'aide du test de page Web, de Lighthouse, de Page Speed ​​Insights et du rapport d'expérience utilisateur Chrome, vous pouvez déterminer les performances d'un site / d'une page par rapport à des concurrents au sein des mêmes secteurs. Ci-dessous, deux images illustrant l'implémentation sans (Image 1) et avec Server Push (Image 2).

(WebpageTest, sans Server Push)

(WebpageTest, HTTP/1.1, avec Server Push)

Avec le push du serveur, le serveur peut être configuré de sorte qu'il envoie toujours tous les composants de page supplémentaires (tels que les fichiers CSS, JavaScript et les images) s'il est invité à envoyer le fichier .html qui les contient.

Dans les cascades ci-dessus, nous pouvons voir que push.php utilise quatre fichiers CSS.

Sans serveur push, le navigateur doit recevoir le fichier push.php, analyser le code HTML, puis effectuer des requêtes spécifiques pour chaque fichier CSS supplémentaire. Ce n'est qu'une fois qu'il a reçu tous les fichiers CSS qu'il peut commencer à les utiliser dans le processus de rendu.

Lorsque le push du serveur est activé, la demande de push.php déclenche automatiquement l'envoi par le serveur des quatre fichiers CSS. Le navigateur les reçoit et peut commencer à les utiliser dans le processus de rendu beaucoup plus tôt. Cela signifie que le navigateur peut commencer à afficher le contenu de la page beaucoup plus tôt, ce qui se traduit par de meilleures mesures de vitesse de page.

Priorisation HTTP/2

La hiérarchisation HTTP/2 donne le contrôle de l'ordre dans lequel les ressources sont chargées, aux propriétaires du site. Effectuée correctement, la hiérarchisation profite à l'expérience utilisateur et à la vitesse de la page/du site en fournissant les ressources de la page dans un ordre optimisé, créant ainsi une expérience utilisateur "rapide".

Si nous regardons le prédécesseur de HTTP/2, HTTP/1.1, le client Web contrôlait l'ordre de chargement des ressources. Comme indiqué ci-dessus, cela était dû au fait que chaque connexion TCP ne pouvait prendre en charge qu'une seule ressource à la fois. C'est au navigateur de planifier les requêtes en décidant quelles ressources choisir et combien de connexions ouvrir en parallèle.

Avant d'entrer dans la façon dont cela se fait, il est important de comprendre pourquoi nous voudrions utiliser la hiérarchisation de nos ressources.

Si nous avons une image en haut d'une page et une image en bas de la page, nous voudrions logiquement nous assurer que l'image en haut se charge avant l'image en bas. Ce concept aide à démontrer l'importance et l'impact que peut apporter la hiérarchisation HTTP/2. La hiérarchisation HTTP/2 nous permet de spécifier quelles ressources doivent être livrées en premier et chargées avant les autres (qu'il s'agisse de JavaScript, de CSS ou d'images), garantissant ainsi le temps de chargement le plus rapide pour la page.

Alors que le navigateur peut désormais demander plusieurs ressources simultanément sur une seule connexion TCP en utilisant le multiplexage, il peut désormais également spécifier des informations de priorité avec chaque demande pour aider à déterminer quand/comment la ressource doit être livrée. Si le serveur et le navigateur prennent en charge la hiérarchisation HTTP/2, le navigateur doit définir les règles de hiérarchisation en utilisant toute la bande passante sans que les ressources ne se concurrencent. Afin de mieux comprendre le fonctionnement du processus de hiérarchisation, il est important de discuter de trois paramètres importants pour la hiérarchisation HTTP/2 :

Flux : il s'agit d'un flux bidirectionnel d'octets au sein d'une connexion établie qui peut transporter un ou plusieurs messages.

Flux parent : il s'agit d'un flux dont les ressources dépendent

Flux enfant : il s'agit d'un flux dépendant du flux parent. Ils partagent le même parent et sont donc connus sous le nom de flux enfant

Poids : Il s'agit d'un nombre attribué entre 1 et 256 qui identifie la quantité de bande passante à allouer au flux si plusieurs flux partagent une connexion. La bande passante est allouée par rapport aux poids de tous les autres flux actifs.

Bit exclusif : il s'agit d'un indicateur indiquant que le flux doit être téléchargé sans partager la bande passante avec d'autres flux.

Cadre d'en-tête : il s'agit de l'identification du flux auquel il appartient

Couche de cadrage binaire : c'est ainsi que les messages HTTP sont encapsulés et transférés entre le client et le serveur

Un exemple ci-dessous illustre un exemple de ce qui précède :

( Priorisation des flux HTTP/2 des développeurs Google )

Afin d'effectuer la hiérarchisation HTTP/2, vous devrez ajouter des informations de hiérarchisation dans le cadre d'en-tête situé dans la nouvelle couche de cadrage binaire HTTP/2. Le flux parent et la dépendance/non-dépendance vis-à-vis d'autres flux enfants détermineront la priorité/pondération et donc la livraison au client Web de la ressource.

Bien que la hiérarchisation HTTP/2 soit désormais prise en charge sur de nombreuses plates-formes, de nombreux CDN et fournisseurs d'hébergement ne prennent pas en charge la hiérarchisation HTTP/2. Il est donc important de vous assurer que vous utilisez un CDN/fournisseur d'hébergement qui prend en charge la hiérarchisation HTTP/2 si vous souhaitez utiliser cette technique d'optimisation. Vous trouverez ci-dessous un tableau décrivant les CDN/hébergements/serveurs capables et incapables de prendre en charge la hiérarchisation HTTP/2.

Priorisation HTTP/2 - Compatibilité commune serveur/hébergement/CDN

Cette comparaison était correcte le 01/02/2020 , mais il vaut la peine de vérifier si les fournisseurs de services potentiels ont amélioré leur compatibilité avant de prendre votre décision quant au choix.

Il est également important d'examiner de manière critique les navigateurs spécifiques car, malheureusement, tous les navigateurs ne prennent pas en charge la hiérarchisation HTTP/2 et hiérarchisent différemment en raison de leurs clients Web différents. Vous trouverez ci-dessous un tableau décrivant les clients Web capables de prendre en charge la hiérarchisation HTTP/2.

Compatibilité client Web avec hiérarchisation HTTP/2

La hiérarchisation HTTP/2 peut améliorer considérablement la perception qu'a l'utilisateur de la vitesse de la page/du site et aura un impact positif sur les données accumulées dans le rapport d'expérience utilisateur Chrome. Bien que cette optimisation n'ait aucun impact sur les robots de recherche tels que Googlebot, des outils tels que Lighthouse et Page Speed ​​Insights vous aideront à évaluer l'impact de la hiérarchisation HTTP/2 sur les performances de vitesse de page du point de vue de l'utilisateur.

En configurant correctement le poids du flux avec le serveur et le client à l'aide d'un CDN/hôte pris en charge par HTTP/2, vous serez en mesure d'améliorer considérablement vos mesures de vitesse de page pour votre client.

Quels sont les prérequis pour HTTP/2

Avant de pouvoir profiter des avantages de vitesse de HTTP/2, assurez-vous que vous êtes en mesure de l'utiliser. Quelques prérequis sont à prendre en compte :

1. Il est important de s'assurer que HTTPS est activé.
2. Utilisez un certificat TLS d'une autorité authentifiée et activez et installez le certificat.
3. Assurez-vous que votre logiciel de serveur Web tel que Nginx, Apache et IIS prend en charge HTTP/2. Une liste complète authentifiée pour le support peut être trouvée sur http://ayi.ma/browsershttp2 qui montrera le support du navigateur pour HTTP/2. Si vous recherchez une prise en charge HTTP/2 pour CDN/Hosting, veuillez vous référer à http://ayi.ma/serverhosting .

Pièges courants/choses qui doivent changer avec l'introduction de HTTP/2

En raison des limitations des protocoles HTTP 1.0 et HTTP 1.1 antérieurs, les développeurs et les référenceurs se sont efforcés de trouver des moyens de contourner la multitude de problèmes que ces limitations présentaient pour les performances et la sécurité de la vitesse des pages.

Finalement, ils ont pu trouver des "hacks" pour contourner certaines de ces limitations, mais bon nombre de ces méthodes ont causé encore plus de travail aux développeurs. Quels sont certains de ces hacks que vous pourriez demander ? Voici quelques-uns des hacks les plus courants que vous verrez sur les sites et qui peuvent être résolus grâce à la mise en œuvre correcte de HTTP/2.

Évitez le partage de domaine

Étonnamment, une multitude de sites utilisent encore ce hack bien qu'ils aient correctement implémenté HTTP/2. Lorsque HTTP/2 est activé, il sera important d'éviter d'utiliser le partage de domaine. Le partage de domaine est la technique de répartition des ressources entre différents noms d'hôte, permettant ainsi à davantage de ressources d'être servies simultanément.

Grâce au protocole HTTP/2 mis à jour, le partage de domaine n'est plus nécessaire et, en fait, cause plus de problèmes qu'il n'en résout. Si HTTP/2 est correctement configuré et activé pour votre site et que vous utilisez également le partage de domaine, vous annulez en fait certains des avantages de HTTP/2 puisque le navigateur ne pourra pas bénéficier du multiplexage et des téléchargements sur plusieurs noms d'hôte.

De plus, grâce au partage de domaine, vous cassez en fait la hiérarchisation des flux et vos ressources ne pourront pas être chargées pour tirer le meilleur parti de Page Speed.

Utiliser correctement Server Push

Server Push présente certains inconvénients dont vous devez être conscient. Server Push peut en fait être surutilisé et vous devez être sélectif lorsque vous choisissez quand l'utiliser. Vous ne voulez pas nécessairement pousser trop de ressources car cela pourrait amener le client Web à télécharger non seulement du HTML, mais tout ce avec quoi il est "poussé". Cela signifie que la page peut en fait prendre plus de temps à se charger et à s'afficher (augmentant les métriques centrées sur l'utilisateur sur lesquelles Google se concentre, telles que Time to Interactive).

Un deuxième écueil courant pour la poussée du serveur consiste à déterminer comment ne pas pousser les ressources que le client Web possède déjà. Cela peut être contrôlé par de nombreuses méthodes. Une méthode consiste à choisir de ne pas pousser les ressources vers les utilisateurs récurrents et donc de permettre aux utilisateurs récurrents d'utiliser leurs actifs mis en cache. C'est de loin la mise en œuvre la plus simple. Cela peut simplement être fait en vérifiant les en-têtes de cache pour les ressources en s'assurant que les en-têtes ne se chevauchent pas avec l'implémentation push du serveur.

Tests réels sous HTTP/2

Les connaissances théoriques sont toujours importantes pour jeter les bases de la compréhension de HTTP/2 et de ses avantages. Une fois les concepts saisis et compris, il est important de tester ces théories afin de mesurer l'impact que HTTP/2 peut avoir sur Page Speed.

La partie 2 de cette série Page Speed ​​HTTP/2 In Real Life - using Website Tests & Analysis discutera du véritable avantage de HTTP/2 en ce qui concerne la vitesse de page et la valeur pour le référencement, alors ne la manquez pas !

Qu'en est-il de HTTP/3 ?

Bien que HTTP/3 démontre un potentiel clair en tant que protocole successeur de HTTP/2, il ne signale pas et ne devrait pas signaler la fin de HTTP/2 pour le référencement sur le Web. Comme pour chaque nouveau développement majeur sur le Web mondial, il passera par une phase de déploiement normale et il faudra probablement du temps pour qu'un site adopte le nouveau protocole et avant qu'il ne devienne une norme de facto dans l'industrie du référencement. La mise en œuvre de HTTP/2 représente toujours un gain simple et bénéfique qui, lorsqu'il est correctement mis en œuvre, peut aider à améliorer les performances de votre site.