Optimizing Network Requests: How to Reduce Screen Load Time?
The main screen of an app makes 14 parallel requests when opened. Seems fast—parallel means quick, right? But HTTP/1.1 limits to 6 connections per host, so 8 requests queue up. On a weak LTE connection with 180 ms RTT, total wait time exceeds 2 seconds. Each second of delay reduces conversion by 7% and retention by 20%. Revenue losses from slow screens can reach millions of rubles monthly.
Switching to HTTP/2 with multiplexing or aggregating requests on a BFF layer (Backend for Frontend) solves this without client-side changes. HTTP/2 multiplexes requests over a single connection, eliminating head-of-line blocking. Our engineers apply both approaches depending on the architecture.
Where Is Time Lost?
Extra requests. The most common issue is lack of client-side caching. URLSession on iOS respects Cache-Control headers by default, but only if the server sets them. If the API returns Cache-Control: no-store "for reliability," every call to reference data (categories, settings, configuration) goes over the network. URLCache with a 50 MB limit and manual URLRequest.cachePolicy = .returnCacheDataElseLoad for read-only endpoints works as a quick fix.
Overweight payloads. A REST endpoint for a user list returns 40 fields, but the UI uses only 4. With a list of 100 items, that's an extra 60–80 KB of JSON per request. GraphQL solves this at the protocol level, but if GraphQL isn't an option, ?fields=id,name,avatar_url as a query parameter for field filtering partially mitigates the issue.
Redundant requests on screen rotation. On Android, ViewModel + LiveData/StateFlow holds the result and doesn't re-run the request when the Activity is recreated. But if the request lives in Fragment.onViewCreated without a check, every rotation triggers a new network call. Diagnose it with Charles Proxy or OkHttp EventListener with logging.
Tools and Solutions: Which Approach to Choose?
iOS (URLSession / Alamofire / Moya)
Alamofire RequestInterceptor is a convenient place for retry logic with exponential backoff:
func retry(_ request: Request, for session: Session, dueTo error: Error, completion: @escaping (RetryResult) -> Void) { let delay = min(pow(2.0, Double(request.retryCount)), 30.0) completion(.retryWithDelay(delay)) } URLSession with waitsForConnectivity = true makes requests automatically wait for network recovery instead of failing immediately. Critical for offline-first apps.
Android (OkHttp / Retrofit)
OkHttp CacheInterceptor is built in; just pass a Cache when creating the client:
val cache = Cache(context.cacheDir, 50L * 1024 * 1024) val client = OkHttpClient.Builder().cache(cache).build() Retrofit + suspend fun cancels requests automatically when the coroutine scope is destroyed. The key is to bind the scope to viewModelScope, not GlobalScope.
Request Deduplication
If several components request the same resource simultaneously, execute the request only once. On iOS, use Combine’s share() operator on a Publisher. On Android, use StateFlow in a Repository: the first subscriber triggers the request, and subsequent subscribers receive the result from the same flow. This aligns with Apple Human Interface Guidelines on responsiveness.
Request Prioritization
On iOS, URLSession supports URLRequest.networkServiceType: .responsiveData for user actions, .background for analytics and prefetch. The system prioritizes traffic accordingly—analytics doesn't compete for bandwidth with user requests.
On Android, WorkManager with NetworkType.CONNECTED and priority EXPEDITED vs. normal allows background data sync without blocking the main request flow.
How to Set Up Caching: Step-by-Step Guide
- Identify read-only endpoints (directories, categories, configuration).
- Check if the server sends
Cache-Control. If not, force client-side caching. - On iOS, set up URLCache with a 50 MB limit and
cachePolicy = .returnCacheDataElseLoad. - On Android, create OkHttp Cache of 50 MB and pass it to OkHttpClient.
- For dynamic data, use ETag or Last-Modified: the client sends
If-None-Match, the server responds with304 Not Modified, saving bandwidth.
Comparison of HTTP/1.1 and HTTP/2
| Characteristic | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Connections per host | 6 (typical) | 1 (multiplexed) |
| Head-of-line blocking | Yes (request queue) | No (streams within connection) |
| Server push | No | Yes (server push) |
| Header compression | No | HPACK |
| Load time on slow LTE (14 requests) | >2 s | ~600 ms |
HTTP/2 yields a 3-4× improvement on weak networks by eliminating queues.
Case Study: GraphQL N+1 on Mobile
From our practice: an app used GraphQL, but queries were built "as convenient"—a separate query for each card in the list when viewing details. 20 cards = 20 queries. Implementing the DataLoader pattern on the client via @defer directive (supported by Apollo iOS / Apollo Android) allowed batching requests. Detail screen load time dropped from 2.8 s to 0.6 s. Our team's experience shows this approach is also applicable to REST via BFF.
Comparison of Caching Strategies
| Approach | iOS | Android | Traffic reduction | Complexity |
|---|---|---|---|---|
| URLCache / OkHttp Cache | URLCache + cachePolicy | OkHttp Cache | up to 70% | Low |
| Disk-based + memory | + | + | up to 90% | Medium |
| ETag / Last-Modified | URLSession default | OkHttp default | up to 50% with 304 | Low |
| Pragma / Cache-Control | Configurable | Cache-Control | up to 80% | Medium |
Common Mistakes in Network Request Optimization
- Forgetting to configure Cache-Control on the server, which makes caching ineffective. - Using a single HTTP client for all requests without considering priorities. - Not testing on weak networks—LTE simulation is mandatory. - Making requests on every screen redraw instead of in ViewModel creation.What’s Included in the Work?
- Audit of the current network layer with timing measurements and traffic analysis.
- Implementation of HTTP/2 or aggregation on BFF.
- Caching setup (URLCache, OkHttp Cache, ETag).
- Request deduplication and batching.
- Payload optimization (GraphQL or field filtering).
- Retry logic and prioritization.
- Documentation and recommendations for ongoing maintenance.
Contact us to order a network layer audit—we'll assess your project in one day.
Why Choose Us?
We have 5+ years of experience in mobile app optimization for iOS and Android. We've completed over 50 projects focused on load speed, caching, and traffic reduction. After the audit, you'll receive concrete recommendations with measurable metrics. Submit a request for an audit and get a detailed report with metrics.
Timeline
Network layer audit and targeted optimizations: 3–5 days. Implementing caching, retry logic, and deduplication across the entire app: 1–2 weeks. Get a consultation—we'll calculate exact timelines for your project.