Dans les articles précédents, nous avons beaucoup écrit sur les performances du site Web et la sécurisation de votre site Web, deux facteurs que Google a publiquement annoncés comme facteurs de classement de recherche. Ces articles fournissent des conseils détaillés utilisant les outils et technologies existants pour améliorer les performances et la sécurité de votre site (conseils que nous vous recommandons fortement de suivre). Mais saviez-vous que Google a également développé et défend un nouveau protocole de transport Web appelé SPDY qui résout de nombreux défauts de performance et de sécurité inhérents au Web aujourd’hui ?
Dans cet article, j’aborderai plus en détail le fonctionnement de ce nouveau protocole, pourquoi il est important pour vous et comment vous pouvez commencer à l’utiliser dès aujourd’hui.
De l’expérimentation à la norme
Google a créé le protocole SPDY dans le cadre d’une expérience pluriannuelle visant à trouver un moyen plus rapide pour le navigateur et les serveurs de communiquer. Les résultats ont été si positifs que l’IETF (Internet Engineering Task Force) utilise SPDY comme base pour HTTP/2, un remplacement du protocole réseau actuel qui alimente tout le trafic Web Internet aujourd’hui. Bien que techniquement HTTP/2 soit encore une spécification en évolution, de nombreux navigateurs Web, serveurs Web, périphériques réseau et sites Web prennent déjà en charge SPDY et HTTP/2 sous sa forme actuelle.
Bien qu’il existe quelques différences subtiles entre SPDY et HTTP/2, pour les besoins de cet article, il est prudent d’utiliser ces termes de manière interchangeable. Au fur et à mesure que HTTP/2 prend de l’importance dans le vocabulaire populaire, la langue vernaculaire SPDY tombera en désuétude au profit de HTTP/2. Pour cette raison, je ferai simplement référence à SPDY en tant que HTTP/2 pour le reste de cet article.
Quel problème HTTP/2 tente-t-il de résoudre ?
Pour comprendre pourquoi Google et l’IETF créent une nouvelle version de HTTP, nous devons comprendre les limites de performances fondamentales que nous avons aujourd’hui. Il est utile de considérer cette analogie :
Imaginez si toutes les routes du monde moderne avaient été construites à l’époque des calèches : étroites, cahoteuses et avec des limitations de vitesse réduites (c’est encore vrai dans certaines villes…). Bien sûr, il a fallu un certain temps pour aller n’importe où, mais le retard était principalement dû à la vitesse de votre cheval. Flash avant jusqu’à aujourd’hui : mêmes routes cahoteuses, mais maintenant tout le monde conduit une voiture. Maintenant, le cheval n’est pas le goulot d’étranglement, mais plutôt toutes ces voitures qui s’entassent sur la même route engorgée de rondins !
Croyez-le ou non, la plupart du trafic sur les sites Web d’aujourd’hui n’est pas loin de cette analogie. Le protocole HTTP d’origine remonte à près de 25 ans. La mise à jour la plus récente est HTTP/1.1 qui a été standardisée en 1999. C’est toute une vie dans le temps Internet !
Comme ces routes étroites et cahoteuses d’autrefois, le Web était à l’époque un endroit très différent : des pages Web plus petites, des connexions Internet plus lentes et un matériel de serveur limité. Dans un sens, le “cheval” était le goulot d’étranglement. HTTP/1.1 était vraiment un produit de cette époque.
Par exemple, lorsque le navigateur Web charge une page Web à l’aide de HTTP/1.1, il peut demander une ressource (comme une image, un fichier JavaScript, etc.) une à la fois, par connexion au serveur. Il ressemble à ceci :
Vous remarquerez que le navigateur passe beaucoup de temps à attendre chaque requête. Bien que HTTP/1.1 ne nous permette pas de faire plusieurs requêtes en même temps sur la même connexion, les navigateurs peuvent essayer d’accélérer les choses en établissant deux connexions au même serveur, comme indiqué dans le schéma ci-dessous :
L’utilisation de deux connexions est un peu meilleure, mais le navigateur passe encore beaucoup de temps à attendre pour obtenir un téléchargement. Et nous ne pouvons télécharger que deux ressources à la fois. Nous pourrions essayer d’établir plus de connexions pour télécharger plus de ressources en parallèle. Les navigateurs modernes essaient de le faire et peuvent établir entre 2 et 6 connexions par serveur. Malheureusement, cette approche reste médiocre, car chaque connexion elle-même est utilisée de manière si inefficace. Étant donné qu’une page Web moyenne compte plus de 100 ressources, le délai nécessaire pour effectuer toutes ces demandes individuelles une par une sur quelques connexions s’additionne et votre page se charge lentement.
Vous pouvez réellement voir cette inefficacité en regardant un graphique en cascade. Nous avons discuté des chutes d’eau dans un article précédent de Moz sur l’optimisation du temps jusqu’au premier octet, et nous avons également un guide détaillé sur la façon de lire les graphiques en cascade. La plupart des graphiques en cascade affichent de longues sections vertes qui représentent le temps que le navigateur attend pour télécharger une ressource. Tout ce temps perdu à attendre au lieu de télécharger est l’une des principales raisons pour lesquelles les sites Web se chargent lentement.
Cette attente inefficace sur les ressources est la raison pour laquelle des optimisations telles que la combinaison de fichiers JavaScript ou CSS peuvent aider votre site à se charger plus rapidement. Mais des optimisations comme celle-ci ne sont que des mesures palliatives. Bien que vous puissiez (et devriez) continuer à optimiser nos pages pour faire des requêtes moins nombreuses et plus petites, nous n’allons pas vraiment évoluer vers le prochain niveau de performance tant que nous n’aurons pas “réparé les routes” et amélioré la manière fondamentale dont le Web communique . Plus précisément, nous devons trouver une meilleure façon d’utiliser ces connexions réseau.
C’est là qu’intervient HTTP/2.
La solution : HTTP/2
À la base, HTTP/2 consiste à utiliser plus efficacement les connexions réseau sous-jacentes. HTTP/2 modifie la façon dont les requêtes et les réponses voyagent sur le réseau, une limitation clé dans les versions précédentes de HTTP.
HTTP/2 fonctionne en créant un
Célibataire connexion au serveur, puis “multiplexer” plusieurs demandes sur cette connexion pour recevoir plusieurs réponses en même temps. Il ressemble à ceci :
Le navigateur utilise une seule connexion, mais il ne demande plus les éléments un par un. Ici, nous voyons que le navigateur reçoit les en-têtes de réponse pour le fichier #3 (peut-être une image), puis il reçoit le corps de la réponse pour le fichier #1. Ensuite, il commence à obtenir le corps de la réponse pour le fichier #3, avant de continuer avec le fichier #2.
Pensez au multiplexage comme aller à l’épicerie et appeler votre conjoint une seule fois pour obtenir la liste complète :
“D’accord, nous avons besoin de lait, d’œufs et de beurre. Vérifiez.” Comparez cela à HTTP/1.1 qui revient à appeler votre conjoint encore et encore : “Avons-nous besoin de lait? D’accord, au revoir.” « Re-bonjour, est-ce qu’on a besoin d’œufs aussi ? Ouais, d’accord., “Ok désolé une dernière question, avons-nous aussi besoin de farine? Non, bien.”
Toutes ces données sont entrelacées beaucoup plus efficacement sur cette seule connexion. Le serveur peut fournir des données au navigateur dès qu’il est prêt. Il n’y a plus de boucle “faire une demande ; ne rien faire pendant l’attente ; télécharger la réponse”. Bien que légèrement plus complexe à comprendre, cette approche présente plusieurs avantages.
Tout d’abord, les connexions réseau ne restent pas inactives pendant que vous attendez qu’une seule ressource termine le téléchargement. Par exemple, au lieu d’attendre la fin du téléchargement d’une image avant de commencer la suivante, votre navigateur pourrait en fait terminer le téléchargement de l’image 2 avant même que l’image 1 ne soit terminée.
Cela empêche également ce que l’on appelle
tête de ligne blocage : lorsqu’une ressource volumineuse/lente (par exemple, une image d’arrière-plan de 1 Mo) bloque le téléchargement de toutes les autres ressources jusqu’à ce qu’elles soient terminées. Sous HTTP, les navigateurs ne téléchargent qu’une seule ressource à la fois par connexion. L’approche de multiplexage de HTTP/2 permet aux navigateurs de télécharger toutes ces autres images de 5 Ko en parallèle sur la même connexion et de les afficher dès qu’elles deviennent disponibles. C’est une bien meilleure expérience utilisateur.
Un autre grand avantage de HTTP/2 en termes de performances est la fonctionnalité “Server Push” : cela permet au serveur de transmettre de manière proactive du contenu à un visiteur sans qu’il le demande. Ainsi, par exemple, lorsqu’un navigateur visite votre site Web, votre serveur peut en fait “pousser” l’image de votre logo vers le navigateur avant même qu’il ne sache qu’il en a besoin. En poussant de manière proactive les ressources nécessaires à partir du serveur, le navigateur peut charger les pages beaucoup plus rapidement qu’auparavant.
Dernier point, mais non des moindres : HTTP/2 fonctionne mieux avec HTTPS. Comme nous l’avons mentionné précédemment, les deux performances
et la sécurité est une composante de plus en plus importante du classement de recherche. Alors que la spécification HTTP/2 permet techniquement une utilisation sur des connexions non HTTPS, l’ancien protocole SPDY de Google nécessitait HTTPS. Pour des raisons de compatibilité, la plupart des logiciels de serveur Web n’utiliseront HTTP/2 que sur une connexion HTTPS cryptée. Prendre le train en marche HTTPS protège non seulement la sécurité de vos utilisateurs et est bon pour votre classement de recherche, mais est également le moyen le plus efficace d’adopter HTTP/2. Pour plus d’informations, consultez notre article précédent sur l’activation de HTTPS.
L’avenir, aujourd’hui !
Il est donc clair que HTTP/2 offre de grands avantages en termes de vitesse et de performances, mais qu’est-ce que cela signifie pour vous en ce moment ? Eh bien, vous serez peut-être surpris d’apprendre que HTTP/2 est déjà disponible et que vous pouvez le prendre en charge sans affecter vos anciens utilisateurs fonctionnant sur HTTP/1.1.
Vous pouvez considérer HTTP/2 comme n’importe quel autre protocole, ou même comme une langue parlée. Pour que cela fonctionne, vous avez juste besoin d’un accord de l’expéditeur et du destinataire pour parler la même langue. Dans ce cas, “l’expéditeur” est le navigateur Web et le destinataire est votre serveur Web.
Prise en charge du navigateur
Puisqu’il est peu probable que vous créiez votre propre navigateur Web comme Microsoft, Google, Apple ou Mozilla, vous n’aurez pas à vous soucier du côté « expéditeur » de l’équation. La prise en charge de HTTP/2 dans le navigateur Web est déjà largement utilisée dans les navigateurs modernes d’aujourd’hui, l’adoption ne faisant qu’augmenter à mesure que les anciennes versions de navigateur vieillissent.
En fait, les dernières versions de tous les principaux navigateurs Web de bureau prennent déjà en charge HTTP/2. Chrome et Firefox le supportent depuis plusieurs années. Apple a ajouté la prise en charge de Safari à l’automne 2014 avec Safari 8. IE 11 prend en charge HTTP/2, mais uniquement si vous utilisez Windows 8.
De même, HTTP/2 est déjà largement adopté sur les téléphones intelligents. L’ancien navigateur Web d’Android, bien nommé
Navigateur, prend en charge HTTP/2 depuis plusieurs années. Le navigateur par défaut actuel pour Android est le navigateur Chrome de Google. Les versions mobiles de Chrome utilisent le même code réseau que Desktop Chrome. Cela signifie que Chrome sur les appareils Android, ainsi que Chrome sur les appareils iOS, prennent tous deux en charge HTTP/2. Apple a ajouté la prise en charge de la version iOS de Safari avec iOS 8.
Votre mieux est de regarder les analyses de votre site Web et de voir quels navigateurs Web vos visiteurs utilisent. Il y a de fortes chances que la majorité des visiteurs aient des navigateurs Web compatibles HTTP/2 (vous pouvez consulter cette liste de navigateurs de bureau et mobiles prenant en charge HTTP/2). Dans ce cas, vous pouvez passer à l’étape suivante en toute sécurité.
Prise en charge du serveur Web
Bien que vous ayez peu de contrôle sur les navigateurs utilisés par vos visiteurs, vous avez un contrôle direct sur votre serveur Web. En termes simples, pour prendre en charge HTTP/2, vous devez sélectionner un serveur Web prenant en charge HTTP/2 et l’activer. Et bien sûr, ce serveur devrait également continuer à prendre en charge HTTP/1.1 car vous
toujours ont des utilisateurs utilisant des navigateurs plus anciens.
Poursuivant notre analogie “langue parlée” d’avant, vous pouvez considérer HTTP/1.1 et HTTP/2 comme des langues différentes comme l’anglais ou le français. Tant que les deux parties peuvent parler la même langue, elles peuvent communiquer. Si votre serveur ne prend en charge que HTTP/1.1, les visiteurs ne peuvent lui parler qu’avec HTTP/1.1. Mais, si votre serveur prend également en charge HTTP/2, le navigateur de vos utilisateurs choisira également de parler (le plus rapide) HTTP/2. Et enfin, si votre serveur parle HTTP/2, mais pas le navigateur de vos utilisateurs, ils continueront à parler HTTP/1.1 comme avant, il n’y a donc aucun danger à “casser” vos anciens utilisateurs.
À l’heure actuelle, les serveurs Web Apache et nginx prennent en charge HTTP/2. nginx prend en charge HTTP/2 de manière native et Apache le prend en charge via le module mod_spdy. Étant donné qu’Apache et nginx servent le trafic pour 66 % de tous les serveurs Web actifs, il y a de fortes chances que le serveur de votre site Web puisse prendre en charge HTTP/2 dès maintenant.
Si vous n’utilisez pas nginx ou Apache, vous avez encore d’autres options. Il existe un certain nombre de projets plus petits et plus spécialisés qui prennent en charge HTTP/2. Vous pouvez également placer un proxy inverse prenant en charge HTTP/2 comme HAProxy devant votre serveur Web existant pour obtenir le même avantage qu’un serveur Web prenant directement en charge HTTP/2.
Si vous exécutez votre site via un fournisseur d’hébergement, vérifiez auprès de lui la version du serveur Web qu’il utilise. Les principaux sites comme WordPress.com et CloudFlare offrent tous déjà un support HTTP/2. Si votre fournisseur ne prend pas encore en charge HTTP/2, faites-lui savoir que c’est important !
Ajout du support HTTP/2
Comme je l’ai mentionné, HTTP/2 est simplement un autre langage que votre serveur Web peut utiliser pour communiquer. Tout comme une personne peut apprendre une nouvelle langue tout en se souvenant de sa langue maternelle, votre serveur Web continuera à savoir comment communiquer HTTP/1.1 après avoir ajouté la prise en charge de HTTP/2. Vous ne risquez pas d’empêcher quiconque de parler avec votre site. Les personnes utilisant des navigateurs plus récents communiqueront via HTTP/2, et
les anciens navigateurs continueront d’utiliser l’ancien HTTP/1.1 — rien ne s’arrête. Si vous avez le temps, il n’y a vraiment aucune raison de ne pas mettre à jour votre site pour prendre en charge HTTP/2.
N’oubliez pas que HTTP/2 est simplement un meilleur moyen de transmettre du contenu Web que HTTP/1.1. Tout le reste de votre site Web (les URL, votre balisage HTML, vos redirections ou pages 404, le contenu de votre page, etc.) reste le même. Cela rend l’ajout de la prise en charge de HTTP/2 assez simple :
- Assurez-vous que votre site Web utilise HTTPS. Consultez notre article précédent sur la mise en œuvre de HTTPS sans sacrifier les performances.
- Vérifiez que votre logiciel serveur ou votre infrastructure peut prendre en charge HTTP/2.
- Mettez à jour et configurez votre logiciel serveur ou votre infrastructure pour prendre en charge HTTP/2.
C’est ça. Votre site Web utilise maintenant HTTP/2.
Eh bien, j’espère que c’est le cas. Les étapes nécessaires pour mettre à jour/configurer votre site Web varient en fonction du logiciel que vous utilisez, nous ne pouvons donc pas vous fournir de guide détaillé. Cependant, nous avons créé un outil gratuit, SPDYCheck, que vous pouvez utiliser pour vérifier que vous avez correctement configuré votre site Web sur HTTP/2 (alias SPDY). SPDYCheck fonctionne comme une liste de contrôle, vérifiant chaque étape de la façon dont un navigateur négocie avec votre serveur pour communiquer via HTTP/2. Il peut vous dire où dans le processus les choses ne fonctionnent pas, et il fournit également des recommandations utiles comme l’activation de la sécurité de transport stricte. Avec SPDYCheck, vous pouvez être sûr que tout fonctionne correctement et vérifier que votre site prend en charge HTTP/2.
Conclusion
Nous savons tous que les sites plus rapides aident à améliorer le classement des moteurs de recherche, mais les sites plus rapides offrent également une meilleure expérience utilisateur. Les sites plus rapides engagent vos utilisateurs plus longtemps et favorisent le partage, le partage et la création de liens. HTTP/2 est un bond en avant incroyable qui peut aider à améliorer les performances et l’expérience utilisateur de votre site Web. Cependant, HTTP/2 n’est pas une solution miracle. Des optimisations telles que l’optimisation sans perte des images de votre site Web peuvent avoir un effet important sur les performances de votre site et seront toujours nécessaires. En bref, bien que vous deviez ajouter la prise en charge HTTP/2 à votre site Web, assurez-vous d’effectuer d’autres optimisations et de suivre les meilleures pratiques en matière de performances pour garantir la meilleure expérience utilisateur possible. Si vous cherchez un point de départ ou si vous voulez voir comment fonctionne votre site, le rapport de performance gratuit de Zoompf est un excellent moyen de comprendre ce que vous pouvez faire pour rendre votre site Web plus rapide.
