Add a span for measuring JS parse time

[roryabraham]

Problem

When a user opens the app, if all our telemetry runs in JS, then we can't account for the time spent parsing the JS in the first place.

Solution

Leverage native code to add Sentry spans for JS parse time

[roryabraham]

If possible, measuring parse time by file would be very helpful

[elirangoshen]

Update I didnt start to work on this yet due to my other sentry task about measuring start app from native

[elirangoshen]

Update: Ill start working on it as I been busy in other sentry related tasks

[elirangoshen]

I worked on it today and have some findings, mostly about measuring the js bundle time. Ill open draft pr as WIP and continue to investigate lead to get parse by file.

[elirangoshen]

I drafted this 2 pr's for changes so far and this is summary for findings:
Added a Sentry span that tracks the time Hermes spends loading and executing the entire JS bundle on app startup. This required registering a native ReactMarker listener before loadReactNative() on Android (separate Mobile-Expensify PR), and using a PerformanceObserver on react-native-mark entries on the JS side.

Measured value on Android HybridApp dev build: ~1600ms
On iOS: ~3000ms

Differences between his and sentry app.start.warm span

Sentry automatically creates a span called "JS Bundle Execution Before React Root" within app.start.warm, which looks similar but has two key differences. First, it ends at AppRegistry.registerComponent() rather
than at the exact moment Hermes finishes executing the bundle. Second, it's measured from the JS side, meaning it includes SDK instrumentation overhead. Our span uses RUN_JS_BUNDLE_START / RUN_JS_BUNDLE_END
timestamps recorded at the native C++ layer — the exact moment Hermes starts and finishes loading bytecode, with zero JS overhead.

All Measurable Startup Events

The react-native-performance library exposes the full native startup timeline. Each pair of events below represents a measurable slice of app startup that could become a Sentry span:

nativeLaunchStart → nativeLaunchEnd — everything inside Application.onCreate(): font loading, native module registration, basic setup. Useful for catching regressions in native startup code.

loadReactNativeSoFileStart → loadReactNativeSoFileEnd — loading the RN and Hermes C++ shared libraries from disk into memory. Reflects device I/O speed and whether the libraries are cold-cached.

downloadStart → downloadEnd — reading the JS bundle bytes from disk into memory. Separates bundle I/O cost from Hermes parse cost, useful on slow/low-end devices.

runJsBundleStart → runJsBundleEnd — Hermes parsing and executing the entire bundle. This is what we track today.

createUiManagerModuleConstantsStart → createUiManagerModuleConstantsEnd — RN generating view manager constants during bundle execution. Reflects native module registration cost.

nativeLaunchStart → contentAppeared — total time from process creation to first rendered frame. The single most user-facing startup metric.

Next steps

I'm checking leads to measure module initialisation time, it seems is more realistic and relevant than js parse time :

JS Parse Time is what Hermes does before any code runs — reading the bytecode, validating it, and preparing it for execution. With Hermes this is very fast because the JS is pre-compiled to bytecode at build    
  time, so there's no text parsing at runtime. Most of the runJsBundleStart → runJsBundleEnd time is actually the next phase.                                                                                        

  Module Init Time is the execution of each module's top-level code — every const, every import side effect, every class definition, every function that runs at module scope. This is where the real cost lives. A
  module that does const foo = heavyComputation() at the top level, or imports a library that eagerly builds a large data structure, will be slow to initialize regardless of its bytecode size.

It might be possible to deduct from those the module init times per file

Let me know your initial thoughts about existing pr's and further steps

[elirangoshen]

So i was able to get the js module init times , thats sample from my logs:

Top 20 slowest module init times:
2026-02-25 12:30:34.888  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    1. 828ms — index.js
2026-02-25 12:30:34.888  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    2. 699ms — src/App.tsx
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    3. 278ms — node_modules/react-native/Libraries/Core/InitializeCore.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    4. 244ms — src/components/ErrorBoundary/index.native.tsx
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    5. 224ms — node_modules/react-native/Libraries/ReactNative/AppRegistry.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    6. 224ms — node_modules/react-native/Libraries/ReactNative/AppRegistryImpl.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    7. 223ms — node_modules/react-native/Libraries/ReactNative/renderApplication.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    8. 221ms — node_modules/react-native/Libraries/ReactNative/AppContainer.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    9. 221ms — node_modules/react-native/Libraries/ReactNative/AppContainer-dev.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    10. 209ms — node_modules/react-native/Libraries/Components/View/View.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    11. 209ms — node_modules/react-native/Libraries/NativeComponent/NativeComponentRegistry.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    12. 209ms — node_modules/react-native/Libraries/Components/View/ViewNativeComponent.js
2026-02-25 12:30:34.889  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    13. 208ms — node_modules/react-native/Libraries/ReactNative/UIManager.js
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    14. 185ms — src/components/HTMLEngineProvider/index.native.tsx
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    15. 185ms — src/components/HTMLEngineProvider/BaseHTMLEngineProvider.tsx
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    16. 185ms — src/components/HTMLEngineProvider/HTMLRenderers/index.ts
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    17. 180ms — src/components/HTMLEngineProvider/HTMLRenderers/AnchorRenderer.tsx
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    18. 179ms — src/components/AnchorForAttachmentsOnly/index.native.tsx
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    19. 179ms — src/components/AnchorForAttachmentsOnly/BaseAnchorForAttachmentsOnly.tsx
2026-02-25 12:30:34.890  7087-7266  ReactNativeJS           org.me.mobiexpensifyg.dev            I    20. 179ms — src/components/Attachments/AttachmentView/index.tsx

Maybe id try to get top 50 , or just filter the ones 3rd party ones ?

@rinej @adhorodyski goot to know your thoughts as well

[rinej]

Looks good! From my perspective, the 1st-party modules under src/ are the most valuable to track since those are the ones we can actually optimize - filtering them out separately sounds like the good idea.

Also, are there any modules standing out with large init times? Would be great to identify any culprits we see for quick wins