Nous constatons de façon régulière des incompréhensions suite à une analyse de rapport de performance produit par Google PageSpeed Insight, GtMetrix, Pingdom ou encore Dareboost.

Ces incompréhensions viennent généralement de deux points :

1. beaucoup de recommendations sont devenues obsolètes pour les sites en HTTP/2
2. ces outils remontent des erreurs liées à des domaines tiers qui sont hors de contrôle du propriétaire du site.

Le passage en HTTP/2 change la donne.

Nous avons animé un talk du meetup Paris Webperf consacré au changement apporté par HTTP/2.

https://www.fasterize.com/fr/blog/meetup-webperf-http2/

Dareboost résume l'impact au niveau des recommendations :

• Sprites CSS, concaténation de fichiers CSS ou JS

Tout développeur front-end en aura entendu parler : regrouper les fichiers CSS, les fichiers JS, ou les images de faibles dimensions ensemble permet de limiter le nombre de requêtes HTTP et donc d’accélérer le chargement.

Ce qui était bénéfique en HTTP/1 risque au final d’aller à l’encontre d’une bonne expérience utilisateur en HTTP/2 : la connexion TCP est unique et multiplexée, en regroupant les fichiers, vous allez notamment perdre les bénéfices de priorité sur les différents flux !

A noter que les premiers retours d’expérience sur l’utilisation de HTTP/2 semblent montrer qu’il convient d’éviter malgré tout l’utilisation de micro-fichiers. Si c’est votre cas, appliquer partiellement le principe de concaténation peut rester intéressant !

• Domaines Cookie-less

Nous avons parlé plus tôt des en-têtes HTTP, qui se retrouvent répétés sur chaque requête en HTTP/1, ce qui peut être très problématique si le site utilise des cookies un tant soit peu volumineux. Une parade était d’utiliser un domaine dédié pour tous les contenus qui n’avaient pas besoin des informations transmises via les cookies. On éliminait ainsi simplement les données superflues.

Avec HTTP/2, d’une part le problème n’existe plus (en-têtes compressés) mais surtout, le hack du domaine cookie-less devient néfaste, puisqu’il implique inutilement l’utilisation d’une nouvelle connexion TCP et d’une résolution DNS supplémentaire !

• Domain Sharding

Autre “hack” HTTP/1, le domain sharding consiste à distribuer les ressources d’une page web sur plusieurs domaines, pour s’affranchir de la limitation de parallélisation des requêtes HTTP des navigateurs web. Cette limite étant associée au domaine, et non au serveur, on peut l’éviter en utilisant plusieurs domaines. Là encore, cela implique des connexions TCP et des résolutions DNS supplémentaires.

Là encore, HTTP/2 a résolu le problème initial, grâce au multiplexage cette fois !

• Inlining CSS, JS ou images en base64

Conseillé pour les fragments de CSS, de Javascript ou encore les petites images, l’inlining est une autre technique permettant de réduire le nombre de requêtes HTTP/1.

La nécessité de recourir à cette technique est moins évidente en HTTP/2, puisque l’impact de ces requêtes sera moins marqué grâce au multiplexage. Cette technique conserve les inconvénients déjà présents en HTTP/1, à savoir la perte des bienfaits du cache navigateur pour les ressources concernées, et l’on doit ajouter que cela peut aller à l’opposé des effets recherchés par la prioritisation des flux du multiplexage HTTP/2 !

On notera que l’inlining à des fins d’optimisation du chemin critique, pourra lui être éliminé au profit de l’utilisation du Server Push, même s’il faut garder à l’esprit que ce mécanisme reste relativement expérimental.

• Parallelize downloads across hostnames :

Cette optimisation n'est pas appliquée par le moteur en HTTP/2. L'indicateur n'est plus à prendre en compte dans ce cas.