Performance et accessibilité Shiny

Une application Shiny lente ou inaccessible perd ses utilisateurs avant même qu’ils ne voient votre travail. Cette série rend une application à la fois rapide et utilisable par tous : profilez avec profvis pour trouver le vrai goulot d’étranglement, mettez en cache avec bindCache, maîtrisez les saisies rapides et exécutez les traitements longs hors du processus principal — puis rendez-la accessible avec des champs étiquetés, ARIA, l’utilisation au clavier et un contraste suffisant.

Votre application fonctionne — mais un tableau de bord qui saccade à chaque déplacement du curseur, ou qu’un utilisateur au clavier ne peut pas parcourir, perd malgré tout la personne pour qui vous l’avez construit. La performance et l’accessibilité sont les deux choses qui décident si une application qui marche est vraiment utilisable : assez rapide pour paraître réactive, et ouverte à tous ceux qui en ont besoin. Cette courte série couvre les deux, une recette pratique à la fois.

Ni l’une ni l’autre ne relève de la devinette. On mesure avant d’optimiser — profvis vous montre le vrai goulot d’étranglement plutôt que celui que vous supposiez — et on teste l’accessibilité comme les utilisateurs la vivent : au clavier, avec un lecteur d’écran et avec un audit automatisé.

Le parcours

1. Rendez-la rapide — profilez, mettez en cache et passez à l’asynchrone : trouvez le goulot d’étranglement avec profvis, mettez en cache les traitements coûteux avec bindCache(), regroupez les saisies rapides avec debounce(), et exécutez les tâches longues hors du processus principal avec promises et future.
2. Rendez-la utilisable par tous — construisez une application accessible : des champs étiquetés, ARIA là où le HTML est insuffisant, l’utilisation au clavier, un contraste de couleurs suffisant, et des graphiques et tableaux accessibles — au niveau WCAG 2.1 AA.

Chaque leçon tient debout sur elle-même et se termine par un exercice exécutable — commencez par celle dont votre application a besoin en premier.

Pourquoi les deux comptent

Ce ne sont pas des préoccupations distinctes. Une application rapide et sans à-coups est plus facile à utiliser pour quelqu’un sur une technologie d’assistance ou un appareil lent ; une application accessible qui met dix secondes à répondre reste inutilisable. Les deux tiennent à la même discipline — mesurer le comportement réel, corriger ce que montrent les faits, et confirmer le résultat comme un utilisateur le vit réellement.

Si votre application…	Optez pour	Pourquoi
saccade, rame ou fige les autres utilisateurs	optimisation des performances	Profilez d’abord, puis mettez en cache / debounce / passez à l’asynchrone
doit passer un audit d’accessibilité (508, EAA, WCAG)	accessibilité	Étiquettes, ARIA, clavier, contraste — au niveau AA
va être présentée à de vrais utilisateurs, variés	les deux	Rapide et utilisable, c’est le seuil pour livrer

Note

La série performance est gratuite, comme le reste du cursus Shiny. Elle s’appuie sur les fondations gratuites, depuis zéro et la série architecture — structurez d’abord votre application, puis rendez-la rapide. Quand vous serez prêt à livrer, continuez avec le déploiement en production.

Cette page vous a-t-elle été utile ?

Prouvez que vous savez le faire. Maîtrisez toute la série Performance Shiny — suivez votre parcours, construisez des projets et obtenez un certificat.

Commencer gratuitement →

Passez à Pro — Prova illimité sur vos propres données et un certificat vérifiable qui atteste la compétence.

dès 15 $/mois facturé annuellement

Passer à Pro →

✓ Vous êtes Pro — continuez. The runtime is the judge.

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN