1. Measure the screen before changing random code
A slow screen can be caused by rendering, image size, API latency, JavaScript work, native bridge pressure or device limitations. Guessing often creates new complexity without fixing the real bottleneck.
Start by identifying when the app feels slow: first load, scroll, typing, navigation transition, image load or mutation feedback.
- Test on a realistic low or mid-range device.
- Separate API time from render time.
- Record whether slowness appears in development or production builds.
- Watch memory pressure when screens use many images.
- Measure again after each meaningful change.
2. FlatList needs a data and rendering contract
FlatList can handle large lists, but it still needs stable keys, reasonable item components and pagination or windowing decisions. If every row receives new props on every render, scrolling becomes more expensive than it should be.
The list contract should define item identity, empty state, loading state, refresh behavior and how much data each row needs.
- Use stable keys that represent the real item identity.
- Keep row components focused and memoizable when useful.
- Avoid passing new inline objects and functions everywhere.
- Paginate or limit data when the API can return too many records.
- Define clear empty, loading and error states for the list.
3. Images and payloads often explain the visible delay
A mobile screen that renders many large images can feel slow even if the JavaScript is well written. The same happens when an API returns full objects while the list needs only a title, status and thumbnail.
Performance improves when the backend and frontend agree on screen-specific data needs.
- Use image sizes appropriate for the display area.
- Prefer thumbnails in lists and full images only on detail screens.
- Avoid loading hidden images before the user needs them.
- Review API payload size for list endpoints.
- Cache images and data according to product freshness needs.
4. Treat performance as a release routine
A screen can be fast today and slow after a feature adds one more field, image or query. That is why performance should be checked on critical flows before releases, not only after complaints.
A small repeatable checklist is better than occasional heroic optimization.
- Include one performance smoke check in release validation.
- Track slow screens mentioned by users or support.
- Keep analytics for critical flow completion and abandonment.
- Review crash and memory signals after rollout.
- Simplify UI work before adding advanced optimization patterns.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.