Problem
On native, opening the SearchRouter runs a ~300ms native-stack push animation, and the autocomplete list is deliberately deferred until the transition ends. The JS thread is mostly idle during that animation, and only after it does the list mount and pay the full createFilteredOptionList cost. On large accounts this is the dominant JS cost of the first open in a session (later opens hit the module-level cache added in #95378).
Solution
Warm the SearchRouter options cache during the open animation instead of after it, by mounting a render-less cache warmer next to the skeleton while the animation runs. It calls useFilteredOptions with exactly the same configuration as SearchAutocompleteList, producing an identical cache key, so by the time the real list mounts the options are already computed.
The warmer mounts only when the skeleton has laid out (never delays the first paint), the screen is focused, and the query is empty. If Onyx data changes between warm-up and list mount, the cache misses and behavior is byte-identical to today. Web is untouched.
Impact
First open per app session on native. Measured on a heavy account (Android emulator, dev build): −606ms median (−22.3%) for SearchRouter.ListRender. Later reopens already hit the cache from #95378 and are unaffected.
Tracking PR: #97246
Issue Owner
Current Issue Owner: @sumo-slonik
Problem
On native, opening the SearchRouter runs a ~300ms native-stack push animation, and the autocomplete list is deliberately deferred until the transition ends. The JS thread is mostly idle during that animation, and only after it does the list mount and pay the full
createFilteredOptionListcost. On large accounts this is the dominant JS cost of the first open in a session (later opens hit the module-level cache added in #95378).Solution
Warm the SearchRouter options cache during the open animation instead of after it, by mounting a render-less cache warmer next to the skeleton while the animation runs. It calls
useFilteredOptionswith exactly the same configuration asSearchAutocompleteList, producing an identical cache key, so by the time the real list mounts the options are already computed.The warmer mounts only when the skeleton has laid out (never delays the first paint), the screen is focused, and the query is empty. If Onyx data changes between warm-up and list mount, the cache misses and behavior is byte-identical to today. Web is untouched.
Impact
First open per app session on native. Measured on a heavy account (Android emulator, dev build): −606ms median (−22.3%) for
SearchRouter.ListRender. Later reopens already hit the cache from #95378 and are unaffected.Tracking PR: #97246
Issue Owner
Current Issue Owner: @sumo-slonik