Budgets de performance : la discipline dont votre application web a besoin

Votre application web ralentit. Vous ne le remarquez peut-être pas parce que ça arrive progressivement — un nouveau script d'analytics ici, une bibliothèque de composants plus lourde là, une image non optimisée que personne n'a signalée en revue. Chaque ajout est petit. L'effet cumulé est un site qui met 8 secondes à devenir interactif sur un téléphone moyen.

C'est comme ça que chaque site web lent est devenu lent. Pas par négligence, mais par l'absence d'un système qui dit « non » avant que les choses ne deviennent trop lourdes.

Ce système s'appelle un budget de performance.

Qu'est-ce qu'un budget de performance

Un budget de performance est un ensemble de limites quantitatives sur des métriques qui affectent l'expérience utilisateur. Si un changement pousserait une métrique au-delà de son budget, il n'est pas livré tant qu'il n'est pas optimisé.

Pourquoi la taille compte plus que la vitesse

Un développeur sur un MacBook Pro avec fibre voit votre bundle JavaScript de 2,5 Mo charger en 300ms. Un utilisateur à Cotonou sur une connexion 3G attendra 25 secondes pour le même bundle. Le serveur était aussi rapide dans les deux cas. La différence est entièrement dans ce que vous envoyez.

Amazon a trouvé que chaque 100ms de temps de chargement ajouté leur coûtait 1 % en ventes. Google a trouvé qu'un demi-seconde de délai dans les résultats de recherche causait une chute de 20 % du trafic.

La performance n'est pas une métrique technique. C'est une métrique business.

Comment fixer vos budgets

Étape 1 : Mesurez votre base

Utilisez Lighthouse, Web Vitals et WebPageTest.org. Testez sur une connexion limitée (simulez la 4G ou la 3G lente) et un appareil moyen.

Étape 2 : Comparez-vous aux concurrents

Vérifiez les performances de vos concurrents. Vous n'avez pas besoin d'être le plus rapide. Vous devez être assez rapide pour que la performance ne soit pas une raison de départ.

Étape 3 : Fixez des budgets atteignables mais stricts

Pas 10-20 % meilleurs que vos métriques actuelles. Atteignez-les. Puis resserrez.

Appliquer les budgets dans votre pipeline

Analyse de bundle au build

{
  "size-limit": [
    {
      "path": ".next/static/chunks/main-*.js",
      "limit": "100 KB"
    },
    {
      "path": ".next/static/chunks/pages/**/*.js",
      "limit": "50 KB"
    }
  ]
}

Lighthouse CI

Lancez Lighthouse en CI et faites échouer le build si les métriques régressent. C'est probablement la chose à plus fort impact que vous puissiez faire.

Monitoring utilisateur réel (RUM)

Les tests en labo mesurent le potentiel. Le RUM mesure la réalité. Utilisez la bibliothèque web-vitals pour collecter les Core Web Vitals des vrais utilisateurs.

Les tueurs de budget courants (et les correctifs)

Images non optimisées

Correctif : Utilisez next/image ou similaire. Servez du WebP/AVIF. Lazy-loadez les images hors écran.

Scripts tiers

Correctif : Auditez chaque script tiers. S'il n'apporte pas de valeur mesurable, supprimez-le. Pour les scripts essentiels, chargez-les de manière asynchrone.

Gonflement du bundle JavaScript

Correctif : Tree-shakez agressivement. Remplacez les bibliothèques lourdes par des alternatives légères.

Chargement des polices

Correctif : Utilisez font-display: swap. Réduisez les polices aux seuls caractères utilisés. Auto-hébergez les polices.

Commencez aujourd'hui

Ouvrez Lighthouse maintenant. Notez votre LCP, la taille totale du bundle et le poids total de la page. Fixez chacun comme votre budget. Ajoutez un check CI qui empêche ces chiffres de s'aggraver.

Ça ne rendra pas votre site plus rapide aujourd'hui, mais ça garantit que votre site ne sera pas plus lent demain. C'est la discipline qui manque à la plupart des équipes.