Performance Comparisons in Brownfield React Native Projects

Brownfield work adds React Native to an existing app, where a big-bang replacement is not practical. Karekar says the goal is for React Native screens to look and behave like their native counterparts, even though their implementations differ. That makes it harder to compare performance using a single screen-load measurement.

The earlier product detail page used one GraphQL query, followed by data transformations and a completed render. The React Native version used Zalando’s internal Rendering Engine, which streams content through recursive API calls. The screen fills gradually, so a start-to-finish load time does not capture the same experience in both versions.

Karekar describes a perceived-performance metric called meaningful render, similar to web LCP. Modules in the rendering framework can identify which one represents the meaningful content; because they resolve sequentially, that module’s completion marks the metric. The implementation uses React Native’s `onLayout` callback to record the time and ends an OpenTelemetry span.

The meaningful-render span appears alongside network and rendering operations in the team’s observability tooling. Zalando added the metric to gradual rollout plans to help teams assess performance as they release changes. Karekar notes that small rollout samples can produce misleading latency outliers, and attaching spans to the global route does not work in every case.

Karekar says React Native’s Performance API and Performance Observer were coming to the runtime, with the API experimental at the time of the talk. He expects the runtime API could replace Zalando’s internal implementation while keeping its measurement interface usable. The broader aim is to make performance measurement part of rollout practice.