Carnet de notes

HTTP2 for front-end web deve­lo­pers

To get websites to load in an accep­table time using HTTP1 we have deve­lo­ped a series of tech­niques; hacks really; to eke perfor­mance out of this old proto­col. They are:

  • Spri­ting: taking multiple images, combi­ning them into one image, and using CSS to only show part of that image in a parti­cu­lar place.
  • Conca­te­na­ting: Taking multiple CSS or JS files and sticking them into one large file.
  • Serving assets from a cookie-less domain.
  • Shar­ding: crea­ting different domains or sub-domains to host assets like images.

Avec l’ar­ri­vée de HTTP 2, ces quatre opti­mi­sa­tions tendent à deve­nir inutiles, voire contre produc­tives.

Pour les deux premières, le pipe­li­ning devient plus intel­li­gent (donc réel­le­ment utili­sable) et au besoin le serveur peut pous­ser les conte­nus sans même attendre qu’ils soient deman­dés par le client.

Pour les deux suivantes, le système de compres­sion des entêtes et de multi­plexage rend le retour sur inves­tis­se­ment d’une nouvelle connexion TCP à un domaine tiers fran­che­ment contes­table. Vous risquez de perdre de la perfor­mance au lieu d’en gagner.

La leçon est inté­res­sante. Pendant quelques années les déve­lop­peurs ont cher­ché à contour­ner les navi­ga­teurs, croyant pouvoir être plus smart. Le problème c’est que les navi­ga­teurs et les proto­coles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des déve­lop­peurs peuvent désor­mais faire plus de mal que de bien. C’est toute une litté­ra­ture qu’il va falloir mettre à jour.

Publié

dans

par

Éric

Étiquettes :

Commentaires

6 réponses à “HTTP2 for front-end web deve­lo­pers”

  1. Avatar de Re
    Re

    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.

    Répondre
  2. Avatar de karl, La Grange
    karl, La Grange

    (Envoyé par email)

    J’ai dû mal comprendre la tournure, mais voyons: Cette partie c’est bon:

    Avec l’arrivée de HTTP 2, ces quatre optimisations
    tendent à devenir inutiles, voire contre
    productives.</blockquote

    ok, je te suis. Le point mineur est c'est utile pour les sites à haut trafic.

    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.

    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.

    Ici je te suis, HTTP2 permet d’éliminer en effet cela.

    Serving assets from a cookie-less domain.
    Sharding: creating different domains or
    sub-domains to host assets like images.

    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

    Là je ne comprends pas parce que

    old tech: Serving assets from a cookie-less domain.
    -> avec HTTP2, plus besoin de faire cela. Et donc une cnx en moins.

    old tech: Sharding: creating different domains or sub-domains to host assets like images.
    -> avec HTTP2, plus besoin de faire cela puisque justement le pipelining fonctionne mieux et permet d’optimiser le transfert des ressources. Donc justement pas besoin d’initier plein de cnx sur pleins de domaines. (coût en latence).

    Ou veux-tu dire que Ancien setup + HTTP2 va coûter en performance. Dans ce cas, je pense que la réponse est simple, do not fix if it’s not broken. Aka si HTTP/1.1 fonctionne bien avec le setup courant, continue. En revanche si vous passez à HTTP/2.0, il ne faut pas seulement changer le protocole mais également changer le setup. :)

    Répondre
  3. Avatar de karl, La Grange
    karl, La Grange

    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.

    À 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

    Répondre
  4. Avatar de Éric
    Éric

    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.

    Répondre
  5. Avatar de karl, La Grange
    karl, La Grange

    à 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 ;)

    Répondre
    1. Avatar de Éric
      Éric

      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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *