Publié depuis le blog technique d'Evaneos le 27 septembre 2019 en premier lieu
TL;DR Cet article rappelle quelques temps forts de #WeLoveSpeed 2019 (portant sur le sujet épineux des performances web) au travers des
retours d’expériences et propositions des conférencier·e·s.
André Gide dirait que choisir, c’est renoncer
Dès 9h, un bel accueil était réservé à tous les participants s’étant rendu le vendredi 20 septembre à la Cité des Échanges de Lille. La décision de se rendre à l’une ou l’autre session du programme était difficile à chaque embranchement mais les vidéos seront très bientôt publiées. Seront évoquées ci-dessous plus en détail les conférences auxquelles nous avons eu le plaisir d’assister. Le programme complet est disponible à partir du site officiel du cycle de conférences.
Réforme du numérique au Royaume-Uni
Un peu moins d’une demi-heure plus tard, on pouvait voir et entendre Estelle Weyl ainsi que Matt Hobbs présenter respectivement les coulisses du chargement au sein du navigateur ainsi que les raisons pour lesquelles les performances côté navigateur sont importantes.
Matt Hobbs s’est appuyé sur trois récits illustrant les défis rencontrés au sein d’un service d’administration britannique. Ce dernier sert plusieurs milliards de transactions chaque année.
Tout d’abord, il a attiré notre attention sur la nécessité de tester les services développés à partir d’appareils en accord avec la réalité des usages. Les appareils dernier cri sont présents mais il s’agit de composer avec la longue traîne des appareils de tous types et de toutes marques (ne pas les supporter revient à priver une partie de la population de l’accès à des services tels que la demande d’un nouveau passeport).
De manière similaire, les écarts de bande passante selon les régions sont à prendre compte afin de pas exclure une partie de la population dans leur accès aux services (voir directive européenne sur l’accessibilité des sites web et applications mobiles du secteur public).
Au Royaume-Uni, 8% des espaces intérieurs n’ont pas de couverture de données mobiles
De plus, de bonnes performances conduisent à moins de stress engendré chez les utilisateurs du fait d’une moindre concentration requise (on imagine l’accès interminable à un service de déclaration de revenus par exemple).
JavaScript responsable
Jeremy Wagner nous a exposé une collection d’idées et de techniques afin de servir du code JavaScript de manière responsable. Cette présentation repose sur une série de deux articles publiée sur le bien fameux blog A List Apart.
Dans un premier temps, Jeremy a mis l’accent sur le comportement quasi-systématique qu’on peut avoir dans notre métier en important des bibliothèques sans toujours en mesurer l’impact sur les performances.
La réinvention de solutions proposées par les navigateurs introduit selon lui une violation de responsabilité devenu trop courante dans notre métier. La personnalisation de comportements ou rendus de composants natifs nuit à de bonnes performances, sans même parler d’accessibilité ou de sémantique.
Par exemple, une balise HTML de type div utilisée pour un formulaire est une réinvention de la balise form qui ne permettra pas un comportement idéal en l’absence de JavaScript activé (pas de gestion de l’événement de soumission du formulaire modélisé).
C’est avec le principe de conception d’interface dit de cohérence externe qu’on entrerait ici en contradiction (voir notion d’External Consistency, tiré des Universal Principles of Design afin d’aller plus loin). En effet, on doit pouvoir s’attendre à des comportements déterminés face à des composants d’un type particulier (le bon fonctionnement des lecteurs d’écran a ce principe en clef de voûte).
Après avoir insisté sur le fait que les outils à notre disposition ne sont pas infaillibles, un exemple de configuration de Babel adapté à la fois aux navigateurs récents et à ceux qui le sont moins, nous a été offert sur un plateau. C’est la notion de Differential serving qui se cache derrière ce système de service sur mesure mieux adapté à la pluralité des navigateurs.
Les Client Hints ont été mentionnés en dernier lieu dans le cadre de la détection de la bande passante à disposition des visiteurs d’une application, en vue d’optimiser la taille des assets servis, tels que des images par exemple.
En parallèle, Romual Priol s’est exprimé à propos de la réconciliation entre performance et écologie.
Anthony Barré détaillant les optimisations possibles d’images —
CC - By https://
Compression efficace d’images
Après avoir révélé un exemple de réduction exceptionnelle de la taille d’images servies en production (jusqu’à 80% de réduction de taille),
Anthony Barré a décomposé pas à pas le processus permettant d’aboutir à une telle prouesse.
En s’appuyant sur un service d’optimisation d’images, il devient possible de déléguer :
- l’adaptation du format des assets selon les navigateurs et leurs supports des extensions disponibles (webp, jpeg, jpeg2000, png)
- le redimensionnement des images selon les tailles et résolutions des écrans à supporter
- l’adaptation à la qualité du réseau
La Network Information API et la négociation de contenu (du protocole HTTP), permettent de déduire les informations de contexte suffisants à prendre des décisions afin de répondre à chacun de ces points.
En plus d’une introduction à quelques algorithmes mis en oeuvre dans la compression d’image, une piste pouvant servir à automatiser ces optimisations a été founie au travers du projet SSIMULACRA.
Son usage peut contribuer à la détection automatique d’un trop grand crénelage d’une image après optimisation (on peut alors envisager une optimisation par lots guidée par la présence d’artefacts).
Gille Dubuc à propos du monstre RUM —
CC-By https://
Interprétation de mesures de performances réelles chez Wikimedia
C’est avec beaucoup d’humour dans ses représentations que Gille Dubuc a su nous tenir en haleine jusqu’à la pause déjeuner en présentant le monstre RUM (Real User Monitoring) sous toutes les coutures.
Au sein de l’équipe dédiée aux performances de Wikimedia, il a été confronté à la nécessité de sélectionner les données les plus pertinentes afin de se rapprocher au plus près de l’expérience des utilisateurs. Il faut noter qu’aucun service tiers n’a été utilisé en vue de simplifier les opérations de collecte, ou de traitement et ce en vue de préserver la confidentialité des données.
Différentes API de navigateur (en avant-première de leur mise à disposition) ont été mises à contribution :
Des conseils à propos de l’interprétation des données ont été diffusés tout au long de la session en même temps que certains constats avec notamment :
- la nécessité d’écarter les valeurs extrêmes afin de ne pas fausser la lecture des graphes
- la difficulté d’identifier les changements ayant eu un impact sur les performances
- la disparité des tendances d’usage des navigateurs selon les régions
- la difficulté de corréler la perception de performance (ressentie et communiqué au travers d’entretiens) avec les métriques relevées
- la nécessité de basculer d’une échelle de temps à une autre
- la nécessité de basculer d’une région géographique à une autre
Ryan Townsend à propos de l’impact des scripts tiers —
CC-By https://
Comment minimiser l’impact des scripts tiers ?
Sur une note un peu provocatrice (avec en première slide, une photo de policiers faisant barrage), Ryan Townsend nous explique en quoi les scripts tiers posent toujours problème aujourd’hui (8 ans après la première VelocityConf de 2011 où on nous invitait à se méfier des scripts à inclure sur son site).
Des graphes d’inclusion des scripts tiers mis en référence à partir de boutiques en ligne ont servi de point d’accroche tout au long de la discussion.
Les diagnostics et contre-mesures adoptées ont été obtenus via
- L’onglet des performances associé à chrome-devtools ainsi que
- l’outil en ligne disponible à l’URL https://
requestmap.webperf.tools tirant bénéfice de webpagetest.org
Un parti pris intéressant était de considérer que l’amélioration progressive d’une page peut également être appliquée dans la sélection des scripts tiers.
On doit pouvoir se passer de certains services en provenance de partenaires dans certaines situations, en cas de bande-passante insuffisante par exemple. À l’identique, pourquoi forcer le téléchargement d’une police si c’est au détriment de l’accès au contenu ? La directive CSS font-display: fallback peut constituer un bon compromis.
D’autres idées plus controversées ont été évoquées telles que l’auto-hébergement des scripts tiers avant de prévenir la négociation TLS, une “meilleure” priorisation permise par HTTP/2 ou encore la pose d’empreintes ou d’en-têtes de sécurité.
De manière plus modérée, il nous est possible de procéder à une sélection autrement plus éclairée des fournisseurs de ces scripts tiers en allant découvrir comment leurs qualités auront été évaluées par ceux qui les embarquent sur leurs sites.
On peut également demander des résolutions de noms de domaines par exemple anticipées avec prefetch. De manière plus générale l‘évolution des Resources Hints est à surveiller de près (preconnect et preload).
Raphaël Dardeau à propos de PWA et Performances —
CC-By https://
Progressive Web App et Performance
Raphaël Dardeau en tant que responsable des développements web à l’équipe a démontré avec beaucoup d’humilité comment :
- construire simplement un critère de qualification de la qualité du réseau à trois états (Lent, Moyen, Rapide) à partir de la Network Information API,
- identifier le niveau de compression à appliquer à des images de grande qualité afin qu’elle soit servies aux visiteurs dans des conditions de performance optimales
- prévenir la lecture automatique de vidéos a contrario en cas de bande passante insuffisante en proposant une solution de secours élégante (affichage d’une image de substitution)
Des recommandations supplémentaires concernant la directive font-display ont été suggérées avec une stratégie de sélection des valeurs les plus appropriées selon la connectivité détectée.
En conséquence de ces travaux d’optimisation (dont ceux portant sur la détection de la connectivité ne constituaient qu’une partie), le temps de chargement des images a été divisé par un facteur compris entre 2 et 3.
Antoine Kahn-Dubois à propos de la réduction de taille des bundles JS —
CC-By https://
Réduire la taille de Bundles JS avec Webpack ?
Antoine Kahn-Dubois a fait preuve d’une grande pédagogie en abordant le sujet délicat et très technique de la configuration de Webpack afin d’atteindre les résultats suivants :
- Code Splitting (regroupement des imports de modules par page) afin de ne pas importer plus de dépendances que nécessaire
- Choix des bibliothèques
- Bundle Splitting
Du code destiné à pouvoir s’exercer à chacune de ces étapes a été mis à disposition sous la forme d’un kata très détaillé.
On notera bien que la dernière étape de Bundle Splitting n’est véritablement applicable que dans une configuration où le support d’HTTP/2 serait garanti (du fait du grand nombre de requêtes HTTP à satisfaire). En effet, cette dernière étape abouti à un chunk téléchargeable par bibliothèque externe.
On tirera parti du cache navigateur afin d’obtenir de meilleurs résultats.
Le nom d’un chunk dépend directement de son contenu.
Parmi les références et outils évoqués, on peut retenir :
- https://
bundlephobia.com servant à sélectionner les packages aux tailles les plus avantages pour des fonctionnalités apportées similaires - Webpack Bundle Analyzer (https://
github.com/ webpack-contrib/ webpack-bundle-analyzer) générant des graphes de type treemap permettant de visualiser très rapidement quels paquets posent problème selon son budget performance fixé
Estelle Weyl opposant UX et DX avant de les réunir —
CC-By https://
{U,D}X
En conclusion de cette journée chargée, Estelle Weyl a pris le parti de rendre sa présentation plus accessible en la déroulant à la fois en français et en anglais. Les sujets sensibles, trop souvent mis de côté dans notre profession ont été passés en revue un à un en soutien de son argumentaire opposant UX et DX.
Performance, Accessibilité, Internationalisation, Sécurité, Confidentialité et Conception UX peuvent être supportés par les mêmes techniques d’ingénierie c’est-à-dire en recrutant des personnes compétentes disposant d’une sensibilité suffisante vis à vis de chacun de ces sujets. La diversité et l’inclusion font partie des clefs donnant accès à des solutions pérennes autour de chacun de ces axes.
Allouer du temps et de l’importance à ces sujets est un moyen efficace d’atteindre de nouvelles niches d’utilisateurs (d’accéder à de nouveaux marchés). De mauvaises performances peuvent être perçues comme le serait un handicap, ayant des conséquences réelles pour les utilisateurs.
Rendre possible la bidirectionnalité des contenus le plus tôt possible dans un contexte international fait partie de ces actions ayant d’autant plus d’impact sur le long terme qu’on les effectue tôt dans le cycle de vie d’une application à traduire.
À l’inverse de ce qu’on entend souvent, Estelle Weyl recommande de bien faire la première fois (quitte à prendre davantage de temps) car le refactoring n’est de toute façon pas rapide.
Ne nous laissons pas contrôler pas nos propres outils
Nicolas Hoffman dans le même temps à présenter la diminution du poids d’une interface d’un client mail via CSS / SVG.
Merci aux bénévoles, sponsors, participant·e·s et conférencier·e·s d’avoir contribué à la réussite de cet événement !
Représentation des échanges à propos de l’événement (Graphe biparti mots-clefs / noms d’utilisateur, produit avec gephi.org et github.com/digitalmethodsinitiative/dmi-tcat)