I have a web application written in Angular 14. I have been running tests in lighthouse to improve the performance of the application, it is fine for desktop, but much too slow for mobile users. The application has three tabs, each containing a never-ending-page of items. One of the tabs have images instead of items. I have followed several performance optimizing guides. I lazy load all of my pages and have minimised the shared/core modules as much as possible. Following the performance guides I have also enabled optimizations in the angular.json file. I have minified and compressed all my css and js files. In addition, I have implemented onPush change detection on all major pages and trackBy in all ngFor in the application. The main issue reported by Lighthouse is main-thread execution. As can be seen in the screenshot. Bear in mind this is when the CPU is slowed down. The source of the very long script evaluation points to polyfill.ts, but I have found out the problem is not actually polyfill, but zone (which is imported in polyfill). So I have measured the change dection, but it looks fine: > ng.profiler.timeChangeDetection() ran 13400 change detection cycles 0.04 ms per check So the issue doesn't seem to be change detection. The only source left I can think of is rxjs observables. Therefore, I have gone through all of the major pages and ensured they are unsubscribed or piped with takeUntil or take. Is there a way to track observables live? I think I may have a leak somewhere, but if that was the case I would expect the problem to get worse over time, instead of better. This computation is primarily active during/right-after page load. Edit I have examined the trace from Lighthouse in further detail and the problem doesn't seem to come from where I expect it at all. The yellow line indicates more or less where my components finish executing. The work on the mainthread from here seems to be many small function calls. I don't know how to find out what function is being called, the performance tab, simply says Timer Fired. Which makes it look like I might have an event listener which isn't debounced properly. Edit 2 Via a tedious process of commenting our components and modules I have found that part of the issue is indeed in my code. I sending requests using rxjs mergeMap and asapScheduler, which I thought can on an async thread. It seems to heavily affect main thread execution. So I might have to look into handling these requests in a web worker instead. However, this is only responsible for half of the slow script evaluation. Continue reading...
