Help me understand why the navigation transactions exist

[shamilovtim]

Hi I have a general question about why Sentry instruments navigation transitions. I've not seen another mobile performance monitoring tool do this before and personally have found it to be noisy and not very useful. Most transitions happen in the blink of any eye and I assume there isn't much a mobile team could really do to make these transitions any faster. Is there something I'm not understanding as to why this instrumentation exists?

[bruno-garcia]

Are you referring to creating transactions over it, or creating breadcrumbs?
We rely on navigation transitions to create transactions as it's a clear point where we can track the operations that happen and how that can affect user experience. If they are always fast, that's great. But often they are not and the product aims to help you identify which ones can have the most attention from developers to improve things

[shamilovtim]

creating transactions over it

Perf transactions / spans. The bread crumbs are useful.

But often they are not and the product aims to help you identify which ones can have the most attention from developers to improve things

I'd say that's part of my question. What optimizations are you hearing about to make navigation perform better? My understanding is that everyone uses either React Navigation or React Native Navigation. The API in these is declarative and we simply trigger a navigation using a method call to the navigator. I'm not aware of any optimizations that are available to us within a navigation call. If what I am saying is true what would be the purpose of profiling an event which we have no agency to tune?

To clarify one thing. It's super useful to have the actual screens profiled and I know that the navigation integration lets the SDK know which screen its on. It's just the navigation transaction that I don't find useful. Is there a way to prevent creating navigation transactions?

[bruno-garcia]

It's not the "navigation method" that we're trying to measure here. It's what happens as a result. Are HTTP calls triggered? Or files read/written, ORM queries, etc. The navigation is just the trigger, and within that navigation transaction you should be getting the spans of which timing will vary. Depending on latency, device power, or code tuning.

Is there nothing within the navigation transaction? If we remove that, are you going to have any transactions out of the box anyway?