Files
_Assistant_Lead_Tech/knowledge/frontend/risques/performance.md
MaksTinyWorkshop 72758c1adc capitalisation: intégration 33 propositions RL799_V2 (triage 2026-04-07)
Backend: 21 entrées (general, prisma, contracts, auth, patterns)
Frontend: 9 entrées (navigation, tests, general, performance, patterns)
Workflow: 5 entrées (story-tracking)
Nouveau fichier: backend/patterns/general.md
95_a_capitaliser.md purgé.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-07 15:44:36 +02:00

2.6 KiB

Frontend — Risques & vigilance : Performance

Extrait de la base de connaissance Lead_tech. Voir knowledge/frontend/risques/README.md pour l'index complet.


Performances : sur-renders + bundle non maîtrisé

Risques

  • App lente sur mobile
  • Bundle qui grossit sans contrôle
  • Chargements inutiles (images, libs)

Symptômes

  • Input lag
  • Temps de chargement qui dérive à chaque feature
  • Requêtes réseaux inutiles

Bonnes pratiques / mitigations

  • Lazy loading routes/features
  • Mesurer (au minimum) : temps de chargement + re-renders critiques
  • Politique images (formats, tailles, lazy)
  • Audit régulier des dépendances

useCallback inutile quand le callback est wrappé en inline au render

Risques

  • Le handler stable est re-wrappé dans une arrow inline lors du passage en prop → nouvelle référence à chaque render → React.memo ne peut pas éviter le re-render

Symptômes

const handleToggle = useCallback((id: string) => { ... }, []); // stable ✓

// Mais au render :
<ItemCard onToggle={() => handleToggle(item.id)} />
//                 ↑ nouvelle closure à chaque render → memo inutile

Bonnes pratiques / mitigations

  • useCallback n'a de valeur que si le callback est passé directement en prop, sans re-wrapping

  • Si la signature doit capturer des variables de boucle, deux options :

    1. Passer les données en props et laisser l'enfant appeler le handler avec ses propres props
    2. Accepter que memo ne soit pas protégé et supprimer le useCallback inutile
  • Ne pas laisser un useCallback "pour faire bien" si son effet réel est nul

  • Contexte technique : React — app-template-resto 22-03-2026


Fetch sans timeout pour ressources lourdes

Risques

  • fetch() sans timeout pour charger des blobs/fichiers volumineux (PDF, images) laisse l'utilisateur attendre indéfiniment sur connexion dégradée
  • Critique sur mobile avec connexion instable ; faux sentiment de freeze pour l'utilisateur

Symptômes

  • fetch(url) sans AbortController + timeout pour des blobs/fichiers volumineux
  • Spinner infini sans message d'erreur

Bonnes pratiques / mitigations

  • Utiliser AbortController avec setTimeout (15s recommandé)

  • Attraper AbortError et afficher un message explicite à l'utilisateur

  • Signal review : tout fetch de blob/fichier sans AbortController est suspect

  • Contexte technique : frontend / mobile — RL799_V2 06-04-2026