Comment by zffr
2 days ago
> Our apps are blazing fast (<500ms screen loads)
I’m not sure I would consider 0.5 seconds to be blazing fast.
I wish the article went into detail on what these screens do and what a screen load means exactly.
2 days ago
> Our apps are blazing fast (<500ms screen loads)
I’m not sure I would consider 0.5 seconds to be blazing fast.
I wish the article went into detail on what these screens do and what a screen load means exactly.
You'd hope they benchmarked the old native iOS app and the RN app.
Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason).
Looking at a previous blog post, the first hunch seems to be correct - the second may also be true.
From 2024 March, https://shopify.engineering/improving-shopify-app-s-performa... talks about how their RN-ified app was loading screens in 1400ms (P75) and the steps they took to reduce that to 500ms.
I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
Right after that, they have three links (one blog post, two videos) to explanations of how they optimized screen load speed that can answer that question.
It's a mix of layout stuff (like using lazy list views to avoid below the fold rendering) and network fetches (they talk about using better caching).
That was my initial thought as well. Anyone know what native screen loads typically are? I’m sure it varies wildly between apps, but 500ms seems like it would be on the slower end of a “fast” app.
It really depends on what a "screen load" means exactly. If its just rendering the screen from some client-side data then I would expect something <16ms. To support 120fps displays, it would need to be <8ms.
If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
> Anyone know what native screen loads typically are?
500ms sounds about right for a cold launch but otherwise is pretty poor.
50-100ms for "minor" screen changes and 100-200ms for "major" ones are otherwise reasonable for native screens.
For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.)
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
> Keeping UI rendering under 16ms is the gold standard for native apps.
No, it isn't.
If you're not including the actual rendering, so the actual code of the app only or at least only the code on the UI thread, the targets are much smaller. More like 3-6ms/frame.
If you're including rendering then pipelining and 90hz+ being common still changes that anyway.
> Keeping UI rendering under 16ms is the gold standard for native apps.
Not since they’ve started releasing 120hz screens.
For reference, our app is 100% in Jetpack Compose, our screen rendering for both cold and warm are in the average of ~460-480ms. App start is around ~480ms.
If your warm and cold starts are that close I'take a closer look at your measurement methodology. Could be your cold starts are actually warm, or your timing is starting late.