To get websites to load in an acceptable time using HTTP1 we have developed a series of techniques; hacks really; to eke performance out of this old protocol. They are:
- Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
- Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
- Serving assets from a cookie-less domain.
- Sharding: creating different domains or sub-domains to host assets like images.
Avec l’arrivée de HTTP 2, ces quatre optimisations tendent à devenir inutiles, voire contre productives.
Pour les deux premières, le pipelining devient plus intelligent (donc réellement utilisable) et au besoin le serveur peut pousser les contenus sans même attendre qu’ils soient demandés par le client.
Pour les deux suivantes, le système de compression des entêtes et de multiplexage rend le retour sur investissement d’une nouvelle connexion TCP à un domaine tiers franchement contestable. Vous risquez de perdre de la performance au lieu d’en gagner.
La leçon est intéressante. Pendant quelques années les développeurs ont cherché à contourner les navigateurs, croyant pouvoir être plus smart. Le problème c’est que les navigateurs et les protocoles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des développeurs peuvent désormais faire plus de mal que de bien. C’est toute une littérature qu’il va falloir mettre à jour.
6 réponses à “HTTP2 for front-end web developers”
Je ne suis pas d’accord avec toi sur ton analyse à la fin. Pendant des années les développeurs ne se sont pas crus plus smart, ils ont simplement tenté de faire au mieux avec les restrictions imposées par les navigateurs et le protocole HTTP.
Certes le HTTP/2 va balayer toutes ces (anciennes) bonnes pratiques, mais ce protocole n’est pas pour tout de suite et il va falloir faire avec la version précédente encore un moment.
Firefox et Chrome savent parler HTTP/2, mais pas (encore) IE, Safari, et autres. De plus pour le moment ni Nginx ni Apache ne sait servir de HTTP/2.
Il va donc falloir, pour les développeurs, faire avec les deux mondes pendant un moment et continuer à mettre en place les pratiques qui sont inutiles en HTTP/2, mais ne posent aucun soucis (comme le Spriting et Concatenating) et trouver de bons compromis pour les pratiques contre-productives.
Le HTTP/2 est une bonne chose, mais la transition pose de nouveaux challenges aux développeurs.
(Envoyé par email)
J’ai dû mal comprendre la tournure, mais voyons: Cette partie c’est bon:
À mon avis HTTP/1.1 ne disparaîtra pas de si tôt. Et en effet, j’aurais tendance à penser que cela continuera pendant encore très très longtemps, si ce n’est toujours. On trouve des sites qui communiquent toujours en HTTP/1.1 et j’ai déjà vu HTTP/0.9
Afin d’être plus explicite :
* Je ne critique pas les avancées de HTTP 2
* Je ne critique pas le fait d’avoir contourné les problèmes de HTTP 1
Je note que les contournements passés peuvent se révéler négatifs s’ils sont laissés tels quels dans l’environnement à venir.
Il va donc falloir faire du tri dans toutes les ressources en ligne et filtrer. Ce ne sera pas forcément évident pour tout le monde et j’ai très bien en tête le nombre d’année qu’il a fallu à la communauté PHP pour que les développeurs ne se reposent plus sur les anciennes mauvaises pratiques qui étaient mises en avant dans les années 2000. Beaucoup d’évangélisation à prévoir.
Ensuite il y a ceux qui pourront faire de l’auto-détection et fournir une optimisation différente suivant la version de HTTP… et ceux qui ne le pourront pas et devront faire un choix de cible, sachant qu’ils handicaperont de fait une partie de leurs visiteurs.
La morale pour moi c’est surtout que quand on contourne des problèmes ou fait des optimisations dans l’espace utilisateur au lieu de les régler à la source, il faut assurer le suivi car ça peut se retourner contre nous à tout moment.
à noter que je ne suis pas un fan de HTTP/2.0.
Dans le sens où je pense que cela ne résoud que les problèmes des grosses compagnies à haut trafic, et n’apporte rien de significatif pour les sites individuels. Donc la critique de HTTP/2.0 est bienvenue ;)
Pour HTTP 2, je regrette le truc hyper complexe, surtout au niveau des entêtes. Je crains que les fonctions de push ne soient utilisées correctement que par 20 multinationales. Mais le multiplexage est une vraie avancée qui vaut le coût de tout le reste.
Pour une fois les implémentations suivent, donc je suis sur du positif.
Par contre, j’ai vraiment l’impression que ça va justement aussi aider tous les sites de petites boites et individuels. Ces sites n’ont justement généralement pas mis en place les solutions de contournement au HTTP 1 et sont vraiment lents avec un nombre de composants en explosion. Le tiens est une espèce en voie de disparition, pas représentatif à mon avis.
Pour les petits sites très léger comme le tiens, il n’y a quasiment aucun coût négatif de toutes façons.