Mise à jour majeure : test HTTP/2 et autres nouveautés à venir

Toute notre équipe a le plaisir de dévoiler dès aujourd’hui les principales évolutions de ses nouvelles sondes de test, dont le déploiement est prévu a été effectué le lundi 19 septembre 2016.
Il s’agit là d’une mise à jour majeure, avec en vedette la prise en charge d’HTTP/2 (pour la mesure mais aussi nos recommandations), mais aussi le support des websockets, une gestion améliorée de la latence et du débit et encore bien d’autres évolutions…

Cela fait plusieurs mois que nous y travaillons : l’outil de test de performance de Dareboost va très bientôt être compatible avec HTTP/2, la nouvelle version du protocole de communication entre les navigateurs web et les sites internet. Pour rappel, bien qu’encore peu courant, HTTP/2 remplace peu à peu HTTP/1, et est déjà déployé sur certains sites majeurs, Facebook ou Wikipedia par exemple.

En matière de performance web, HTTP/2 marque vraiment un tournant. S’il reste encore assez peu utilisé par les sites internet, la plupart des navigateurs web sont déjà compatibles avec HTTP/2.
Alors évidemment, nous ne pouvions pas passer à côté !

Nous sommes très heureux de vous annoncer la sortie à venir de la nouvelle version de notre technologie de sonde de test, avec de nombreuses améliorations et nouveautés au programme : support de HTTP/2 donc, mais cela ne s’arrête pas là !

Cette nouvelle version sera déployée le 19 septembre prochain, nous vous tiendrons évidemment informés dès que nous disposerons d’une date plus précise.
Les changements sont nombreux, et vont affecter les résultats de performance mesurés par Dareboost. Voilà pourquoi nous vous proposons cet article très détaillé sur toutes les améliorations et changements à attendre, ainsi que leurs impacts, pour mieux vous permettre de les anticiper !

Si vous ne voulez pas rentrer dans les détails, vous pouvez vous rendre directement à la fin de cet article, où vous trouverez un résumé des points à noter.

Support du HTTP/2 pour les tests de performance, et checkpoints adaptés

La prochaine version sera non seulement pleinement compatible avec HTTP/2 pour les tests de performance, mais nous allons également adapter nos recommandations si nous détectons ce protocole.
En effet, nous vous en avions déjà parlé, avec HTTP/2 beaucoup de bonnes pratiques HTTP/1 deviennent inutiles, voire totalement contre-productive. Contrairement à la très grande majorité des outils d’analyse, vous ne verrez pas sur Dareboost de recommandation erronée avec HTTP/2.

A noter que plusieurs cas de figure se présentent concernant HTTP/2 et les impacts à attendre sur nos mesures. Il se peut en effet que votre site utilise intégralement ce protocole, ou seulement pour certaines ressources (par exemple si vous utilisez un CDN compatible), ou encore de façon très anecdotique (par exemple parce que vous utilisez le widget Facebook qui peut être délivré via HTTP/2).
Les impacts du support de HTTP/2 vont donc varier d’un site test à un autre. Dans tous les cas, Dareboost sera plus proche de la réalité de vos internautes.

Suppport des Websockets, de Brotli et de Quic

Ce sont exactement les mêmes contraintes que nous avons levées pour le support HTTP/2 qui nous empêchaient jusqu’à présent de supporter les websockets et le protocole Quic (notamment utilisé par Google Analytics).
Plusieurs d’entre vous attendaient les websockets depuis longtemps, car parfois obligés de blacklister des services externes pour ne pas fausser le temps de chargement total. Ce sera donc réglé d’ici quelques semaines !
Pour le protocole Quic, rien de très significatif à en attendre, car ce protocole est à notre connaissance exclusivement utilisé par plusieurs services Google, avec en conséquence des impacts très limités à attendre pour les résultats de vos sites sur Dareboost.

Brotli, un format de compression plus agressif que gzip, fait peu à peu son apparition. Dareboost non seulement le supportera, mais le prendra également en charge dans ses recommandations. A noter que cette mise à jour pourrait donc à ce niveau avoir un léger impact sur le poids de vos pages (les widgets Facebook là encore utilisent ce format).

Plus largement, le navigateur Chrome que nous utilisons sera mis à jour, pour passer à sa toute dernière version.

Abandon de Firefox

Cette refonte de notre socle technologique nous a amené à prendre une autre décision : celle de retirer le navigateur Firefox, proposé jusqu’à présent pour nos analyses Desktop. Les analyses avec l’option Firefox connaissaient déjà certaines limites (option AdBlock indisponible notamment). Ce retrait nous permettra d’être plus agiles dans le développement de notre outil de test.
Plus fondamentalement encore, le test de performance synthétique tel que nous le proposons, n’est généralement pas la méthode la plus appropriée pour se pencher sur des spécificités cross-browsers. A l’heure actuelle, l’approche du Real User Monitoring (ou monitoring passif) nous semble plus indiquée pour ce type d’exercice.
C’est donc pourquoi nous avons pris cette décision de nous recentrer sur Chrome, même si nous restons évidemment à l’écoute des actualités et évolutions des différents navigateurs du marché, notamment pour nos recommandations sur l’analyse.

Lors de cette mise à jour, Firefox sera donc retiré de notre parc, et toutes les surveillances qui l’utilisent seront automatiquement basculées sur le paramétrage équivalent avec Chrome.

Latence et gestion des débits plus réalistes

Nos sondes de test sont situées dans des datacenters, avec des conditions de connectivité bien plus favorables que celles d’un internaute. La gestion de la latence ainsi que la limitation de la bande passante est donc applicative sur nos sondes.
Cette gestion a été complètement repensée avec notre nouvelle version, s’appuyant sur des fonctionnalités natives de Chrome pour le débit, et sur des couches système pour la latence.
De gros changements à attendre pour les sites HTTPs sur laquelle l’impact de la latence était trop optimiste jusqu’à présent.
La limitation du débit est également plus réaliste et son impact sera mieux distribué sur les requêtes impactées. Sur ce point, c’est essentiellement l’aspect de votre timeline/waterfall qui se verra modifié, les impacts sur les mesures finales restant négligeables d’après nos tests.

Le contexte exposé en Javascript est plus cohérent

Vous l’avez sans doute compris à ce stade, notre nouveau socle technologique s’appuie plus que jamais sur les fonctionnalités exposées par les navigateurs web.
Une autre limitation de Dareboost est levée par ce biais : le contexte exposé en Javascript est maintenant cohérent avec les paramètres avancés de l’analyse.
Jusqu’à présent les propriétés telles que la chaîne du User Agent, le screenWidth/screenHeight ou encore de Device Pixel Ratio accessibles en Javascript restaient ceux par défaut de nos sondes de test, quelques soient les options avancées utilisées pour l’analyse.
Ce problème est résolu, ce qui permettra de meilleurs résultats sur les sites se basant sur ces éléments pour offrir des comportements variables.

Le validateur CSS W3C disparaît

Les normes sont importantes loin de nous l’idée de dire le contraire. Mais à une période où les technologies web évoluent à une vitesse folle, ce validateur est trop souvent source de bruit pour nos utilisateurs. Nous avons donc préféré l’abandonner, pour privilégier de nouvelles fonctionnalités en lien avec l’apparition de HTTP/2.

Temps de chargement total, meilleure détection pour la fin des analyses

Nous basons la mesure du temps de chargement total sur la détection de la fin du trafic réseau. Notre nouvelle sonde sera à même d’apporter davantage de robustesse sur ce mécanisme, en s’assurant avant d’interrompre le test, que l’événement onload a bien été déclenché.
Jusqu’à présent, il pouvait y avoir un léger décalage entre le démarrage de l’analyse et le départ de la première requête. C’est un comportement normal du navigateur, qui se présente également pour un internaute lambda, mais nous avons absorbé ce décalage, pour une lecture simplifiée des informations détaillées de nos rapports, et également car ce décalage était variable
Enfin, la timeline évolue pour faire apparaître les redirections internes aux navigateurs, auparavant masquées. Les redirections internes peuvent par exemple être liées à l’utilisation de la directive CSP upgrade-unsecure-requests que nous avions évoquée dans notre article sur le Mixed Content.

Evolution mineure de l’API

Si vous utilisez notre API sans activer les visualMetrics (speedindex, etc.), vous ne diqu’sposerez plus de la capture d’écran réalisée pendant l’analyse. Nous en profitons pour vous rappeler que la documentation complète de l’API est disponible ici et que nous avons mis en place récemment un changelog.

Conclusion

Cette évolution de Dareboost est sans doute l’une des plus importantes depuis le lancement de notre service, même si contrairement à nos autres mises à jour, la plupart de ces changements ne seront pas visibles au premier abord !
Nous franchissons un cap en prenant en charge ce qui constitue le web de demain, et avons tout mis en place pour gagner encore en agilité et vous offrir un service toujours plus complet.
D’autres mises à jour arriveront prochainement, avec une nouvelle timeline, des alertes intelligentes sur la surveillance automatique, ou encore des bonnes pratiques dans nos analyses dédiées à HTTP/2. N’hésitez pas à vous inscrire à notre Newsletter pour ne rien manquer des prochaines mises à jour.

Voici pour finir un récapitulatif des changements annoncés, qui seront mis en place le 19 septembre :

  • Support du HTTP/2, des Websockets, de Quic et de Brotli
  • Conseils de nos rapports adaptés à HTTP/2
  • Abandon de Firefox. Passage de Chrome sur la dernière version.
  • Gestion de la latence et des débits plus réaliste
  • Contexte Javascript plus cohérent (screenWidth, UA, DPR)
  • Le validateur CSS W3C disparaît
  • Temps de chargement total : borne mini. au onload
  • Affichage des Internal Redirects
  • Evolution mineure de l’API