Performance, accessibilité et tests

Performance, accessibilité et tests

1. Le、Web, est lent : mesurer avant d'optimiser

   Un site perçu comme lent est presque toujours un problème de chargement et de rendu, pas un problème de framework. Les métriques de terrain de la plateforme centrale, de reference pour le secteur, tiennent compte du poids total et du temps d'exécution : c'est ce que l'utilisateur perçoit, pas le nombre de millisecondes que le framework met à jour un composant.

   Les trois coûts qui paient vraiment

   1. le poids téléchargé : une application monopage livre généralement beaucoup de JavaScript. Chaque kilo-octet est un coût de téléchargement, de désérialisation et de compilation sur le fil du navigateur ;
   2. le coût du rendu initial : ce que l'utilisateur attend avant de voir le premier contenu utile ;
   3. les requêtes en cascade : une requête qui attend la réponse d'une autre est du temps d'inactivité du processeur. Les données nécessaires au premier écran se demandent simultanément, pas l'une après l'autre.

   Le levier le plus efficace, et le plus négligé

   Le découpage du code (code splitting) et le chargement différé des composants non visibles au premier écran. Une page qui affiche une liste n'a pas besoin du composant de détail d'un élément tant que l'utilisateur n'en a pas cliqué un. Les trois framework l'intègrent, et la négligence est l'erreur la plus courante : le premier écran attend un composant que personne ne voit.

   Images et polices, le coût invisible

   Sur un site institutionnel, les images et les polices pèsent souvent plus lourd que tout le reste du code. Elles ne relèvent pas du framework, et c'est précisément pourquoi elles sont souvent oubliées : optimiser React n'a aucun effet sur une photo de 2 Mo. Formats modernes, dimensions servies adaptées à l'affichage, et polices préchargées uniquement pour celles réellement utilisées.

2. Accessibilité : le test qui ne trompe pas

   L'accessibilité n'est pas une option. C'est une obligation légale dans l'Union européenne, et c'est surtout le meilleur test de la qualité réelle d'une interface.

   Les quatre principes, vérifiables

   1. Structure et sémantique : les titres décrivent la hiérarchie de la page, les zones de navigation et de contenu sont balisées correctement. Un titre de niveau élevé suivi d'un titre de niveau bas est une erreur de structure ;
   2. Contrôle au clavier : toute action possible à la souris doit l'être au clavier, et le focus doit être visible. Débrancher le focus est le défaut le plus grave : il rend le site inutilisable pour une partie des utilisateurs ;
   3. Contraste : texte et fond doivent atteindre le ratio requis. Un texte gris clair sur fond blanc passe les tests automatiques et reste illisible ;
   4. Alternatives textuelles : une image porteuse d'information a une description ; une image décorative est explicitement marquée comme telle, sinon un lecteur d'écran annoncera « image » sans rien dire de plus.

   Le test qu'un framework rend possible

   Sans accessibilité, une application monopage est navigation au clavier, donc inutilisable. Avec un framework, les composants produisent un balisage cohérent : une application bien écrite est accessible presque naturellement, parce que la structure du composant et la structure sémantique du document coïncident. C'est un vrai gain du modèle à composants, à condition de ne pas remplacer les balises par des conteneurs neutres sans raison.

   Ce qu'un test automatique ne voit pas

   Les outils automatiques détectent les erreurs mécaniques : attribut manquant, contraste insuffisant, libellé vide. Ils ne détectent rien à l'ordre de lecture des titres, à la pertinence des messages d'erreur, ni à la lisibilité réelle. Ces points se vérifient au clavier, sur la page rendue, par une personne qui ne voit pas l'écran.

3. Tester une interface, et ce qu'on teste vraiment

   Tester une application monopage ne signifie pas automatiser les clics. Cela signifie tester l'état, et laisser l'interface s'en déduire.

   L'inversion de la responsabilité

   Un composant pur se décrit par ses entrées et ses sorties : un état, plus des propriétés, donnent un rendu. On peut donc l'appeler sans navigateur, sans DOM, en quelques millisecondes. C'est ce qui rend le test unitaire possible là où il ne l'était pas avec un modèle centré sur la manipulation du DOM.

   La hiérarchie de tests à appliquer

   1. unitaire : un composant, un état, un rendu attendu. C'est la majority du volume, et c'est ce qui donne un retour rapide ;
   2. d'intégration : plusieurs composants ensemble, avec leur état partagé. C'est ici que se trouvent la plupart des bugs réels, parce que c'est là que les composants se parlent ;
   3. de bout en bout : quelques parcours critiques dans un vrai navigateur. peu nombreux, car ils sont lents et instables — et instables exactement quand on a le moins envie d'y toucher.

   Ce qui mérite d'être testé, et ce qui ne l'est pas

   • à tester : les règles métier, les cas limites, les erreurs réseau, les états de chargement et d'échec ;
   • à ne pas tester : le rendu exact d'un bouton, une classe CSS, le détail du texte d'un libellé. Ces tests cassent à chaque retouche graphique sans détecter de régression réelle, et ilscoutent plus cher qu'ils ne protègent.

   Le critère est simple : le test doit échouer quand le comportement change, et seulement dans ce cas. Un test qui échoue quand on change une couleur est un test à supprimer, pas à corriger.