Mon appli Lovable est devenue lente après une modification
Hier, tout allait bien. Vous avez demandé une fonctionnalité de plus, publié, et maintenant une page met plusieurs secondes — ou elle reste bloquée sur le chargement et n’aboutit jamais. Rien ne semble anormal dans l’éditeur, et demander à l’agent de « rendre ça plus rapide » modifie des choses qui n’étaient pas le problème.
Pourquoi c’est difficile à voir
Une appli Lovable n’a pas de serveur à elle, donc la réponse habituelle — regardez les journaux du serveur — n’a rien à regarder. Ce qui a réellement changé est presque toujours une requête : l’agent a réécrit un composant et, au passage, a supprimé un filtre ou déplacé un chargement à l’intérieur d’une liste. Les deux sont invisibles dans l’éditeur et aucune ne lève d’erreur.
L’autre raison pour laquelle c’est difficile à voir, c’est que ce n’était pas lent au moment où ça a été écrit. Contre la poignée de lignes de votre projet, c’est instantané. Ça ne devient lent qu’une fois qu’il y a de vraies données derrière, c’est-à-dire en général bien après la modification qui en est la cause.
Ce que Sixty y fait
L’agent navigateur mesure chaque requête Supabase que fait la page : combien il y en a, et combien de lignes chacune renvoie. Publiez deux fois et la seconde publication est comparée à la première : le constat nomme donc la version plutôt que le jour.
Ce que vous obtenez est une phrase — cette requête renvoyait 30 lignes et en renvoie maintenant 30 000, sur cette page, depuis cette publication — et les preuves partent vers l’agent que vous utilisez, si bien que le correctif est un diff et non une devinette.
Ce qu’il ne fait pas
Le premier constat arrive après votre prochaine publication, pas immédiatement : il n’y a rien à quoi comparer une version isolée. Et travailler dans l’aperçu Lovable ne suffit pas — l’aperçu tourne sur un serveur de développement sans ressources empreintées, il n’y a donc aucune version sur laquelle ancrer une comparaison.
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.