Il y a quelques jours je suis tombé sur l’article de Matt Wilcox, que j’avais trouvé intéressant, puisque nous comptions prochainement évoquer ce sujet ici même.
Matt – contacté sur Twitter – a gentiment accepté que nous traduisions ici son article!
L’article original : HTTP2 for front-end web developers (mars 2015)
HTTP 2 impliquera des changements dans la manière de concevoir un site web. Les bonnes pratiques du HTTP 1 peuvent être nuisibles dans un monde HTTP 2.
HTTP 1.x est lent et inefficace pour la majorité des cas d’utilisation sur le web d’aujourd’hui.
HTTP 1.x est la version de HTTP avec laquelle nous sommes tous familiers. C’est un vieux protocole conçu avant même qu’on sache ce que deviendrait le world wide web. Bien qu’il remplisse son rôle, il manque d’efficacité, car on lui en demande beaucoup plus aujourd’hui que ce pourquoi il a été conçu.
Pour combler les limitations de HTTP 1 et réussir à avoir des sites qui se chargent plus rapidement, une série de techniques s’est développée – des astuces ou hacks à proprement parler – pour donner un coup de boost à ce vieux protocole. Les voici :
- Spriting : prendre plusieurs images, les combiner en une seule image pour n’avoir qu’un seul fichier à télécharger. On utilise ensuite CSS pour n’afficher qu’une partie de cette image combinée, et obtenir un rendu identique à l’utilisateur de plusieurs fichiers.
- Concaténation: prendre plusieurs fichiers CSS (ou JS) et les regrouper dans un unique fichier.
- Sharding : créer différents domaines ou sous-domaines pour héberger les ressources comme les images par exemple.
- Fournir les ressources avec un domaine cookie-less.
Les deux premières techniques ont pour objectif de limiter le nombre de requêtes HTTP. Avec HTTP 1, une requête est une chose très coûteuse et prend beaucoup de temps (latence réseau). Il est plus rapide de regrouper les données pour les envoyer en une seule fois plutôt que de faire de nombreux aller retours pour récupérer les différentes ressources.
La troisième technique va accélérer la récupération des ressources (images, JS, CSS, etc).
En effet, le sharding s’est développé car la plupart des navigateurs ne permettaient initialement que 2 requêtes HTTP simultanées par domaine. Si vous créez un domaine dédié pour une partie de vos ressources, vous doublez alors le nombre de connexions simultanées que le navigateur utilisera pour aller chercher vos fichiers. Ainsi, vous pouvez télécharger les contenu du site web plus rapidement. En pratique, l’utilité du sharding est plus limitée car les éditeurs de navigateurs web ont peu a peu augmenté le seuil de 2 requêtes, mais il reste une limitation (ndtr: souvent entre 6 et 8).
Enfin la dernière technique permet de réduire le volume de données dans les requêtes, en limitant l’utilisation des cookies s’il y en a. En effet, par défaut un cookie est envoyé sur toutes les requêtes d’un même domaine, alors qu’il n’est pourtant que rarement nécessaire. Si vous isolez vos ressources sur un domaine dédié, les requêtes envoyées pour les récupérer n’utiliseront plus les cookies en question, qui sont uniquement nécessaires à votre domaine principal.
HTTP2 : Oubliez les bonnes pratiques instaurées pour combler les manques de HTTP1
Le HTTP2 est presque arrivé, il s’est appuyé sur SPDY, et rend tout beaucoup plus efficace. Cela veut également dire que toutes les bonnes pratiques évoquées plus tôt sont caduques voire nuisibles. Elles peuvent même rendre un site délivré en HTTP 2 plus lent, et non plus rapide – attention donc à la transition.
HTTP 2 diminue fortement le coût lié au nombre de requêtes (donc de ressources à aller récupérer), grâce à des optimisations intrinsèques au protocole.
- Il peut laisser la connexion réseau ouverte et permettre sa réutilisation sur de très longues périodes, on limite donc les coûts d’initialisation avec HTTP 1.
- HTTP2 utilise la compression (ndtr: sur les en-têtes), contrairement au HTTP1. Il y a donc un gain sur le volume de données qui vont transiter.
- HTTP2 est multiplexé: il permet d’envoyer et recevoir plusieurs ressources à la fois sur la même connexion.
Tout cela ne veut pas dire que les techniques HTTP 1 ne sont pas nécessaires, mais une partie d’entre elles peuvent rendre les choses plus lentes.
La concaténation et le spriting deviennent inutiles grâce au multiplexage, alors que ces techniques vous amènent souvent à charger des ressources inutiles sur la page courante de l’internaute (en faisant 1 seule sprite pour tout votre site par exemple).
Le sharding sollicite des résolutions DNS supplémentaires qui viennent à un coût, alors que le HTTP 2 élimine la nécessité du sharding avec le multiplexage. L’intérêt d’un domaine cookie-less est limité par la compression des en-têtes et donc des cookies.
En bref : pour le développement d’un site destiné à être délivré sur du HTTP 2, vous devrez changer vos habitudes et penser à oublier certaines techniques qui étaient destinées à pallier aux limitations propres à HTTP 1 !