Reduzir Cold Start no React Native 2026: Profiling do TTI com o Performance Panel

Atualizado: 18 de agosto de 2026

Para reduzir o cold start do React Native em 2026, meça o TTI a partir do Application.onCreate (Android) e application(_:didFinishLaunchingWithOptions:) (iOS), grave um trace no Performance Panel do React Native DevTools 0.83+, ative o Hermes V1 do 0.84 e mova módulos pesados para inlineRequires do Metro combinado com o lazy loading de TurboModules. Com esses quatro passos, tenho reduzido consistentemente o TTI em 35 a 55% em apps de tamanho médio sem tocar em nenhuma feature de produto.

• O Performance Panel do React Native DevTools 0.83 traz flame charts, CPU throttling e trace de Hermes ao mesmo nível do Chrome DevTools. É o ponto de partida obrigatório.
• Hermes V1, default desde React Native 0.84, corta o parse de JS em bytecode e reduz o TTI em até 50% em bundles grandes.
• A Nova Arquitetura (0.76+) com TurboModules lazy-loaded elimina a inicialização síncrona de 40+ módulos nativos e derrubou o TTI em 44% nos benchmarks da Meta.
• inlineRequires no Metro adia a avaliação de módulos JS para o primeiro uso, economizando 300 a 500ms em cold start em apps com 1.500+ módulos.
• Metas de 2026 para apps de produção: TTI < 1.2s em iPhone 13, TTI < 2.0s em Pixel 6a, install size < 30MB.
• Splash screens nativos com handoff sincronizado eliminam o white flash entre a tela do sistema e o primeiro paint do React.

O que é cold start e como se relaciona com o TTI no React Native

Cold start é o intervalo entre o toque no ícone do app e a primeira tela interativa quando o processo não estava em memória. No React Native, esse intervalo é fatiado em quatro estágios que aparecem em qualquer trace do Perfetto ou do Performance Panel: native startup (dyld, Application.onCreate, inicialização da JVM/Objective-C runtime), bridge init (agora bridgeless a partir da RN 0.82, mas ainda existe o setup da JSI), JS bundle load (leitura do bytecode Hermes, avaliação dos módulos raiz) e first render (mount do componente raiz até o primeiro onLayout completo).

Três métricas quantificam essa jornada. TTID (Time to Initial Display) marca o primeiro pixel não branco, ótimo para percepção e ruim para usabilidade. TTI (Time to Interactive) marca o momento em que a UI responde a toques sem travar o JS thread por mais de 50ms. É o número que importa para conversão. TTFD (Time to Full Display) só bate quando conteúdo remoto (imagens, listas paginadas) terminou de carregar. Em 90% dos meus projetos de consultoria, o cliente diz "o app está lento" olhando TTFD, mas o gargalo real está no TTI, porque é o número que o Play Console e o App Store Connect medem em App Launch Time e afetam o ranking na loja.

Antes de mudar uma linha de código, é fundamental entender qual desses estágios domina seu perfil. Um trace mostra que ~35% do TTI típico está no native startup (fora do seu controle direto), ~40% em JS bundle load (Hermes + inline requires resolvem), ~15% em bridge/JSI init (a Nova Arquitetura já entrega) e ~10% no first render (React Compiler e memoização atacam). Se você otimizar first render sem tocar no JS bundle load, ganha 200ms de um total de 3.500ms. Trabalho descartado. Profiler-first, sempre.

Como medir o TTI antes de otimizar qualquer coisa

A regra que aplico em toda auditoria: se você não tem um número reproduzível, você não tem um problema. Instrumento o TTI em dois pontos. No lado nativo, capturo o timestamp da entrada do processo. No lado JS, capturo o timestamp assim que o componente raiz completa o primeiro onLayout significativo. A diferença é o TTI real, medido em wall-clock, não em percepção.

No Android, o ponto de partida é Application.onCreate(). Sobrescreva MainApplication.kt:

// android/app/src/main/java/com/seuapp/MainApplication.kt
class MainApplication : Application(), ReactApplication {
  companion object {
    var processStartMillis: Long = 0L
  }

  override fun onCreate() {
    processStartMillis = System.currentTimeMillis()
    super.onCreate()
    SoLoader.init(this, OpenSourceMergedSoMapping)
    if (BuildConfig.IS_NEW_ARCHITECTURE_ENABLED) {
      load()
    }
  }
}

No iOS, o gancho equivalente vive em AppDelegate.mm:

// ios/SeuApp/AppDelegate.mm
static NSTimeInterval processStartTime = 0;

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  processStartTime = [[NSDate date] timeIntervalSince1970];
  self.moduleName = @"SeuApp";
  return [super application:application didFinishLaunchingWithOptions:launchOptions];
}

Do lado JS, exponho os dois timestamps via um TurboModule custom (ou uso react-native-performance quando prefiro uma dependência pronta) e fecho a conta no primeiro InteractionManager.runAfterInteractions do root:

import { InteractionManager } from 'react-native';
import { NativeStartup } from './specs/NativeStartup';

export function HomeScreen() {
  useEffect(() => {
    InteractionManager.runAfterInteractions(() => {
      const tti = Date.now() - NativeStartup.getProcessStartMillis();
      NativeStartup.reportTTI(tti);
      console.log(`[perf] TTI: ${tti}ms`);
    });
  }, []);
  return <YourUI />;
}

Rode em release build (não em debug, porque o Metro sozinho adiciona 800ms falsos) em um dispositivo real de gama média. Meu setup padrão: Pixel 6a e iPhone 13, ambos com cache limpo (adb shell pm clear, kill do app pelo simulador). 10 medições, descarta max e min, calcula P50 e P95. Só então começo a otimizar.

Profiling com o Performance Panel do React Native DevTools 0.83

O Performance Panel, lançado no React Native 0.83, foi o que finalmente me fez aposentar o Perfetto para 80% dos casos de cold start. Ele traz três coisas que o Flipper nunca teve: flame chart do JS thread com nomes de função Hermes, CPU throttling nativo (4×, 6×) para simular dispositivos de baixa gama sem precisar de um Redmi na mesa, e marks customizados via performance.mark() que aparecem alinhados com os eventos do React Scheduler.

Para abrir o painel, rode o app em release-ish (use --variant release --active-arch-only no Android para ter símbolos Hermes) e pressione j no terminal do Metro. Aba Performance, clique em Record, mate o app, reabra, pare o trace após 8 segundos. O que você quer procurar:

• Long tasks acima de 100ms no JS thread durante o load. Cada uma é um módulo pesado sendo avaliado. Passe o mouse para ver o require() responsável.
• Gaps entre o final do bundle eval e o primeiro commit do React. Geralmente indica trabalho síncrono no root component (contexts que fazem I/O, providers que fazem fetch).
• Frames vermelhos no track "Main" após o first paint. Significa que animações de entrada estão brigando com o React Commit por CPU.

Sempre adiciono marks customizados nos limites lógicos para ler o trace mais rápido:

// index.js
performance.mark('bundle_start');
import { AppRegistry } from 'react-native';
import App from './App';

performance.mark('app_import_end');
performance.measure('bundle_eval', 'bundle_start', 'app_import_end');

AppRegistry.registerComponent('SeuApp', () => App);
performance.mark('registered');

Esses marks aparecem no timeline do Performance Panel como bandeirinhas coloridas, o que economiza minutos comparando timestamps na mão. Para uma comparação mais ampla das ferramentas modernas de instrumentação, incluindo o Radon IDE e o Sentry Mobile, dá uma olhada na discussão de arquitetura em Nova Arquitetura React Native 2026. Muito do que aparece no trace só faz sentido depois de entender bridgeless mode e JSI.

Ativando o Hermes V1 no React Native 0.84

Hermes V1, o engine JavaScript padrão desde a release 0.84 do Hermes, é o maior ganho de TTI de um único flag em 2026. A diferença para JSC é que Hermes pré-compila seu JS em bytecode no build time, então a fase de parse (que consome 400 a 1.200ms em bundles de 4 a 8MB em Android de gama média) some completamente. Nos meus benchmarks internos, migrar de JSC para Hermes V1 em um app de 6MB derrubou o TTI de 3.4s para 1.9s em um Redmi Note 12.

Em RN 0.84, Hermes V1 é default. Verifique em android/gradle.properties:

# android/gradle.properties
hermesEnabled=true
newArchEnabled=true

E em ios/Podfile (a partir do 0.84 não é mais necessário passar a flag, mas confirme):

# ios/Podfile
use_react_native!(
  :path => config[:reactNativePath],
  :hermes_enabled => true,
  :fabric_enabled => true
)

Depois do build, valide que o bytecode foi gerado. O arquivo index.android.bundle deve começar com 0xC61FBC03 (magic number Hermes). Um erro que vejo com frequência é o time incluir uma dependência com eval() ou new Function(), o que força Hermes a cair de bytecode para modo interpretado e apaga metade do ganho. Honestamente, esse foi um bug que me custou meio dia de debugging num app de fintech em 2025. Depois disso passei a rodar npx react-native-hermes-check depois de cada upgrade de dependência maior para pegar esses regressos.

Hermes V1 também trouxe o Hermes Sampling Profiler nativo, exposto via HermesInternal.enableSamplingProfiler(). Uso em conjunto com o Performance Panel quando o flame chart mostra uma função opaca chamada native. O sampling profiler abre a chamada e mostra o JS real por trás.

Inline requires no Metro: o ganho mais barato

Por padrão, o Metro empacota todos os import no topo dos arquivos, o que significa que o JavaScript engine avalia o mundo inteiro no cold start. inlineRequires reescreve as chamadas require() para o ponto de uso, transformando avaliação eager em lazy. Em um app com 1.500 módulos, isso corta 300 a 500ms sem mudança de código.

Ative em metro.config.js:

// metro.config.js
const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');

const config = {
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
};

module.exports = mergeConfig(getDefaultConfig(__dirname), config);

Depois de ativar, sempre rodo uma medição comparativa. Em um projeto recente, o TTI P50 caiu de 2.480ms para 2.030ms, ou seja, 450ms de ganho para uma linha alterada. Mas atenção: inlineRequires pode quebrar módulos com side effects no topo do arquivo (registro de listeners, polyfills). Se sua analytics library depende de require('./analytics') executar no bundle load, ela vai ativar só na primeira chamada. A solução é forçar o import cedo em index.js:

// index.js, força side effects críticos
import './setup/polyfills';
import './setup/analytics';
import { AppRegistry } from 'react-native';
import App from './App';
AppRegistry.registerComponent('SeuApp', () => App);

Para bundles maiores que 8MB, considero também RAM Bundles (ram-bundle): o Metro divide o bundle em módulos separados carregados sob demanda pelo runtime. Ganho adicional de 200 a 400ms, mas custa complexidade de deploy. Só aplico quando inlineRequires sozinho não bate a meta.

Lazy loading de TurboModules na Nova Arquitetura

Antes da Nova Arquitetura, o React Native chamava getConstants() em todos os módulos nativos registrados no startup, ou seja, Camera, Bluetooth, Contacts, Geolocation, mesmo que o usuário nunca abrisse a câmera. Em um app típico, isso significava 40 a 80 módulos inicializando síncronos, cada um custando 5 a 25ms. TurboModules matam esse desperdício: um módulo só é instanciado quando o JS chama NativeCameraModule.takePicture() pela primeira vez.

Para colher esse benefício, você precisa: (1) estar na Nova Arquitetura (newArchEnabled=true), (2) declarar seus módulos custom via Codegen, (3) evitar chamar NativeModules.SeuModulo no bundle load. O terceiro item é o mais violado. Vejo com frequência algo assim em App.tsx:

// ANTI-PADRÃO, força o carregamento do TurboModule no bundle load
import { NativeModules } from 'react-native';
const { CameraKit } = NativeModules;
const DEVICE_CAMERAS = CameraKit.getAvailableCameras(); // avaliado no import

export default function App() { ... }

Isso derrota o lazy loading. O padrão correto move a chamada para dentro do componente que precisa:

// CORRETO, TurboModule carrega só quando a tela da câmera monta
import { useEffect, useState } from 'react';
import NativeCameraKit from './specs/NativeCameraKit';

export function CameraScreen() {
  const [cameras, setCameras] = useState([]);
  useEffect(() => {
    NativeCameraKit.getAvailableCameras().then(setCameras);
  }, []);
  return <CameraView cameras={cameras} />;
}

Combinado com React.lazy() na navegação, você garante que a tela da câmera (e seu TurboModule) só entre no bundle no momento em que o usuário toca no ícone da câmera. Nos benchmarks públicos da Meta, esse padrão sozinho reduziu o TTI do app do Facebook em 50% versus o bridge antigo. Para uma visão profunda de Codegen e specs, o guia da Nova Arquitetura cobre o pipeline completo de migração.

Deferindo trabalho não crítico com InteractionManager

Nem todo trabalho de startup precisa acontecer antes do primeiro paint. Analytics, remote config, verificação de update, warm-up de caches, prefetch de assets: nada disso é observável pelo usuário nos primeiros 500ms depois que a tela aparece. Se você move esse trabalho para depois do TTI usando InteractionManager.runAfterInteractions, o JS thread fica livre para responder ao primeiro toque.

// App.tsx
import { InteractionManager } from 'react-native';

useEffect(() => {
  const task = InteractionManager.runAfterInteractions(() => {
    initAnalytics();
    prefetchRemoteConfig();
    warmUpImageCache();
    checkForUpdate();
  });
  return () => task.cancel();
}, []);

Um erro sutil: runAfterInteractions só espera animações declaradas via InteractionManager.createInteractionHandle. Se você tem uma animação Reanimated na tela de splash e não declarou o handle, o callback dispara imediatamente. Para animações da Reanimated 4, use runOnJS no onFinished do worklet para sinalizar o fim manualmente.

No meu último cliente, mover a inicialização do Firebase Remote Config para depois do TTI derrubou o cold start P95 em 1.500ms (cache-first no launch, fetch fresco em background). Foi um daqueles ganhos absurdos por 15 minutos de refactor, e desde então virou item de checklist. O padrão está descrito com mais detalhes na documentação oficial do Firebase Remote Config loading strategies.

Splash screen nativo e handoff sem white flash

A maioria dos apps React Native tem um white flash de 300 a 800ms entre o splash do sistema e o primeiro paint do React. A causa é conhecida: o splash JS-based só aparece depois que a bridge/JSI sobe e o bundle é avaliado, e enquanto isso o Android/iOS mostra a activity/view root, que é branca. A solução é fazer o splash na camada nativa e só remover quando o React sinalizar readiness.

Uso expo-splash-screen em projetos Expo e react-native-bootsplash em bare workflow. Setup do handoff correto:

// App.tsx
import * as SplashScreen from 'expo-splash-screen';
import { useEffect, useState } from 'react';

SplashScreen.preventAutoHideAsync();

export default function App() {
  const [ready, setReady] = useState(false);

  useEffect(() => {
    (async () => {
      await Promise.all([
        loadFonts(),
        hydrateInitialState(),
      ]);
      setReady(true);
      await SplashScreen.hideAsync();
    })();
  }, []);

  if (!ready) return null;
  return <RootNavigator />;
}

O truque é que preventAutoHideAsync mantém o splash nativo visível até você chamar hideAsync. Durante todo esse tempo, o React já montou mas está por trás do splash. Zero white flash. Para uma experiência premium, animo o splash usando Rive ou Lottie na camada nativa (via react-native-bootsplash) e sincronizo com uma micro-animação no primeiro frame do React usando shared elements. A transição fica invisível.

Metas de cold start para apps de produção em 2026

Depois de otimizar dezenas de apps, essas são as metas que uso como linha de corte. Se seu app está abaixo desses números, você está entre os 10% melhores da categoria:

Métrica	Meta (P50)	Meta (P95)	Como medir
TTI iPhone 13	< 1.2s	< 1.8s	Instruments / Native timestamps
TTI Pixel 6a	< 2.0s	< 3.2s	Perfetto / Native timestamps
TTID cross-platform	< 0.8s	< 1.4s	Performance Panel mark
JS bundle size (Hermes bytecode)	< 3.5MB	—	ls -lh index.android.bundle
Install size (APK/IPA)	< 30MB	—	Play Console / App Store Connect
Sustained FPS pós-TTI	60 FPS	58+ FPS	PerformanceObserver('frame')

Depois que o TTI está resolvido, o próximo gargalo tende a migrar para renderização de listas. Faz sentido, porque a maioria dos apps modernos mostra uma lista logo no home. Se você usa FlatList, uma migração para FlashList v2 ou LegendList tipicamente adiciona 10 a 15 FPS no scroll. Cobri esse trade-off com traces reais no guia comparativo de FlatList, FlashList v2 e LegendList.

Uma última observação sobre CI: coloque essas metas como budgets no seu pipeline. Uso bundlesize para o JS bundle e um script custom que roda o app em um emulador Pixel 6a headless, mede o TTI e falha o build se ultrapassar 2.5s. Sem gating automatizado, o TTI vaza uma feature por vez até você acordar com 4s de cold start e um cliente irritado. Regressão de performance é como dívida técnica: acumula em silêncio e cobra juros compostos.

Perguntas frequentes

Qual é um bom tempo de cold start para um app React Native em 2026?

Aponte para TTI P50 abaixo de 1.2s em iPhone 13 e abaixo de 2.0s em um Pixel 6a. Apps que passam de 3s no P95 em Android de gama média perdem 15 a 25% de retenção D1 segundo dados do Play Console.

O Hermes V1 realmente reduz o tempo de inicialização?

Sim. Hermes V1 pré-compila JavaScript em bytecode no build time, eliminando a fase de parse que consome 400 a 1.200ms em bundles de 4 a 8MB. Nos meus benchmarks, migrar de JavaScriptCore para Hermes V1 reduziu o TTI de 3.4s para 1.9s em um Redmi Note 12, um ganho de 44%.

Como faço para habilitar inline requires no Metro?

Adicione inlineRequires: true dentro de getTransformOptions no metro.config.js. Depois valide side effects críticos (polyfills, registro de analytics) forçando o import em index.js, porque módulos com side effects no topo do arquivo podem quebrar ao serem lazy-loaded.

Preciso migrar para a Nova Arquitetura para reduzir cold start?

Não é obrigatório, mas é o maior ganho estrutural disponível. TurboModules substituem a inicialização síncrona de todos os módulos nativos por lazy loading sob demanda, o que sozinho corta 20 a 40% do TTI em apps com muitos módulos. Desde a RN 0.82 o bridge antigo foi retirado, então novos projetos já nascem na Nova Arquitetura.

O Performance Panel do React Native DevTools funciona em builds release?

Funciona, e é onde você deve medir. Rode um build release com JS bundle Hermes e conecte o Performance Panel via Metro (pressione j). Habilite CPU throttling 4× ou 6× para simular dispositivos de gama média. Profiling em Mac M3 sem throttling gera traces que mentem sobre a experiência real do usuário.

Como o splash screen nativo elimina o white flash?

O white flash acontece porque o splash JS-based só aparece depois que a JSI e o bundle terminam de carregar. Movendo o splash para a camada nativa com expo-splash-screen ou react-native-bootsplash e chamando preventAutoHideAsync, você mantém o splash visível até o React sinalizar readiness. O handoff acontece sem intervalo branco.