When Your App's Launch Got Quietly Slower Release After Release — Field Notes on TTI Instrumentation and a Startup Budget for Rork Apps

Find where it came from

Once the numbers are tied to releases, the regression graph reveals its shape. What looks like a smooth decline is usually a staircase — one specific release stepped up. Go read the diff of the version where the step appeared.

The culprits I actually hit were nearly the same cast every time. Here are the three I kept running into in production.

Synchronous work at the root stalls launch

Synchronous work during module evaluation at the root. Libraries that build a heavy object the instant you import them, or code that requires a large JSON at the top level, block the JS thread before anything has rendered. The example below is the classic mistake of putting "runs just by being loaded" work on the launch path.

// ❌ Always runs at launch (evaluated even if the screen doesn't need it)
import heavyCatalog from '../assets/catalog.json'; // unpacks hundreds of KB at boot
const prebuiltIndex = buildSearchIndex(heavyCatalog); // synchronous and heavy
 
// ✅ Build lazily, once, on the screen that needs it
let _index: SearchIndex | null = null;
export async function getSearchIndex() {
  if (_index) return _index;
  const { default: catalog } = await import('../assets/catalog.json');
  _index = buildSearchIndex(catalog);
  return _index;
}

Keep SDK init off the launch path

Lining up SDK initialization on the launch path. Ads, analytics, crash reporting, remote config — initialize them all at root mount and they jam up right before TTI. Crash reporting is worth bringing up first; ads and most analytics can wait until after the first interaction.

import { InteractionManager } from 'react-native';
 
// Run init once the first interaction has settled
function deferNonCriticalInit() {
  InteractionManager.runAfterInteractions(() => {
    initAds();            // not needed to paint the first screen
    initAnalyticsQueue(); // buffer events and flush later
    warmRemoteConfig();
  });
}

Don't let the first screen carry too much

The first screen carrying too much. I once had a five-tab app fetching data for every tab at launch. Only one tab was visible, yet the network and formatting for the other four were dragging TTI down. Prepare synchronously only what the first screen truly needs, and fetch the rest after it appears. Obvious in principle, easy to break as features accumulate.

Hermes and the New Architecture: manage them so you don't lose them

Performance advice often says "enable Hermes" and "migrate to the New Architecture." On 2026-era Expo / React Native, these are largely on by default. So the task is less about adding them and more about checking that you haven't quietly turned the defaults off by tweaking config or adding an incompatible legacy library.

It's reassuring to confirm once before release that they're in effect as expected.

// app.json (via expo-build-properties)
{
  "expo": {
    "plugins": [
      ["expo-build-properties", {
        "android": { "newArchEnabled": true },
        "ios": { "newArchEnabled": true }
      }]
    ]
  }
}

Hermes precompiles JS to bytecode, cutting parse cost at launch. Disable it unintentionally and cold start gets visibly heavier. Once you've taken the detour of "a setting I touched for performance actually removed a default benefit," this check becomes a habit.

Use the splash to make people wait, not to hide slowness

Trying to make launch look fast with a splash screen backfires over time. Painting over the non-interactive window with a splash doesn't shrink TTI; if anything it manufactures the "it launched but won't respond" state.

The right move is to drop the splash only at the moment the app is genuinely interactive.

import * as SplashScreen from 'expo-splash-screen';
 
SplashScreen.preventAutoHideAsync();
 
export default function Root() {
  const [ready, setReady] = useState(false);
 
  useEffect(() => {
    (async () => {
      // Wait only for what the first screen truly needs (not everything)
      await loadCriticalData();
      setReady(true);
    })();
  }, []);
 
  const onLayout = useCallback(async () => {
    if (ready) await SplashScreen.hideAsync(); // after the layout is ready
  }, [ready]);
 
  if (!ready) return null;
  return <AppShell onLayout={onLayout} />;
}

Put only "what the first paint of the first screen requires" into loadCriticalData. Mix deferrable init in here and the splash lingers, and the felt experience gets worse.

Put a startup budget in CI so it never slides again

Left alone, all the measuring and fixing above returns to the same place. Since adding features is development, launch trends heavier whenever you do nothing. So the last step is a mechanism that stops the regression before a human notices.

What worked best was fixing the initial bundle-size ceiling in CI. When the bundle swells, the download and JS load ride straight into launch.

// scripts/check-startup-budget.js
const fs = require('fs');
 
const BUDGET = {
  bundleBytes: 2.6 * 1024 * 1024, // initial JS bundle ceiling
};
 
const size = fs.statSync('dist/_expo/static/js/index.hbc').size;
if (size > BUDGET.bundleBytes) {
  console.error(
    `Startup budget exceeded: ${(size / 1024 / 1024).toFixed(2)}MB ` +
    `> ${(BUDGET.bundleBytes / 1024 / 1024).toFixed(2)}MB`
  );
  process.exit(1); // fail the PR
}
console.log(`✅ Within startup budget: ${(size / 1024 / 1024).toFixed(2)}MB`);

If you can, also record on-device TTI p75 per release and warn when it worsens past a margin from the previous one. The threshold doesn't need to be precise. What matters is noticing in the same week the regression happens. Defending a little every release is far cheaper than letting it slip and clawing back six months at once.

In numbers: on the app I run, simply moving the root-level synchronous work and SDK init off the launch path shrank the cold-start p75 on my fixed test device by a felt amount. There was no dramatic single fix — I just pushed the "work I don't need right now" off the launch path, one item at a time. The real nature of launch optimization isn't a speed-up spell; it's deciding what not to make the app do at the moment of launch.

Start by measuring your current cold-start p75 on the slowest device you have. With just one baseline number, you can say whether the next release got faster or slower as a fact, not a feeling.