Au fil des années et du développement toujours plus rapide d’internet, les limites du protocole HTTP 1.1 ont commencées à se faire sentir et elles sont devenus une réelle entrave à la performance des sites web. Ainsi, plusieurs techniques de contournement ou hacks sont apparus et sont mêmes devenus des « best-practices » pour certains.
Toutefois, avec l’arrivée de HTTP/2, ces techniques se révèlent parfois contre-productives. Petit tour d’horizon des pièges à éviter désormais.
Cet article fait partie de la série HTTP/2, contenant les articles suivant :
- HTTP/2 : introduction
- HTTP/2 : les détails
- HTTP/2 : les anciennes pratiques à éviter maintenant
- HTTP/2 : l’API HTTP Client de Java 11
- HTTP/2 : Push serveur
- HTTP/2 : Push serveur avec Java EE 8
Le domaine sharding
En moyenne, 108 ressources sont nécéssaires pour l’affichage complet d’une page web. le « Head-of-line blocking » en HTTP nous obligeant à charger ces ressources de manière séquentielle, une première solution consiste à ouvrir plusieurs connexions TCP.
Cependant, comme expliqué dans mon article précédent, le navigateur limite à 6 le nombre de connexions TCP ouvertes vers un même domaine.
Pour contourner cela, la technique du « domaine sharding » consiste à distribuer les ressources nécessaires à une page web sur plusieurs domaines.
On peut ainsi paralléliser un peu plus le chargement au prix de connexions TCP et de résolutions DNS supplémentaires.
HTTP/2 à la rescousse
Grâce à son multiplexage de flux, HTTP/2 permet de charger en parallèle toutes les ressources nécéssaires à une page via une unique connexion TCP.
Concaténation des fichiers CSS ou JS
En développement front-end actuellement on cherche toujours à regrouper tous les fichiers CSS ou JS ou voire même des images de faibles tailles en un seul fichier monolithique, afin d’éviter les multiples requêtes HTTP. Cette concaténation est même effectuée automatiquement lorsqu’on utilise des frameworks comme Angular ou React.
HTTP/2 à la rescousse
Encore une fois, grâce au multiplexage de flux, il n’y a plus aucune raison d’agir ainsi. Charger chacun des fichiers séparemment permettra de plus d’utiliser la priorisation des streams, de les mettre en cache et ainsi pouvoir les réutiliser pour d’autres pages.
Attention toutefois à ne pas tomber dans l’excès en créant des multitudes de micro-fichiers. Il convient d’appliquer cette pratique de manière raisonnée.
Domaine cookie-less
Certains cookies, notamment sur les sites marchands, peuvent devenir assez volumineux. Étant donné qu’ils sont automatiquement ajoutés à chacune des requêtes faites par le navigateur, ils vont de-facto réduire la bande passante disponible pour le reste des données.
Une technique répandue en HTTP 1.1 consiste à utiliser un autre domaine par la partie du site web qui n’utilise pas les cookies. Cela permet de ne pas avoir à transmettre de cookies pour des contenus n’en ayant pas besoin.
HTTP/2 à la rescousse
En éliminant les headers redondants et en les compressant, HTTP/2 réduit drastiquement la bande passante utilisée par ces derniers. L’intérêt du domaine « cookie-less » est donc beaucoup moins flagrant, d’autant plus qu’il implique une connexion TCP (et donc une autre table indexée => voir article précédent) et une résolution DNS supplémentaire.
Inlining de fichier
En HTTP 1.1, une méthode « d’optimisation » consiste à inclure directement dans la page HTML le code CSS/JS ou d’autres ressources comme des images en utilisant les balises appropriées. Exemple avec un pixel transparent :
Cela permet de « pousser » les ressources vers le client sans attendre qu’il les requête.
HTTP/2 à la rescousse
Le serveur Push HTTP/2 permet d’atteindre les mêmes objectifs mais en bénéficiant en plus de la possibilité de :
- Mise en cache dans le navigateur
- Réutiliser la ressource dans d’autres pages
- Transmettre le message de manière multiplexée
- Prioriser le stream
- Décliner le stream
Conclusion
Je trouve intéressant la manière dont les différents poins ci-dessus mettent en évidence la réelle volonté de l’IETF de venir faciliter le travail des développeurs avec son protocole HTTP/2. Celui-ci vient en effet apporter des alternatives à tous les principaux hacks utilisés avec HTTP 1.1. Cela va certes demander du travail pour faire machine arrière sur toutes ces pratiques très utilisées, mais le gain de simplicité que cela apporte devrait finir de convaincre même les plus sceptiques.
Le prochain article de cette série, détaille la nouvelle API HTTP Client de Java 11 qui propose entre autre un support d’HTTP/2 côté client.