--- title: "Diagnose frontend performance issues with RUM Profiling" description: "Use Datadog RUM Profiling to identify CPU-intensive code behind slow mobile app launches and frontend interactions across iOS, Android, and the browser." author: "Arti Arutiunov, Jessica Manheimer" date: 2026-11-02 tags: ["real user monitoring", "digital experience monitoring", "performance", "ios", "debugging"] blog_type_id: the-monitor locale: en --- When a mobile application takes too long to launch or becomes unresponsive, it can be difficult to find the cause. Datadog Real User Monitoring (RUM) helps developers detect these issues and understand which users are affected. But knowing that an application is slow doesn't tell you which part of its code is responsible. Engineers often need to reproduce the problem locally, piecing together performance metrics and code execution information from separate tools. This can be particularly difficult when performance varies across devices, operating system versions, and real-world conditions. On top of that, it can be hard to share findings from local profiles with teammates. Datadog RUM Profiling is an add-on to RUM that connects code-level CPU profiling data with performance measurements from real user sessions. RUM Profiling, which supports browser applications through [Browser Profiler](https://www.datadoghq.com/blog/browser-profiler.md), now supports iOS and Android applications as well, enabling developers to see which methods consume CPU time during performance-critical operations on real users' devices. In this post, we'll show how RUM Profiling helps you: - [Identify code-level bottlenecks in iOS and Android applications](#identify-code-level-bottlenecks-in-ios-and-android-applications) - [Collect code-level performance data from production mobile applications](#collect-code-level-performance-data-from-production-mobile-applications) - [Troubleshoot frontend performance across browser and mobile applications](#troubleshoot-frontend-performance-across-browser-and-mobile-applications) ## Identify code-level bottlenecks in iOS and Android applications RUM Profiling attaches CPU profiles to the RUM events where mobile performance problems surface, from slow application launches to moments when an app stops responding, as well as to the workflows that developers define as critical [RUM operations](#track-critical-workflows-with-rum-operations). Developers can use RUM Profiling to investigate the code behind a single slow or unresponsive event, or find the bottlenecks that have the biggest impact on performance. Slow application launches can create friction before users have a chance to interact with an app. With RUM, developers can [track startup performance](https://www.datadoghq.com/blog/rum-mobile-app-launch-monitoring.md) through industry-standard measurements such as [Time to Initial Display](https://developer.android.com/topic/performance/vitals/launch-time#time-initial) (TTID) and [Time to Full Display](https://developer.android.com/topic/performance/vitals/launch-time#time-full) (TTFD). These measurements help teams determine the severity of startup delays, but they don't independently explain what could be causing those delays. RUM Profiling helps explain the *why* by adding code-level visibility through the association of CPU profiles with application startup events in iOS and Android applications. When developers identify a slow TTID measurement, they can examine the corresponding CPU profiles to see which functions executed during the affected startup period, without reproducing the same conditions on a local device. For example, suppose an engineering team has configured a Datadog monitor to track TTID for cold application launches. After deploying a new version, the team is alerted about a significant increase in startup times. RUM helps them identify the affected application version and sessions, and RUM Profiling provides the associated CPU profiles. Developers can inspect the method call stacks in flame graphs and thread timelines to investigate which functions consumed CPU time during startup and identify potential sources of the regression. They can do all of this in RUM, without switching to a separate debugging tool, and can download profiles for further analysis as needed. ![Datadog associates a mobile application startup measurement with function-level CPU profiling data.](https://web-assets.dd-static.net/42588/1793640998-rum-profiling-mobile-ttfd-profile.png) ### Track critical workflows with RUM operations Application startup is one important use case, but developers also need to investigate performance during business-critical interactions. A checkout flow, for example, might occasionally stall for certain users even when overall application performance appears healthy. Critical [RUM operations](https://docs.datadoghq.com/real_user_monitoring/operations_monitoring.md?tab=browser) let developers explicitly mark the key moments to be profiled in their app, such as authentication, adding an item to a cart, or completing checkout. Enabling profiling for an operation tells Datadog that this moment matters. Datadog then collects CPU profiling data during the activity and attaches it to the operation’s RUM event, even if no out-of-the-box RUM event is captured during this time. This gives developers code-level context for important workflows, not just the events Datadog profiles automatically. ![Datadog associates CPU profiling data with a mobile application operation to investigate a slow interaction.](https://web-assets.dd-static.net/42588/1793640993-rum-profiling-mobile-operation-profile.png) ### Understand the scope of performance issues with aggregated profiling views A single CPU profile can help developers investigate an individual performance issue, but it doesn't necessarily reveal the scope of that issue. A function that consumes excessive CPU time during one application launch, for example, might also contribute to slow startup performance across many sessions. Identifying these recurring patterns helps engineers prioritize improvements that can benefit more users. RUM Profiling provides aggregated profiling views that help developers identify methods that repeatedly contribute to CPU consumption across multiple real user sessions. This helps them distinguish isolated performance issues from recurring bottlenecks that may warrant broader optimization work. For mobile applications, aggregated profiles cover supported profiling scenarios, including application startup, TTID, TTFD, and critical RUM operations. For example, if multiple users experience slow application launches, aggregated profiling data can help identify methods that repeatedly consume CPU time during startup. Developers can then examine individual profiles for additional context and determine which code paths to investigate. ![Aggregated mobile CPU profiles identify functions that repeatedly consume CPU time across retained user sessions.](https://web-assets.dd-static.net/42588/1793640987-rum-profiling-mobile-aggregate.png) Developers can also compare aggregated profiling data across groups of sessions to investigate performance regressions. For example, they can compare slow application launches (at or above p90) with typical launches (at or below p75) to identify methods that consume more CPU time in slower sessions, or compare profiling data across application versions to investigate changes in code execution following a deployment. After optimizing a CPU-intensive method, developers can use [out of the box metrics](https://docs.datadoghq.com/real_user_monitoring/rum_without_limits/metrics.md) provided through RUM without Limits, including TTID, TTFD, and critical RUM operations, to evaluate whether application performance has improved for real users. ## Collect code-level performance data from production mobile applications Traditional profiling tools can introduce CPU and battery overhead, potentially affecting the same performance they are intended to measure. Because of this, developers often profile in controlled testing environments. But it can be difficult or impossible to reproduce problems that occur only on particular devices or under real-world conditions in these environments. RUM Profiling circumvents this problem by profiling only a sample of application launches and sessions, in production, on real user devices. It lets developers control profiling collection on iOS and Android through sampling rates they can adjust using [RUM Remote Configuration](https://docs.datadoghq.com/real_user_monitoring/remote_configuration.md). If application startup times or Android [ANR](https://developer.android.com/topic/performance/issues/anr) rates increase, for example, a team can raise the profiling sample rate to collect more profiles, then lower it once it has gathered enough data. The underlying collection mechanisms differ by platform. On Android, [Datadog uses the operating system's ProfilingManager API](https://android-developers.googleblog.com/2026/06/datadog-profilingmanager-performance-insights.html), subject to application and device-level rate limits. RUM Profiling also captures CPU profiles for ANR errors. On Android 16 or higher, these can include [system traces](https://developer.android.com/topic/performance/tracing) showing what the main thread was waiting for, such as a lock held by another thread, a slow disk read, or a call to another process. On iOS, RUM Profiling associates CPU profiles with application launches, [app hangs](https://docs.datadoghq.com/real_user_monitoring/error_tracking/mobile/ios.md#add-app-hang-reporting), and long tasks, so developers can examine the code executing when an application freezes or stops responding. ![An Android CPU profile provides function-level context for a performance issue recorded in Datadog RUM.](https://web-assets.dd-static.net/42588/1793640981-rum-profiling-mobile-android-long-task.png) ## Troubleshoot frontend performance across browser and mobile applications Many engineering teams maintain both web and native mobile applications, but the performance issues affecting these environments can differ considerably. In browser applications, long-running JavaScript tasks can block the main thread and delay user interactions. Native iOS and Android applications execute work across multiple threads, so developers may need to investigate activity on different threads to identify the code contributing to a slowdown. Although each platform uses different profiling mechanisms and supports different collection scenarios, Datadog packages and presents profiling data the same way for every platform. All profiles are attached to RUM events, can be queried alongside the rest of your RUM data, and roll up into the same aggregated profiling views. For browser applications, RUM Profiling collects [JavaScript CPU profiling data](https://developer.mozilla.org/en-US/docs/Web/API/JS_Self-Profiling_API) and correlates it with RUM events, including views, actions, long tasks, and performance vitals. Developers can use the Profiling Explorer to investigate CPU-intensive functions, identify recurring bottlenecks, and compare profiling data across application versions. You can learn more in our post on [Browser Profiler](https://www.datadoghq.com/blog/browser-profiler.md). With support for iOS and Android, engineers responsible for an ecommerce application, for example, can use RUM Profiling to investigate JavaScript functions contributing to slow checkout interactions in the browser while also examining CPU profiles associated with slow launches, Android ANRs, iOS app hangs, or RUM operations in their mobile applications. ![Datadog RUM Profiling connects browser and mobile CPU profiles with real user performance events.](https://web-assets.dd-static.net/42588/1793640976-rum-profiling-mobile-cross-platform-diagram.png) ### Find root causes faster with Bits AI and the Datadog MCP Server Developers don't need to be experts in reading profiling data to act on it. From any profiled RUM event or the aggregated profiling page, they can ask [Bits AI](https://docs.datadoghq.com/bits_ai.md) for the root cause of a slowdown, such as why the app froze or what caused a regression in the latest release, without manually reviewing call stacks or flame graphs. Developers can also use the [Datadog MCP Server's profiling tools](https://docs.datadoghq.com/mcp_server/tools.md#profiling) to query for problematic sessions, such as those with slow app launches, frequent ANRs, or app hangs, and analyze the associated CPU profiles. ## Investigate frontend performance down to the code with RUM Profiling RUM helps developers identify the performance problems users experience, and RUM Profiling provides the code-level context to explain why they occur. With support for browser, iOS, and Android applications, engineering teams can use RUM Profiling to investigate code-level bottlenecks across frontend experiences and use profiling data from real users' devices to guide optimization efforts. RUM Profiling is available as an add-on to Datadog Real User Monitoring. To get started, see the [RUM Profiling documentation for Android](https://docs.datadoghq.com/real_user_monitoring/correlate_with_other_telemetry/profiling.md?platform=android), [iOS](https://docs.datadoghq.com/real_user_monitoring/correlate_with_other_telemetry/profiling.md?platform=ios), and the [browser](https://docs.datadoghq.com/real_user_monitoring/correlate_with_other_telemetry/profiling.md?platform=browser). To learn more about investigating JavaScript performance, read our post on [Browser Profiler](https://www.datadoghq.com/blog/browser-profiler.md). If you're new to Datadog, to start investigating real user performance with Datadog RUM.