Performance Monitoring in React Native: Firebase Performance and New Relic in Practice

1. Why Production Monitoring Does Not Replace Local Profiling

Local profiling with Flipper or native profilers reliably shows how an app behaves on your own test device, but says nothing about the actual device, network, and operating system diversity of the real user base. A budget Android device with little RAM, a user on a weak mobile connection in a rural area, or a rare combination of OS version and device model produce performance problems that simply cannot be reproduced in a developer's office with a current high-end device and WiFi.

Application Performance Monitoring, APM for short, closes that gap by collecting and aggregating performance data directly from production app installs. Firebase Performance Monitoring and New Relic Mobile are two established tools for React Native that differ in scope, pricing model, and integration depth, but follow the same basic principle: capture automatic baseline metrics and add custom traces for app-specific critical flows.

2. Which Metrics Are Captured Automatically

Both tools measure a set of baseline metrics without any additional code. App start time is typically split into two phases: the time from process start to the first visible frame, called cold start or app start, and the time to actual readiness for interaction. Firebase Performance explicitly distinguishes between App Start, which begins automatically at process start, and a manually markable time to the first meaningful interaction.

Network latency is captured automatically for every HTTP call, provided the networking library in use is supported, including response time, status code, and payload size. Frame drops, or the frame rate during app usage, are recorded separately and reveal which screens users actually experience jank on. New Relic Mobile adds automatically captured network interaction maps and a correlation between crashes and preceding performance anomalies on top of these baseline metrics, something Firebase Performance does not offer at this depth.

3. Setting Up Firebase Performance

Setting up Firebase Performance in React Native happens through the official @react-native-firebase/perf package, which builds on the existing Firebase project that is usually already configured for Analytics or Crashlytics anyway. After installation and native setup via google-services.json or GoogleService-Info.plist, automatic capture of app start time and network requests begins without any further code.

Reports in the Firebase console dashboard typically take twenty-four to forty-eight hours until enough data points have aggregated to show reliable trends. What matters for React Native projects is that Firebase Performance by default only captures native network requests through the platform HTTP layer; requests made via fetch or axios inside JavaScript may need additional configuration to be correctly attributed to the bridge.

npm install @react-native-firebase/app @react-native-firebase/perf

# iOS: install native dependencies
cd ios && pod install && cd ..

# Automatic capture of app start and network requests
# begins with no further code once the module is imported

4. Setting Up New Relic Mobile

New Relic Mobile for React Native is wired up through the newrelic-react-native-agent package and requires an app token from the New Relic dashboard, configured separately for iOS and Android builds. Unlike Firebase Performance, New Relic additionally provides a mobile APM dashboard with distributed traces that make the full path of a request traceable across multiple backend services, which is particularly relevant for teams running their own microservice infrastructure.

Initialization happens early in the app lifecycle, ideally as the very first call in index.js, before the actual app rendering, so even the earliest phases of app start get captured. New Relic also offers an explicit interactionCreate API for defining custom, named interactions beyond the automatically captured network and start metrics.

// index.js
import NewRelic from "newrelic-react-native-agent";
import { AppRegistry } from "react-native";
import App from "./App";

NewRelic.startAgent(
  Platform.OS === "ios"
    ? "IOS_APP_TOKEN_FROM_NEW_RELIC_DASHBOARD"
    : "ANDROID_APP_TOKEN_FROM_NEW_RELIC_DASHBOARD"
);

AppRegistry.registerComponent("MyApp", () => App);

5. Setting Up Custom Traces for Critical User Flows

Automatically captured metrics cover generic cases but say nothing about app-specific, business-critical flows like a multi-step checkout process or a login with biometric authentication. Both tools support creating custom traces that can be started and stopped at any code location and can collect custom attributes and metrics in between, for example the number of items in the cart or the selected payment provider.

For a checkout flow, a single trace that starts when entering the cart screen and only ends after successful payment confirmation works well, complemented by intermediate markers for each individual step, say address entry, payment method, and confirmation. This lets the dashboard show not just total duration but the duration of each individual sub-step, making it possible to pinpoint exactly which step users spend abnormally long on or abandon at.

import perf from "@react-native-firebase/perf";

async function trackCheckoutFlow(cartItemCount: number) {
  const trace = await perf().startTrace("checkout_flow");
  trace.putAttribute("cart_item_count", String(cartItemCount));
  trace.putMetric("started_at_ms", Date.now());
  return trace;
}

// Call at the respective steps in the checkout flow
async function onAddressSubmitted(trace: FirebasePerformanceTypes.Trace) {
  trace.putMetric("address_step_completed_at_ms", Date.now());
}

async function onPaymentConfirmed(trace: FirebasePerformanceTypes.Trace) {
  trace.putAttribute("payment_provider", "stripe");
  await trace.stop();
}

6. Tracking Frame Drops and UI Responsiveness Specifically

Frame drops are particularly relevant for React Native apps because they are often caused by expensive computations on the JavaScript thread blocking the UI thread, say an unfiltered list with a thousand entries and no virtualization. Both monitoring tools capture the frame rate during usage, and New Relic additionally offers an explicit slow-rendering and frozen-frame metric that flags specific screens where the frame rate repeatedly drops below a critical value.

For diagnosis, it pays off to correlate frame drop data with custom traces: if the frame rate systematically dips during a specific checkout step, that points to a concrete, code-locatable cause, say an expensive re-render cascade when updating the cart total. Without that correlation, a low average frame rate stays an abstract number with no concrete lead for a fix.

7. Setting Alerting Thresholds for Production Apps

An alert that fires on every small fluctuation quickly leads to alert fatigue, where a team eventually ignores notifications even when a real problem exists. Sensible thresholds combine an absolute value with a relative change: an app start time above four seconds at the ninety-fifth percentile is problematic regardless of the historical trend, while a sudden doubling of average network latency compared to the seven-day average points to a new problem even at a low absolute value.

New Relic lets you define such baseline-based alerts directly in the dashboard, where a threshold is defined relative to the historical spread rather than as a rigid absolute value, which meaningfully reduces false alarms from normal daily fluctuations. Firebase Performance, in contrast, offers simpler, static threshold alerts through Cloud Monitoring, which are often sufficient for smaller teams but need manual retuning as the user base or app usage changes over time.

8. Firebase Performance or New Relic: Selection Criteria

For teams already using Firebase for Analytics, Crashlytics, or Remote Config, Firebase Performance is the obvious choice, since integration flows seamlessly into the same console and the same billing model without requiring an additional third-party relationship. For simple to moderate requirements around app start time, network latency, and basic traces, the feature set is entirely sufficient in most cases.

New Relic pays off primarily for teams with their own backend infrastructure who need end-to-end traces spanning the mobile app and server services, or for organizations that already use APM for other systems and prefer a unified monitoring platform. The broader feature set comes with a correspondingly higher price and a more involved initial setup, which often does not justify the extra effort for smaller projects.

9. Privacy and the Monitoring's Own Performance Overhead

Performance monitoring inevitably collects device-related data such as model name, operating system version, and network type, which in the EU requires a GDPR review, particularly the question of whether this data is linked to other user data and how long it is retained. Both providers offer configuration options for data minimization, such as disabling automatic user identification, which should be reviewed before production rollout and documented in the app's privacy policy.

The performance overhead of the monitoring libraries themselves is small for both tools, typically in the low single-digit percentage range for app start time and memory usage, but should still be measured against a build without monitoring before a production rollout. Especially with many custom traces involving frequent attribute assignments, the overhead can add up noticeably, which is why traces should be used deliberately for truly critical flows rather than for every possible interaction.

10. Summary

11. FAQ: Performance Monitoring: The Essentials at a Glance