React Native Rendering Performance Optimization Practices at Ctrip

Background – As React Native adoption grows, large‑scale applications increasingly focus on rendering performance, measured primarily by First Meaningful Paint (FMP) and Time to Interactive (TTI). Ctrip observed gaps between ideal metrics and real‑world results, identifying missing quantitative standards, visualization tools, conflicting optimizations, and neglect of native/service layers.

Evaluation Criteria – FMP reflects the perceived "white‑screen" duration, while TTI reflects the "direct‑out" experience. Acceptable thresholds are around 1.6 s for normal service requests (FMP) and 1.2 s for pre‑sent requests (TTI). Both metrics must be balanced to avoid sacrificing functionality.

Optimization Directions

3.1 Native Layer

Switch to the Hermes engine on Android to reduce TTI.

Implement hot‑start of the React Native container to preload business code, shortening the FMP critical path.

Reuse containers across sequential screens to avoid repeated initialization, while managing memory‑overflow risks and global‑state contamination.

3.1.2 Bundle

Pre‑download bundles for low‑change, high‑stay screens, using priority‑based asynchronous download queues.

Update, compile, and execute bundles efficiently; single‑file bundles (Hermes) outperform multi‑file JSCore bundles.

3.1.3 Native‑to‑React Native API

Replace costly asynchronous bridges with synchronous APIs for fast data such as AB‑testing IDs, local storage, feature flags, screen size, and SOTP cookies.

3.2 Front‑end (React Native)

Bundle slimming: remove dead code, unused experiments, redundant NPM calls, and abstract repeated components.

Compress large images, replace small icons with IconFont, and prefer network images where appropriate.

LazyRequire: defer module loading until needed. Example:

import {lazyRequire} from 'react';
let moduleA = lazyRequire('../src/ModuleA');

Dynamic import example to avoid executing unused modules:

import A from './A';
import B from './B';
import C from './C';
export {A, B, C};

Selective export using getters:

const Common = {
    get A(){
        const module = require('./A');
        return (module && module.__esModule) ? module.default : module;
    },
    get B(){
        const module = require('./B');
        return (module && module.__esModule) ? module.default : module;
    },
    get C(){
        const module = require('./C');
        return (module && module.__esModule) ? module.default : module;
    }
};
module.exports = Common;

Rendering techniques:

Skeleton screens to reduce perceived white‑screen time.

Batch rendering for list‑type pages, rendering only the visible viewport first.

Progressive rendering: simplify the virtual DOM tree initially, then expand after TTI.

Deferred rendering of secondary layers, combined with LazyRequire.

Pre‑rendering: hot‑start a new container for the next screen while the current screen is active.

3.3 Service Layer

Prioritize service requests to overlap network latency with other rendering work.

Delay non‑critical requests until after TTI.

Implement request caching using a hash‑based key to avoid duplicate network calls.

Practical Tools

4.1 Offline – Use Chrome DevTools Performance to capture flame graphs (Timing) and console timelines (Console) in both emulator and real‑device environments, noting the differences in data fidelity.

4.2 Online – Collect real‑world FMP and TTI via pixel‑detection on released builds, segment data by app version, OS, and time window, and visualize performance curves and P90 coverage.

By combining quantitative metrics, targeted optimizations across native, bundle, front‑end, and service layers, and systematic offline/online analysis, developers can achieve consistent rendering performance improvements that are applicable to both RN and native platforms.