Push HTTP2 : push me for satisfaction
Désormais, le protocole HTTP2 est recommandé par tous les acteurs un peu sérieux de la web performance. Comme Benney Benassi qui le chante si bien : « Push me, And then just touch me, Till I can get my satisfaction ». Voyons voir si cette satisfaction est au rendez vous avec le server push HTTP2.
Server Push HTTP2
Il s’agit d’envoyer avec le contenu, dès la première réponse venant du serveur, les ressources fondamentales pour l’affichage de la page (les styles, les fonts, les scripts, …). Au lieu de devoir faire X aller-retours (roundtrip) pour les récupérer. Attention toutefois à ne pas tout envoyer ! L’idée est simplement de remplir l’espace libre du tuyau (la bande passante) créé pour la réponse initiale.
Il faut aussi apporter une petite précision. Le lexique n’est pas toujours clair sur ce qu’on peut trouver sur le web. Server Push et Notification Push sont deux choses différentes.
- Le premier accélère la récupération des ressources et est transparent pour l’internaute.
- Le second est un mécanisme de notification pour généralement prévenir l’internaute qu’un article a été publié ou qu’une mise à jour du site est disponible.
HTTP Preload
Lorsqu’on push une ressource, il est nécessaire de spécifier quel est son type, une feuille de style ? un script ? une font ? Dans le cas d’une feuille de style, celle-ci est à la réception, lue et interprétée directement comme si elle était contenue dans le code html. On peux ainsi remplacer la fameuse technique du inline critical path recommandée par Google. Et les rendus bloqués en l’attente de ces ressources ne le sont plus ! Vu comme ça, ça a l’air top.
Push mais pas cache
Là où ça devient problématique, c’est que le serveur n’est pas forcément au courant que le navigateur peut déjà avoir en cache les ressources à « pusher ». Le navigateur télécharge par défaut les push, même s’il possède les ressources en cache. Dans ce cas, le service worker peut nous aider à filtrer les push, mais ce n’est pas le sujet. Logiquement, on pourrait mettre en place un système côté serveur pour détecter si les ressources sont là et ne les envoyer qu’à la première connexion. On pourrait mais …
En cache, le rendu rebloque !
Donc si la ressource est présente dans le cache, on se dit qu’elle est interprétée quasi instantanément. Certainement plus rapidement que si les ressources étaient « pusher » par le serveur. Et bien non, car le navigateur doit interpréter la ressource en cache ! Même avec un service worker tel que présent sur ce site, il y a toujours un temps de chargement. Certes minime, mais il bloque le rendu de la page.
There is a solution ?
Alors vu que le inline critical path est un souci récurrent pour le rendu. Mais si les ressources bloquantes sont assez légères, on peut envisager de systématiser les headers link pour un petit poids de ressources. Très clairement, en dessous de quelques dizaines d’octets pas de soucis. L’idéal étant de pouvoir mesurer et d’ajuster les ressources pushées.
Enfin la technique qui consisterait à détecter coté serveur la présence des fichiers en cache, sera un gain quand, le navigateur lui même pourra « pusher » les ressources en cache. C’est ce qu’on nous promet avec le Navigation preload for service workers… à suivre donc.
Photo by Joshua Sortino on Unsplash
