Skip to main content

WeLoveSpeed 2019 à Lille 🕾🚅


TL;DR Cet article rappelle quelques temps forts de 2019 (portant sur le sujet épineux des performances web) au travers des 
retours d’expĂ©riences et propositions des confĂ©rencier·e·s.

Logo de We Love Speed

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).

Paint the picture, not the frame

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://twitter.com/0gust1

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://twitter.com/0gust1

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://twitter.com/0gust1

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

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://twitter.com/0gust1

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://twitter.com/0gust1

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 :



Estelle Weyl opposant UX et DX avant de les rĂ©unir — 
CC-By
https://twitter.com/0gust1

{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.

Cet article a été publié depuis le blog technique d'Evaneos le 27 septembre 2019 en premier lieu.


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)

 

Merci à Fabien Huitelec pour la relecture de cet article