Les utilisateurs signalent que l'application ralentit plus ils la laissent ouverte longtemps. Comment traqueriez-vous ça ?

Ce motif indique une fuite ou une croissance non bornée. Prenez des instantanés du tas dans les DevTools à deux moments après le même parcours utilisateur, comparez les tailles retenues et regardez ce qui retient les noeuds DOM détachés. Les causes habituelles sont des écouteurs et abonnements jamais retirés, des minuteurs qui continuent après le démontage, des caches qui n'évincent jamais, et des closures capturant de gros objets. Corrigez en démontant tout ce qu'un composant a créé.

Je commencerais par confirmer que c'est bien la mémoire et pas autre chose, donc je laisserais le moniteur de performance ouvert et je répéterais le parcours décrit par les utilisateurs, en surveillant le tas ainsi que le nombre d'écouteurs et de noeuds. S'ils montent et ne redescendent jamais après une collecte forcée, c'est une fuite. Ensuite je prends un instantané du tas, je fais le parcours dix fois, j'en prends un autre, et je compare par taille retenue. Les noeuds DOM détachés sont le signe qui trahit, et le chemin de rétention me dit ce qui les retient. En pratique, c'est presque toujours quelque chose mis en place sans démontage correspondant : un écouteur de resize ou de scroll sur window, un abonnement à une socket, un interval, ou un observer qui survit au composant. J'en ai trouvé un où une bibliothèque de graphiques attachait un écouteur par rendu et n'en retirait qu'un au démontage, donc le compte grimpait à chaque navigation. Le motif de correction est ennuyeux mais efficace : tout ce qui est créé dans un effet renvoie son nettoyage, et tout cache reçoit une limite de taille au lieu de croître pour toujours.