Fixez le budget de performance avant la conception, pas après les plaintes

Presque toutes les équipes disent que la performance compte. Et presque toutes la planifient comme une phase proche de la fin, où elle entre en concurrence avec la livraison et perd.

Les équipes qui finissent avec des produits rapides font autre chose, et ce n’est pas de l’optimisation héroïque. Elles décident de ce que signifie « assez rapide » avant que quiconque ouvre un outil de design, puis traitent ce nombre comme la matrice des navigateurs supportés : une contrainte, pas un objectif.

Pourquoi « on optimisera plus tard » échoue

Trois raisons, et c’est la troisième qui vous met à terre.

1. Rien n’impose l’arbitrage. Prise isolément, chaque fonctionnalité vaut son coût. Sans budget, rien ne dit jamais non, et la somme est lente.
2. Les correctifs bon marché s’épuisent. Compression, cache et formats d’image vous achètent une quantité fixe et modeste. Ensuite vous entrez dans l’architecture.
3. Les causes coûteuses sont architecturales. Une couche de données qui sur-récupère, un rendu bloqué par le réseau, un script tiers dans le chemin critique. Cela se décide tôt et coûte énormément à défaire tard.

Le temps que vous puissiez mesurer, les décisions qui ont déterminé le résultat ont plusieurs mois.

À quoi ressemble un budget

Un budget, ce sont quelques limites précises qu’une construction peut respecter ou non. Les nôtres pour la recherche de KoiSpeak, à titre d’exemple :

Deux propriétés rendent un budget réel plutôt que décoratif :

• C’est un nombre, pas un adjectif. « Rapide » ne peut pas faire échouer une construction. 150 ms, si.
• Il est mesuré sur un appareil que vos utilisateurs possèdent. Un budget mesuré sur le portable du développeur via le Wi-Fi du bureau ne mesure rien.

Testez sur le matériel qui existe vraiment

C’est là que la plupart des travaux de performance déraillent avant même de commencer.

Le développement se fait sur des machines rapides et des connexions rapides. Vos utilisateurs sont sur des téléphones Android de milieu de gamme vieux de quelques années, en données mobiles, avec une douzaine d’applications en arrière-plan. L’écart entre ces deux expériences n’est pas de 20 %. Sur les traitements limités par le processeur, il est couramment de 5 à 10 fois.

Minimums pratiques :

• Gardez un vrai appareil de milieu de gamme sur le bureau et utilisez-le chaque semaine.
• Activez la limitation du processeur dans les outils de développement par défaut, pas comme un exercice exceptionnel.
• Collectez des données de terrain issues de vraies sessions, pas seulement des chiffres de laboratoire. Le laboratoire dit ce qui a changé ; le terrain dit ce que les utilisateurs ont réellement reçu.

Comment un budget change les décisions

La valeur n’est pas dans la mesure. Elle est dans les débats qu’il tranche tôt et à bas coût, avant que quoi que ce soit ne soit construit.

• Une famille de polices devient un coût. Quatre graisses et deux familles représentent une part réelle d’un budget mobile. Vous choisissez deux graisses, au moment de la conception, sans drame.
• Une bibliothèque d’animation doit se justifier face au CSS que vous écririez de toute façon.
• L’analytique et les widgets de chat sont comptabilisés. Les scripts tiers sont souvent le poste le plus lourd, et personne ne le remarque parce que personne dans l’équipe ne les a écrits.
• La forme des données suit le budget. Si le premier résultat doit arriver en 150 ms, vous ne pouvez pas charger une grosse charge utile et filtrer côté client. Cela vous pousse vers un index de préfixes, qui était de toute façon la bonne réponse.

Ce dernier point est le motif récurrent. Un budget ne vous ralentit pas ; il rend la bonne architecture évidente plus tôt.

Le travail de performance fait après le lancement est une opération de sauvetage. La performance traitée comme une contrainte dès le départ n’est que de la conception.

Le faire respecter sans cérémonie

Un budget que personne ne vérifie est un vœu. Gardez l’application bon marché :

• Faites échouer la construction sur la taille du bundle. Une ligne de configuration d’intégration continue, qui attrape l’essentiel des régressions et ne coûte rien à maintenir.
• Lancez un audit synthétique par pull request sur les deux ou trois routes qui comptent le plus.
• Alertez sur les métriques de terrain chaque semaine, pas à chaque commit. Les données réelles sont bruitées ; regardez les tendances.
• Revoyez le budget quand le produit change. Un budget n’est pas sacré. Le relever délibérément, avec une raison, est acceptable. Le dépasser en silence ne l’est pas.

Où dépenser le budget

Les budgets parlent d’allocation, pas de minimalisme. Certaines choses valent leur poids :

• Le chemin critique. Ce pour quoi l’utilisateur est venu passe en premier, le reste peut attendre. Dans un dictionnaire, la barre de recherche et le résultat. Dans une boutique, l’image produit et le prix.
• La vitesse perçue avant la vitesse mesurée. Afficher immédiatement un squelette de résultat vaut souvent mieux que gagner 40 ms sur la réponse.
• Un retour immédiat à la saisie. Répondre à une frappe en 100 ms environ est perçu comme instantané. Au-delà de 300 ms environ, les gens le remarquent.

La part inconfortable

Un vrai budget implique de dire non à des choses qui, isolément, sont bonnes. C’est précisément ce qui le fait fonctionner, et aussi pourquoi les équipes abandonnent discrètement leurs budgets : la première fois qu’un budget bloque une fonctionnalité désirée, le geste facile est de le relever.

La discipline n’est pas dans la fixation du nombre. Elle est dans la réunion où vous le tenez.