Beyond image compression and lazy loading, here are battle-tested techniques — offline-first sync, request coalescing, and progressive skeletons — for building web apps that perform on 2G/3G networks.

Designing Low-Bandwidth UX: A Practical Checklist for African Web Apps

Most performance guides are written with a 4G LTE baseline in mind. Compress your images. Lazy-load below the fold. Done. But if your users are in Kumasi, Kisumu, or Kano — or anywhere a 2G signal is the norm between 8 AM and 6 PM — that checklist falls embarrassingly short.

This guide goes deeper. It is a practitioner's reference for engineers and product teams building web applications for African markets, where network conditions are variable, data costs are real, and a three-second delay can end a user session permanently.

1. Stop Treating "Offline" as an Edge Case

On a stable fiber connection, offline is an exception. On a congested urban tower or a rural 2G mast, it is Tuesday afternoon.

Offline-first architecture means your application is designed to function without a live connection as its default assumption, and syncs opportunistically when bandwidth is available. The practical implementation looks like this:

Use IndexedDB (via libraries like Dexie.js) to persist application state locally.
Queue all write operations — form submissions, cart additions, content saves — and replay them when connectivity is confirmed.
Use Service Workers to cache API responses and serve stale-while-revalidate content, keeping the UI responsive even when the network is not.

// Register a background sync for queued form submissions
self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-pending-orders') {
    event.waitUntil(flushPendingOrders());
  }
});

The key mindset shift: your app should be ready to go offline, not graceful when it happens.

2. Request Coalescing: Fewer Trips, More Data per Trip

Every HTTP round trip on a high-latency connection is expensive. A 2G connection in Ghana can have latency exceeding 500ms. If your app fires seven separate API calls on load, you are spending over three seconds just in handshakes before a single byte of useful data arrives.

Request coalescing batches multiple data fetches into a single request.

Practical approaches:

GraphQL is a natural fit — one query, one round trip, precisely shaped data.
If you are on REST, implement a batch endpoint (/api/batch) that accepts an array of sub-requests and returns aggregated responses.
Use HTTP/2 multiplexing to reduce head-of-line blocking where possible, but do not rely on it alone — the round-trip problem is in the radio layer, not the protocol.
Aggressively prefetch data you can predict. If a user opens a product listing, start fetching the first three product detail pages immediately.

Reducing seven round trips to two on a 500ms latency connection is a 2.5-second improvement. That is not a micro-optimisation — that is the difference between a bounce and a conversion.

3. Progressive Skeleton Screens Done Right

Skeleton screens are widely misunderstood. Slapping a grey rectangle on the screen and calling it "loading state" does not improve perceived performance — it just makes the wait visible. Done correctly, skeleton screens create the illusion of momentum.

The right approach:

Render skeleton shapes that closely mirror the actual content geometry. A skeleton for a product card should have the same aspect ratio, heading height, and price-tag block as the real card.
Populate skeletons progressively. As each data fragment resolves, replace the corresponding skeleton section — do not wait for the entire payload to fill the whole screen at once.
Combine skeletons with stale content. If the user has visited before and you have a cached version of the data, show the old content immediately, then animate a subtle update when fresh data arrives. This is the Netflix and Twitter approach, and it eliminates perceived loading time almost entirely on repeat visits.

Avoid spinners for anything expected to take longer than 300ms. Spinners communicate waiting; skeletons communicate structure and progress.

4. Compress Aggressively at Every Layer

You already know about WebP images. Here is what teams often miss:

Brotli compression for text assets (HTML, CSS, JS, JSON) outperforms gzip by 15–25%. Most modern CDNs support it. Enable it.
Font subsetting: If you are loading a Latin-extended Google Font for a Twi or Hausa UI that only uses a fraction of those glyphs, you are wasting bandwidth. Use unicode-range to subset fonts or self-host pre-subsetted WOFF2 files.
JSON diet: API responses grow fat over time. Audit your payloads. Remove deprecated fields, use short property names for high-frequency responses, and consider binary formats like MessagePack for mobile-heavy endpoints.
Differential/delta updates: Instead of re-fetching full datasets, implement endpoints that return only records changed since a given timestamp. This matters enormously for sync-heavy apps.

5. Design for Expensive Data, Not Just Slow Networks

A 500MB data bundle in Nigeria costs roughly the same as a meal. Your users are not just impatient — they are making economic decisions about whether to engage with your product.

Show data usage estimates before large operations ("This will use approximately 3MB").
Provide lite modes that strip non-essential media. WhatsApp and YouTube both do this. So should you.
Default to low-resolution assets, with opt-in for high quality. Do not make users configure this — detect navigator.connection.effectiveType and serve accordingly.
Avoid auto-playing video or audio under any circumstance.

6. Test on Real Conditions, Not DevTools Throttling

Chrome DevTools' network throttling is useful for rough simulation, but it does not replicate packet loss, radio interference, or the burst-and-stall pattern of a congested cell tower. Use real devices on real SIMs.

Maintain a QA checklist that includes:

Testing on a mid-range Android device (the Tecno Spark / Infinix tier dominates African markets).
Testing at peak hours (12 PM–2 PM and 6 PM–9 PM) when towers are most congested.
Measuring Time to Interactive and Cumulative Layout Shift, not just page load time.
Running Lighthouse with a mobile preset, targeting a score above 85 on performance.

Why This Matters for Your Project

Building for low-bandwidth users is not a charity exercise — it is a market reality for any SaaS or web product targeting African consumers or SMEs. The techniques above — offline-first sync, request coalescing, progressive skeletons, and data-conscious defaults — compound into a UX that feels fast and respectful regardless of network conditions. Teams that treat performance as a first-class feature from day one spend far less time retrofitting it later, and they build products that earn trust in markets where trust is hard won and easily lost.