 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Mobile engineers are very familiar with application crashes and the importance of keeping crash rates within acceptable bounds. While not as drastic and obvious a failure as a crash, application hangs and slowness can have equally negative impacts on long-term user engagement.
People’s patience is finite, and most will tolerate slow, frustrating experiences for only so long before deleting an app, as this data shows.
Likelihood that users will delete an application based on slow behavior. Data from The State of Mobile Experience report by Embrace.
So, what can you do to understand where your app is running slow?
This is where spans come in. They help you measure the performance of key actions within your application so you can quickly address problems.
Conceptually, spans are quite simple and consist of three key things:
Example of a parent span and its child spans that measure the performance of add-to-cart functionality.
Spans are incredibly flexible in what they can be used for. Spans that monitor larger functions in the app, e.g., the entire time a user spends on a checkout page in an e-commerce app, are typically used by product organizations. However, I will discuss performance spans, which focus on more granular tasks and are typically more helpful to mobile engineers working to understand and fix performance issues.
A performance span measures the duration of actions and flows in your app that are not directly dependent on user interactions. In other words, performance spans measure how long it takes a given action to complete (e.g., add to cart).
Spans can help mobile engineers in several ways.
Spans help you understand the true performance of your app once it has been released. Actions may be fast and never hang while testing a clean install of your app on a modern iOS or Android device with a fast network connection. But they may behave very differently for a significant subset of your real-world users.
Unless you instrument performance spans, you won’t know what your user population really experiences. Maybe average startup duration on some devices jumps significantly due to a new ad SDK version. Perhaps payment processing is slow for users in certain countries. Unless you measure these things, you will not know the frustration building with significant parts of your user population.
Example of a span that shows a combination of acceptable and unacceptable durations. For about 65% of users, this span duration is fine, but for the remaining 35%, the duration is unacceptably long.
As a mobile engineer, it can be incredibly helpful to know the extent of a problem. Did your app get a few bad reviews for slow behavior but the issue doesn’t affect a large proportion of your users? Or do the negative reviews indicate a problem that affects a larger percentage of users?
Having span data makes it much simpler to decide whether to prioritize improving the performance of various parts of your app. In the sample chart above, a real problem exists for about 35% of users.
Your backend team already uses spans to understand service and infrastructure health, and your DevOps team is familiar with how to analyze and monitor them. Adopting a shared telemetry language allows you to standardize how you instrument the pieces of your mobile and web apps. Using a shared language also simplifies how you can connect the spans that start in the mobile app with all the backend services they interact with.
By tracing key actions and flows through the entire journey from client to backend and back to the client, you get a complete picture of what is really causing the slowness that end users experience.
Spans are incredibly versatile, so how you can best use them for your application will depend on your business and technical goals. I will use an e-commerce app as an example for understanding what makes sense to instrument. In general, though, enumerating the parts or flows in your app that are most critical to a good user experience is a good starting point for deciding where to add spans.
Critical flows in most e-commerce apps include:
While some apps allow purchasing as a guest, in most cases buyers have to log in. While this may seem like a simple process, modern logins have many components that were not common a decade ago, such as biometric inputs and two-factor authentication (2FA). You can have a root span for the login and child spans for the individual components, such as accessing biometric data and getting input for 2FA.
How long does it take for search results to appear? How well does delivering search results work over challenging network connections? How long does it take to render the search results? You can use a root span for the search operation and break it down.
When a user clicks a button to add an item to their cart, how long does it take to succeed? Are there network calls? Will it work with a poor network connection?
The most important part of an e-commerce app is enabling users to successfully make purchases, so monitoring the actual order submission process is incredibly important. You can add a span that measures the time from when a “Submit order” button is clicked until the “Order confirmed screen” appears. Then you can add child spans that measure individual steps in that journey, like making a call to a third-party payment provider.
Instrumenting a few spans manually is typically not a challenging task, and when you use an observability SDK like the ones we have built at Embrace, you will also get auto-instrumented spans for common tasks such as network requests. You can start by instrumenting one or two critical flows in your app and then expand from there. You don’t need to exhaustively instrument every single flow in your app before you can derive value.
Choosing observability SDKs that are OpenTelemetry (OTel)-compliant gives you a great deal of flexibility in how you collect and analyze your performance span data. Embrace provides a hosted service, but you can also choose to send your data to an OTel-compatible collector.
To learn more about how performance spans can help you deliver a better end-user experience, feel free to check out Embrace’s website or join our Slack community.
