# Frontend — Risques & vigilance : Performance

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

---

<a id="risque-performances-sur-renders"></a>
## 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

---

<a id="risque-usecallback-inutile-inline"></a>
## `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

```tsx
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