Une page, des dizaines d’appels à la base
Une page de liste qui était rapide met maintenant une seconde ou deux, et c’est de pire en pire à mesure que la liste s’allonge. Chaque requête prise séparément a l’air correcte quand vous la vérifiez. Dix éléments, ça va ; cent, non.
Pourquoi c’est difficile à voir
C’est un N+1, et il naît à l’intérieur d’un rendu : quelque chose récupère une liste, puis récupère un enregistrement lié pour chaque élément. Chaque requête est réellement rapide — c’est pour ça que mesurer le temps par requête ne l’attrape pas, et pour ça qu’il survit à la relecture : le code se lit très raisonnablement. Seul le nombre est faux.
Il arrive plus souvent avec une refonte qu’avec une fonctionnalité. Déplacer un chargement dans un composant rendu une fois par ligne est une modification d’une ligne et transforme une requête en autant de requêtes que vous avez de lignes.
Ce que Sixty y fait
Les appels à la base sont comptés par rendu et comparés entre versions : le constat devient « cette opération faisait une requête par rendu et en fait maintenant quatorze, depuis ce déploiement » plutôt qu’un chiffre de latence à interpréter. Les images de pile viennent avec, donc le rendu responsable est nommé.
Ces preuves partent vers votre agent de code via MCP : la requête, les images de pile, les nombres avant et après, et quels appels enfants expliquent l’écart.
Ce qu’il ne fait pas
Compter les appels par rendu demande un agent serveur, et il en existe un pour Node, Python, Go, Ruby et PHP — mais seul Node l’obtient sans qu’on le lui demande. Sa transformation au build ouvre tout seul un span par fonction asynchrone exportée ; partout ailleurs vous marquez le code qui mérite d’être mesuré (un décorateur en Python, deux lignes en Go, un module inclus en Ruby, un appel en PHP) et l’attribution est ensuite la même. Java, .NET, Rust et Elixir n’ont pas d’agent du tout. La moitié navigateur fonctionne avec n’importe quel backend mais ne voit que ce que la page demande elle-même.
OpenTelemetry
Vous avez déjà OpenTelemetry ?
Gardez votre collector et vos exportateurs. Sixty peut ingérer les traces reliées et les métriques runtime utiles pour déduire les régressions par version ; les agents natifs donnent plus de détails sur les fonctions et drivers lorsqu’ils existent.