Nutzer melden, dass die App langsamer wird, je länger sie geöffnet bleibt. Wie würdest du das aufspüren?

Dieses Muster deutet auf ein Leck oder unbegrenztes Wachstum hin. Nimm in den DevTools zwei Heap-Snapshots nach demselben Nutzerflow, vergleich die Retained Sizes und schau, was die abgetrennten DOM-Knoten festhält. Die üblichen Ursachen sind Listener und Subscriptions, die nie entfernt werden, Timer, die nach dem Unmount weiterlaufen, Caches, die nie etwas rauswerfen, und Closures, die große Objekte einfangen. Der Fix ist, alles abzubauen, was eine Komponente angelegt hat.

Ich würde zuerst bestätigen, dass es Speicher ist und nichts anderes, ließe also den Performance Monitor offen und wiederhole den Flow, den die Nutzer beschreiben, mit Blick auf Heap sowie Listener- und Knotenzahlen. Steigen die und kommen auch nach einer erzwungenen Collection nicht zurück, ist es ein Leck. Dann nehme ich einen Heap-Snapshot, laufe den Flow zehnmal, nehme einen zweiten und vergleiche nach Retained Size. Abgetrennte DOM-Knoten sind der Verräter, und der Retainer-Pfad sagt mir, was sie festhält. In der Praxis ist es fast immer etwas, das ohne passendes Teardown aufgesetzt wurde: ein resize- oder scroll-Listener auf window, eine Socket-Subscription, ein Interval oder ein Observer, der die Komponente überlebt. Ich habe mal einen gefunden, bei dem eine Chart-Bibliothek pro Render einen Listener angehängt und beim Unmount nur einen entfernt hat, die Zahl wuchs also mit jeder Navigation. Das Fix-Muster ist langweilig, aber wirksam: alles, was in einem Effect entsteht, gibt sein Cleanup zurück, und jeder Cache bekommt ein Größenlimit statt ewig zu wachsen.