Se préparer pour HTTP2 : un guide pour les concepteurs et les développeurs Web

Le protocole de transfert hypertexte (HTTP) est le protocole qui régit la connexion entre votre serveur et les navigateurs des visiteurs de votre site Web. Pour la première fois depuis 1999, nous avons une nouvelle version de ce protocole , et il promet des sites Web beaucoup plus rapides pour tout le monde.

Dans cet article, nous examinerons les bases de HTTP2 telles qu'elles s'appliquent aux concepteurs et développeurs Web. J'expliquerai certaines des fonctionnalités clés du nouveau protocole , j'examinerai la compatibilité des navigateurs et des serveurs, et je détaillerai les éléments auxquels vous devrez peut-être réfléchir à mesure que nous verrons une plus grande adoption de HTTP2.

Pour en savoir plus sur Smashing :

• Préchargement : à quoi ça sert ?
• Tout ce que vous devez savoir sur AMP
• Améliorer les performances de Smashing Magazine

En lisant cet article, vous aurez un aperçu de ce qu'il faut envisager de changer dans votre flux de travail à court et à long terme. J'inclurai également de nombreuses ressources si vous souhaitez approfondir les problèmes soulevés. Mon objectif est de vous donner suffisamment d'informations pour pouvoir prendre de bonnes décisions lorsque vous planifiez votre passage à HTTP2.

Une brève histoire de HTTP

HTTP est un ancien protocole, initialement défini en 1991, avec la dernière révision majeure — HTTP/1.1 — publiée en 1999. Les sites Web de 1999 étaient très différents des sites Web que nous développons aujourd'hui. Dans http2 expliqué , Daniel Sternberg note que la quantité de données désormais requise pour charger la page d'accueil d'un site Web moyen est de 1,9 Mo, avec plus de 100 ressources individuelles nécessaires pour afficher une page - une "ressource" pouvant être une image ou une police. dans un fichier JavaScript ou CSS.

HTTP/1.1 ne fonctionne pas bien lors de la récupération du grand nombre de ressources nécessaires pour afficher un site Web moderne. Comme nous le verrons plus loin dans cet article, bon nombre des meilleures pratiques en matière de performances que nous connaissons en tant que développeurs Web proviennent de notre capacité à faire face aux limitations de HTTP/1.1.

SPDY

En 2009, deux ingénieurs de Google ont publié un article sur un projet de recherche sur lequel ils travaillaient nommé SPDY. Ce projet a résolu certains des problèmes de HTTP/1.1. SPDY s'est engagé à :

• autoriser les requêtes simultanées sur une seule connexion TCP, appelée multiplexage ;
• permettre aux navigateurs de hiérarchiser les actifs afin que les ressources vitales pour l'affichage d'une page puissent être envoyées par le serveur en premier ;
• compresser et réduire les en-têtes HTTP ;
• implémentez le push du serveur , par lequel un serveur peut pousser des ressources vitales vers le navigateur avant qu'on ne les lui demande.

De plus, SPDY nécessite une connexion cryptée (HTTPS) entre le navigateur et le serveur.

SPDY ne remplace pas HTTP ; il s'agit plutôt d'un tunnel pour le protocole et modifie la manière dont les requêtes et les réponses HTTP existantes sont envoyées. Il nécessite la prise en charge à la fois du serveur et du navigateur se connectant à ce serveur. Avec la prise en charge disponible dans NGINX et les packages disponibles auprès de Google pour activer la prise en charge dans Apache, il y a eu une adoption raisonnable de SPDY. La prise en charge des navigateurs est également assez bonne, avec les versions modernes de tous les principaux navigateurs qui la prennent en charge.

HTTP2

Nous avons vu SPDY connaître un certain succès, gagnant l'adoption avec les serveurs et les navigateurs. Cependant, vous avez peut-être également remarqué que, malgré la prise en charge d'Internet Explorer 11, le navigateur Edge de Microsoft l'a abandonné. Qu'est-ce qu'il se passe ici?

La prise en charge de SPDY a été abandonnée dans Edge en raison de la mise en œuvre par Microsoft de la prise en charge de HTTP2, la dernière version du protocole HTTP. Alors que d'autres navigateurs actuels maintiennent toujours la prise en charge de SPDY, Chrome supprimera la prise en charge en 2016, et d'autres navigateurs suivront probablement. Au moment de la rédaction, Edge, Firefox, Chrome et Opera prennent en charge SPDY et HTTP2. Safari, y compris sur iOS, rejoindra ce groupe plus tard cette année avec le lancement de Safari 9.

HTTP2 s'appuie sur le succès de SPDY, qui a été utilisé comme point de départ pour le nouveau protocole. Ainsi, la majorité des objectifs de SPDY sont atteints en HTTP/2. L'exigence d'une connexion HTTPS a été abandonnée. Cela dit, tous les fournisseurs de navigateurs ont décidé de n'implémenter HTTP2 que pour les connexions TLS (https). Ainsi, bien que vous puissiez potentiellement utiliser HTTP/2 avec du texte clair dans les communications de serveur à serveur, notre cas d'utilisation de HTTP2 aux navigateurs signifie que vous devez faire fonctionner votre site sur https avant même de penser à passer à HTTP2.

La spécification HTTP2 a été finalisée en février 2015 ; un an plus tard, la prise en charge des navigateurs dans les navigateurs modernes est excellente. Comme avec SPDY, HTTP2 nécessite une prise en charge au niveau du navigateur et du serveur, et il existe déjà de nombreuses implémentations de serveurs Web. Vous pouvez en garder une trace sur le wiki HTTP/2. W3Techs a également publié un article de juillet 2015 détaillant les taux d'adoption. L'adoption de ce protocole se déroule rapidement, compte tenu de sa relative nouveauté.

Devrons-nous changer nos sites Web ?

HTTP/2 est rétrocompatible avec HTTP/1.1 , il serait donc possible de l'ignorer complètement et tout continuera à fonctionner comme avant. Le changement de protocole est totalement transparent pour les utilisateurs. De nombreux lecteurs de cet article utiliseront un protocole autre que HTTP/1.1 depuis des années. Si vous avez un compte Gmail et que vous utilisez Chrome pour y accéder, vous aurez utilisé SPDY puis HTTP/2 sans rien savoir à ce sujet.

Cependant, de nombreuses choses que vous considérez comme des bonnes pratiques peuvent nuire aux performances sous HTTP/2. Au fil du temps, à mesure que de plus en plus de serveurs se mettent à jour pour utiliser HTTP/2 et que de plus en plus de personnes ont des navigateurs prenant en charge HTTP/2, votre site Web, à un moment donné bien optimisé selon les meilleures pratiques, commencera à sembler plus lent que les sites Web optimisés pour le nouveau protocole.

Que devons-nous changer pour adopter HTTP/2 ?

Dans le reste de cet article, nous examinerons certaines des meilleures pratiques courantes qui deviendront des anti-modèles à mesure que HTTP/2 sera adopté . Comme nous l'avons vu, la transition sera lente pour de nombreux sites Web. Pour passer à HTTP/2, votre logiciel serveur devra être mis à jour pour prendre en charge le protocole, ce qui peut être facile ou presque impossible selon la manière dont vous êtes hébergé.

Avant d'apporter des modifications à votre site Web spécifiquement pour HTTP/2, vous devrez également déterminer si vos visiteurs ont tendance à avoir des navigateurs qui le prennent en charge. Les propriétaires de sites Web qui attirent de nombreuses personnes utilisant des navigateurs très récents pourront effectuer ce changement plus tôt que les propriétaires dont les journaux affichent une majorité d'utilisateurs sur des navigateurs plus anciens. Pour refléter cela, je vais également vous donner quelques suggestions sur la façon de travailler pendant cette période de transition.

Passez au TLS

Pour de nombreux sites Web, la chose la plus difficile à propos du passage à HTTP/2 n'est peut-être pas du tout HTTP/2, mais plutôt l'obligation d'exécuter le site via une connexion sécurisée. Si vous développez un nouveau site ou mettez à jour un ancien, votre premier geste devrait être de vous assurer que vous lancez ou passez à https dès que possible. Ceci n'est pas seulement important pour HTTP/2, Google utilise des connexions sécurisées comme signal de classement, et les navigateurs commencent à signaler les sites Web non-https comme « non sécurisés ». À l'avenir, vous constaterez que certaines fonctionnalités HTML5 puissantes, telles que la géolocalisation, ne seront pas disponibles sans une connexion sécurisée.

Si vous avez un site qui est actuellement uniquement http, ma suggestion serait de donner la priorité à un passage à https d'abord, puis de décider de votre stratégie HTTP/2.

Transformer plusieurs fichiers image en sprites

Dans HTTP 1.1, récupérer une grande image est beaucoup plus efficace pour le navigateur que de faire beaucoup de requêtes pour les petites. Cela est dû au fait que plusieurs requêtes sont mises en file d'attente les unes derrière les autres. Pour contourner ce problème, on nous a conseillé de transformer nos petites icônes en un fichier sprite.

Le sprite résultant est renvoyé avec une requête HTTP, ce qui évite le problème de la mise en file d'attente de plusieurs requêtes. Cependant, même si le visiteur se trouve sur une page qui n'affiche qu'une seule de ces icônes, il devra toujours télécharger un fichier beaucoup plus volumineux que nécessaire pour voir cette image.

Avec la capacité de multiplexage de HTTP/2 , cette mise en file d'attente des ressources n'est plus un problème. Servir les petites images individuellement sera mieux dans de nombreux cas ; vous n'aurez qu'à fournir ce qui est requis pour la page sur laquelle se trouve le visiteur. La création d'un sprite sera toujours justifiée dans certains cas ; Les requêtes HTTP ne sont qu'un aspect des performances. La combinaison de certaines images dans un sprite peut permettre d'obtenir une meilleure compression et, par conséquent, une taille de téléchargement plus petite dans l'ensemble, surtout si toutes ces images sont utilisées sur la page en cours de chargement. Cependant, ce ne sera plus le cas qu'un sprite est toujours le meilleur choix.

Intégration d'images à l'aide d'URI de données

Une autre solution au problème des requêtes HTTP multiples dans HTTP/1.1 consiste à incorporer des images dans CSS à l'aide d'URI de données. L'incorporation d'images de cette manière rendra une feuille de style beaucoup plus grande. Si vous avez combiné cela avec une autre technique d'optimisation pour concaténer les ressources, un visiteur téléchargera probablement tout ce code même s'il ne visite jamais les pages où les images sont utilisées.

Les requêtes HTTP étant très bon marché en HTTP/2, cette « meilleure pratique » entravera plutôt que d'aider les performances.

Concaténer CSS et JavaScript

Lors de la dernière étape de notre processus de création, beaucoup d'entre nous concatèneront tous les petits fichiers CSS et JavaScript utilisés sur notre site Web. Nous souhaitons souvent les garder séparés lors du développement pour faciliter la gestion de ces ressources, mais nous savons que fournir un fichier au navigateur est plus efficace pour les performances que d'en fournir cinq. Encore une fois, nous essayons de limiter les requêtes HTTP.

Si vous faites cela, un visiteur qui atterrit sur votre page d'accueil peut télécharger tous les CSS et JavaScript requis pour votre site Web, même s'il n'en utilise jamais la majeure partie. En tant que développeur, vous pouvez contourner ce problème en sélectionnant et en incluant soigneusement des fichiers spécifiques pour chaque zone du site Web dans votre processus de création, mais cela peut représenter beaucoup de travail.

Un problème supplémentaire avec la concaténation est que tout devra être purgé du cache en même temps. Vous ne pouvez pas donner à certains fichiers qui ne changent jamais une longue date d'expiration tout en donnant à des parties souvent changeantes de la base de code une date plus courte. Tout doit être expiré si même une seule ligne de CSS, utilisée sur une seule page, est modifiée.

J'imagine que vous voyez où cela mène ! Les requêtes HTTP sont bon marché dans le monde de HTTP/2 . Organiser vos assets lors du développement en fonction des pages sur lesquelles ils seront utilisés sera bien meilleur. Vous pouvez alors ne servir que le code dont le visiteur a besoin. Le téléchargement d'un grand nombre de petites feuilles de style n'aura pas d'importance. Vous pouvez également vous organiser en fonction de la fréquence à laquelle les choses changent ; les actifs ayant une longévité pourraient alors être entretenus plus longtemps.

Fractionnement des ressources entre les hôtes : partitionnement

Avec HTTP/1.1, vous êtes limité au nombre de connexions ouvertes. Si le chargement d'un grand nombre de ressources est inévitable, une méthode pour contourner cette restriction consiste à les récupérer à partir de plusieurs domaines. C'est ce qu'on appelle le partage de domaine. Cela peut permettre d'obtenir de meilleurs temps de chargement, mais peut également causer des problèmes, sans parler des frais généraux de développement liés à la préparation de cela pour votre site Web.

HTTP/2 supprime ce besoin de partitionnement de domaine car vous pouvez demander autant de ressources que nécessaire. En fait, cette technique nuira probablement aux performances car elle crée des connexions TCP supplémentaires et empêche HTTP/2 de hiérarchiser les ressources.

Comment se préparer à HTTP/2 maintenant

Si vous démarrez un projet dont vous vous attendez à avoir une certaine longévité mais que vous ne pouvez pas lancer HTTP/2, peut-être en raison de la prise en charge du serveur, il serait utile de réfléchir à la manière dont vous pouvez vous préparer pour HTTP/2. Vous pouvez ajouter quelques éléments à votre processus de construction maintenant qui faciliteront le changement plus tard.

Créer des actifs individuels en plus des sprites et des URI de données

Si vous créez des sprites, ajoutez à votre processus la création et l'optimisation de ces ressources individuelles également, ou des sprites spécifiques à une page plus petits si vous pensez que les performances seraient mieux améliorées par ceux-ci. Cela vous permettra de passer plus facilement de gros sprites à de petits sprites (ou pas) lorsque le point de basculement de votre site Web sera atteint.

Il en va de même pour les URI de données. Si vous les utilisez actuellement dans votre CSS, préparez les images lorsque vous abandonnerez cette technique.

Organisez vos actifs par section de site Web

Avec la concaténation CSS et JavaScript, il est tentant d'optimiser pour faciliter le développement, car les fichiers seront de toute façon tous écrasés ensemble. Lorsque vous passez à HTTP/2, vous obtiendrez les meilleures performances en gérant soigneusement les ressources afin que seuls les éléments nécessaires à une certaine page soient livrés à cette page. Par conséquent, commencer à organiser votre développement de cette manière maintenant sera payant. Pour l'instant, vous pouvez toujours concaténer, et lorsque le point de basculement est atteint, vous pouvez arrêter cette partie de votre processus de construction et servir les ressources individuellement.

Gérer le partage de domaine

La meilleure pratique actuelle pour HTTP/1.1 consiste à limiter le partitionnement à deux noms d'hôte. Il existe un moyen d'obtenir HTTP/2 pour fusionner les connexions, si le certificat TLS est valide pour les deux hôtes et que les hôtes se résolvent sur la même adresse IP. Étant donné que les implémenteurs de navigateur exigent que HTTP/2 s'exécute sur HTTPS, il est nécessaire d'obtenir le certificat TLS pour qu'il s'exécute sur HTTP/2. Voir plus sur la diapositive 26 du diaporama d'Ilya Grigorik de la conférence Velocity.

Plus à venir

En fin de compte, nous aurons toute une série de bonnes pratiques pour HTTP/2. Pour de meilleures performances, ce protocole vous rendra beaucoup de contrôle, ce qui signifie que vous devrez prendre des décisions pour chaque projet. Je n'ai pas expliqué dans cet article comment tirer parti des nouvelles fonctionnalités de HTTP/2 telles que le serveur push. Cette technologie vous permet de décider quelles ressources sont prioritaires et demande au serveur de les distribuer avant les choses moins importantes.

Quand changer ?

Pour les concepteurs et les développeurs qui n'ont pas un contrôle total sur les serveurs sur lesquels ils déploient, la décision peut devoir attendre que les serveurs qu'ils utilisent soient mis à jour. Il existe déjà des sociétés d'hébergement proposant HTTP/2 - même pour l'hébergement partagé - donc le déploiement sur un serveur de support est quelque chose que vous pourriez recommander à un client si vous savez qu'il en bénéficierait.

Une fois que votre site Web est hébergé sur un serveur prenant en charge HTTP/2, la décision de continuer à optimiser pour HTTP/1.1 ou d'optimiser pour HTTP/2 dépendra du protocole pris en charge par la majorité de vos utilisateurs . N'oubliez pas que HTTP/2 est rétrocompatible - vous n'avez rien de spécifique à faire. La décision que vous devez prendre est de savoir quand l'optimiser.

Vous devrez décider en fonction de vos données d'analyse. Si plus de visiteurs utilisent des navigateurs prenant en charge HTTP/2 que non, je dirais que c'est un point de basculement raisonnable pour l'optimisation pour ces utilisateurs. Beaucoup d'entre nous auront déjà atteint ce point. Vous devez utiliser les données de sites tels que Can I Use ainsi que les données recueillies à partir de vos propres analyses et de la connaissance de votre public probable. Par exemple, bon nombre des avantages de HTTP/2 seront ressentis plus vivement par les utilisateurs d'appareils mobiles prenant en charge HTTP/2. Si vous avez un pourcentage élevé de trafic mobile, cela pourrait être une indication pour passer plus tôt à HTTP/2. Cependant, si vous avez un pourcentage élevé de trafic mobile provenant d'utilisateurs qui naviguent à l'aide d'Opera Mini, ce serait une raison de retarder le passage à HTTP/2 car il n'est actuellement pas pris en charge tout en ayant un nombre élevé d'utilisateurs dans certains parties du monde.

Si vous construisez un tout nouveau site Web aujourd'hui, je vous suggère de garder à l'esprit l'optimisation HTTP/2 tout au long de votre construction. Si au lancement, vous sentez que vous devez faire des concessions pour HTTP/1.1 en raison de la prise en charge du navigateur ou du serveur, une grande partie de cela peut être faite dans le processus de construction, vous permettant de passer à la version HTTP/2 dès que vous vous sentez le moment est venu.

Votre plan d'action HTTP/2

1. Lancez avec une connexion sécurisée ou passez à TLS maintenant Cela devrait être votre priorité.
2. Préparez-vous pour HTTP/2 dans votre processus de génération. Tout site Web que vous créez maintenant gagnerait probablement à être optimisé pour HTTP/2 au cours de sa durée de vie. Utilisez les conseils ci-dessus pour créer un processus de génération qui peut être optimisé pour les deux protocoles.
3. Vérifiez vos statistiques. En comparant l'utilisation du navigateur sur votre site Web avec le tableau de support sur Puis-je utiliser, vous pouvez voir quel pourcentage de visiteurs bénéficierait de l'optimisation HTTP/2.
4. Vérifiez votre hébergement. Lorsque vous atteignez le point où vous bénéficieriez du basculement, vous devrez vous assurer que votre serveur prend en charge HTTP/2. Parlez à votre fournisseur d'hébergement ou à votre administrateur de serveur pour connaître leur plan de migration.
5. Déployez l'optimisation HTTP/2. Une fois que votre serveur prend en charge HTTP/2, le reste dépend de vous. Arrêtez d'utiliser les anciennes meilleures pratiques et passez aux nouvelles. Cela signifie que les utilisateurs dont les navigateurs ne prennent pas en charge HTTP/2 auront une expérience plus lente, c'est pourquoi le pilote derrière votre changement devrait être le point de basculement lorsque la majorité en bénéficierait.

Lorsque vous passez à HTTP/2, il serait intéressant de comparer les augmentations de vitesse et de voir quelles techniques ont fait les plus grandes différences sur vos sites Web. J'ai hâte de voir des informations sur des cas réels à mesure que les gens migrent des sites Web. Ces informations nous aideront à développer une toute nouvelle génération de meilleures pratiques.

En savoir plus

De plus en plus d'informations sur HTTP/2 sont disponibles en ligne. J'ai répertorié quelques ressources ici pour votre référence, dont j'ai parlé pour la plupart lors de la rédaction de cet article.

• "Hypertext Transfer Protocol Version 2 (HTTP/2)" (spécification), Internet Engineering Task Force Ceci est destiné aux personnes qui aiment lire les spécifications ou qui ont besoin d'en comprendre les subtilités. Pour tous les autres, la FAQ HTTP/2 est un excellent résumé des principales fonctionnalités.
• http2 expliqué , Daniel Sternberg Cet ebook gratuit vaut la peine d'être lu si vous souhaitez approfondir les détails du protocole lors de la planification de votre stratégie.
• Réseaux de navigateur haute performance , Ilya Grigorik, O'Reilly Ce livre couvre à la fois les meilleures pratiques HTTP/1.1 et HTTP/2. Il serait utile à tous ceux qui souhaitent à la fois améliorer leurs performances aujourd'hui et préparer l'avenir.
• « HTTP/2 est là, optimisons » (diaporama) Ilya Grigorik Cet excellent ensemble de diapositives contient plus d'informations sur certains des points abordés dans cet article.
• Indicateur HTTP/2 : Firefox et Chrome Ce plug-in de navigateur vous indique si le site Web sur lequel vous vous trouvez est servi via HTTP/2.
• Pour plus de lecture, consultez cette énorme liste de liens organisée par Rebecca Murphey.