Designing for low-bandwidth: what African builders should know

Your product loads in 0.8 seconds on your MacBook Pro in Lekki. Your user in rural Kano opens it on a 2G connection and waits 45 seconds. They close the tab.

This isn't a hypothetical. Across Nigeria, Kenya, Uganda, and most of sub-Saharan Africa, a significant portion of internet traffic still moves over 2G networks. The GSMA Intelligence data consistently shows that while 4G and 5G coverage is expanding in urban centres, latency remains unpredictable and bandwidth constrained. In Nigeria alone, millions of users rely on networks that deliver speeds between 50-400 kbps-slower than most developers assume their users to be.

The consequence: if you build for fibre-speed connections, you're building for maybe 15% of your potential market. The other 85% will experience your product as broken. They won't blame the network. They'll blame you. This playbook teaches you how to design and build for the reality of African internet, not the fantasy of it.

Why low-bandwidth design matters for your bottom line

Let's start with business, not philosophy. Low-bandwidth design isn't about charity. It's about market capture.

When Paystack launched in Nigeria in 2015, they didn't assume every merchant had broadband. Their dashboard and payment flow were built to work on slower connections. When Flutterwave scaled across West Africa, the same principle held. When Moniepoint expanded from Lagos to Tier-2 cities, bandwidth constraints weren't an afterthought-they were a design parameter.

The numbers matter:

1. User retention rises dramatically. Studies from Cloudflare and HTTPArchive show that every additional second of load time costs you 7% of conversions. On a 2G connection, a 5MB page takes 40 seconds. A 500KB page takes 4 seconds. The difference between success and failure is often a single order of magnitude.

2. Data costs drop for your users. In Nigeria, a 1GB mobile data plan costs between ₦1,000-₦3,000 depending on the network and promo. A user who burns 50MB per session on your app is spending real money. Make them spend 5MB instead, and you've solved a genuine pain point. They'll use your product more often.

3. You unlock rural and secondary-market growth. Most African startups focus on Lagos, Accra, Nairobi-the metros. But 60-70% of the population lives outside major cities. Those users are on slower networks and have less disposable income. Low-bandwidth design lets you serve them profitably.

4. Your infrastructure costs fall. If your average page is 2MB, you need more server bandwidth. If it's 200KB, your hosting bill shrinks. Over time, this compounds. See Where to host your African startup: VPS vs serverless vs PaaS for more on how hosting choices interact with bandwidth constraints.

Measure your actual user experience, not your connection

Most founders test on their own machines or on Chrome DevTools throttling, which is useful but incomplete. You need to measure what real users experience.

Set up synthetic monitoring for 2G

Synthetic monitoring means running automated tests that simulate real user journeys on real networks. Don't just measure page load time. Measure:

• Time to First Byte (TTFB): How long until the user's browser receives the first byte from your server. High TTFB (>1 second on 2G) usually means server latency or network distance, not asset size.
• First Contentful Paint (FCP): When the user sees something meaningful on screen. On 2G, this should be under 3 seconds.
• Largest Contentful Paint (LCP): When the main content finishes rendering. Target under 5 seconds on 2G.
• Cumulative Layout Shift (CLS): How much the page jumps around as it loads. High CLS frustrates users and increases accidental clicks.

Tools like WebPageTest (webpagetest.org) let you test from servers in Nigeria, Kenya, and South Africa. Run a test from a Lagos location with a 2G connection profile. You'll see exactly what your users see.

Use real-device testing

Chrome DevTools throttling is a simulation. Real 2G networks have jitter, packet loss, and variable latency. If you can, grab a used Tecno or Infinix phone (the devices most of your users have), tether it to a 2G connection, and use your product as a user would.

In our experience at LaunchPad, founders who do this once are shocked. They discover features that seem instant on fibre are unusable on 2G. They find that their app crashes when the connection drops mid-request. They learn that animations they thought were delightful are actually stressful when they cause layout shifts.

Build for offline-first and progressive enhancement

On unstable networks, the connection will drop. Your product must handle it gracefully.

Progressive enhancement: assume nothing

Progressive enhancement means building your product to work at the most basic level first, then layering on features for better connections.

Example: a form submission. At the basic level:

1. User fills form and hits submit.
2. Form data is sent to the server.
3. Server responds with success or error.
4. Page reloads or redirects.

This works on any connection, including 2G. Now layer on enhancements:

• Use JavaScript to submit the form without a page reload (if JavaScript loads).
• Add client-side validation (if JavaScript loads).
• Add real-time field validation with debouncing (if the connection is fast enough).
• Add animations and transitions (if the device is powerful enough).

The key: every layer is optional. If JavaScript fails to load, the form still works. If the connection drops, the user's data isn't lost because the form uses <input> elements with name attributes, not a React state machine.

This principle applies to fintech apps like Kuda or OPay too. A transaction confirmation must work on 2G with JavaScript disabled. The fancy UI enhancements come after.

Implement offline-first caching

Service Workers let you cache assets and data locally, so your app works even when the network is down or extremely slow.

Basic strategy:

1. On first visit, cache the critical path: the HTML shell, core CSS, essential JavaScript.
2. Cache API responses aggressively. If the user requests their transaction history and the network is slow, serve yesterday's cached version while fetching fresh data in the background.
3. Queue user actions (like sending money or submitting a form) when offline. When the connection returns, sync them to the server.

Libraries like Workbox (from Google) make this easier. For a Nigerian startup, this is especially valuable: users in areas with spotty coverage can still use your app to draft messages, compose transfers, or fill out forms. When they reach a better connection, everything syncs.

Optimize assets ruthlessly

On a 2G connection (50-400 kbps), every kilobyte matters. Here's where most founders fail: they optimise images but leave bloated JavaScript untouched.

Images: the biggest culprit

Images often account for 50-70% of page weight. Optimise aggressively:

1. Use modern formats. WebP and AVIF compress 25-35% better than JPEG. Serve them with fallbacks:

   <picture>
     <source srcset="image.avif" type="image/avif">
     <source srcset="image.webp" type="image/webp">
     <img src="image.jpg" alt="description">
   </picture>
   

2. Serve responsive images. Don't send a 2000px-wide image to a 360px phone screen. Use srcset to serve the right size:

   <img srcset="small.jpg 480w, medium.jpg 800w, large.jpg 1200w" sizes="(max-width: 600px) 100vw, 50vw" src="medium.jpg" alt="">
   

3. Lazy-load images below the fold. Don't load images the user hasn't scrolled to yet:

   <img src="placeholder.jpg" data-src="real-image.jpg" loading="lazy" alt="">
   

4. Use a CDN with image optimisation. Cloudflare, Bunny CDN, or Statically can auto-optimise images on the fly. They detect the user's device and connection and serve the smallest viable version.

JavaScript: the hidden bloat

Many founders load entire frameworks for simple features. A common pattern: loading React (40KB gzipped) to render a dropdown menu.

Better approach:

1. Audit your bundle. Use webpack-bundle-analyzer or similar to see what's actually being shipped. You'll often find unused libraries.
2. Use native HTML and CSS first. A <select> dropdown works on any device, loads instantly, and requires zero JavaScript.
3. Load JavaScript conditionally. If a feature is only used by 10% of users, don't load it for everyone. Load it on-demand.
4. Consider lightweight alternatives. Instead of moment.js (67KB), use date-fns (13KB). Instead of lodash (71KB), use individual utilities or native methods.

For a startup following Ship your MVP in 2 weeks: a Nigerian founder's playbook, this is critical: you can't afford to spend two weeks optimising later. Build light from the start.

CSS and critical rendering path

1. Inline critical CSS. The CSS needed to render the above-the-fold content should be inlined in the <head>, so the browser can start rendering immediately.
2. Defer non-critical CSS. Load stylesheets for below-the-fold content asynchronously.
3. Minify and compress. Every byte counts. Use a build tool to minify CSS and JavaScript, and enable gzip compression on your server.

Choose the right tech stack for low-bandwidth

Your framework choice affects how much code ships to the user. See Tech stack choices for Nigerian startups in 2026 for a full breakdown, but here's the low-bandwidth angle:

Framework	Bundle Size (gzipped)	Best for low-bandwidth?	Notes
React	40-50KB	No	Powerful but heavy. Good for complex UIs.
Vue	30-35KB	Maybe	Lighter than React. Still requires JavaScript.
Svelte	12-16KB	Yes	Compiles to minimal JavaScript. Excellent for 2G.
Alpine.js	14KB	Yes	Lightweight interactivity without a build step.
htmx	14KB	Yes	Server-driven interactivity. Minimal client-side code.
Plain HTML + vanilla JS	Variable	Yes	No framework bloat. Requires discipline.

For a fintech app like Uni or Shamba, which need to work reliably on slow networks, Svelte or htmx with progressive enhancement is smarter than React. You get interactivity without the payload.

Backend optimisation: reduce round trips

Low bandwidth isn't just about file size. It's about latency. On a 2G connection, each HTTP request takes time just to establish the connection.

Batch requests and use GraphQL or JSON:API

If your frontend needs data from five different endpoints, that's five round trips. Instead:

1. Use GraphQL to fetch exactly what you need in one request.
2. Use JSON:API with include parameters to fetch related resources.
3. Create backend endpoints that batch common requests.

Example: a user's dashboard needs their account balance, recent transactions, and available offers. Instead of three API calls, create one /dashboard endpoint that returns all three.

Compress responses

Enable gzip or brotli compression on your server. This is often a checkbox in your hosting panel. A typical JSON response compresses 60-80%, which matters hugely on 2G.

Cache aggressively

Use HTTP caching headers (Cache-Control, ETag) so the browser doesn't re-download unchanged assets. For API responses, use short TTLs (5-10 minutes) for data that changes often, longer TTLs for static data.

Real-world examples from African startups

Paystack

Paystack's dashboard works on 2G because they:

• Keep the initial page load to under 200KB of assets.
• Use server-side rendering for the first paint, so users see content before JavaScript loads.
• Lazy-load reporting dashboards and advanced features.
• Cache merchant data locally so returning users see their dashboard instantly.

M-Pesa (Safaricom, Kenya)

M-Pesa's USSD interface predates smartphones, but their mobile app is equally bandwidth-conscious:

• The core transaction flow uses minimal data.
• Account statements are paginated and cached.
• Notifications are pushed via SMS when data is unavailable.

Shamba (AgriTech, East Africa)

Shamba's farming app works in areas with sporadic connectivity because:

• Farmers can compose orders and messages offline.
• The app syncs when a connection is available.
• Images of crops are resized aggressively before upload.

Monitoring and iteration

Optimisation isn't a one-time task. Build monitoring into your product:

1. Log performance metrics. Send TTFB, FCP, LCP, and CLS to your analytics backend. Track these by device, network, and geography.
2. Set budgets. Decide: "Our pages will never exceed 500KB on initial load. Our API responses will never exceed 100KB." Enforce these in your build pipeline.
3. Alert on regressions. If a new feature adds 50KB to your bundle, your build should fail and notify the team.
4. Test with real users. Use tools like Sentry or LogRocket to capture real-world performance data and errors.

FAQ

Q: Does low-bandwidth design make the product look worse? A: No. It makes the product load faster. You can have beautiful design and low bandwidth. Use modern CSS (which compresses well), optimised images, and thoughtful layouts. Complexity comes from bloated frameworks and unoptimised assets, not from good design.

Q: What if my users are mostly in Lagos and Abuja on 4G? A: Even 4G users benefit from fast load times-it reduces their data costs and battery drain. Plus, 4G connections drop to 3G or 2G regularly. Building for low bandwidth is insurance. And your market will grow beyond metros; building for low bandwidth from the start is cheaper than rebuilding later.

Q: Should I build a separate "lite" version for slow connections? A: No. Maintain one codebase with progressive enhancement. A lite version means double the work, double the bugs, and a worse experience for users who can't choose which version they get. One product, built right, works everywhere.

Q: How much does low-bandwidth optimisation cost in development time? A: If you build with it in mind from day one, almost nothing. It's actually faster-you spend less time loading heavy frameworks and more time shipping. If you optimise after the fact, it's weeks of work. Build right the first time.

Q: What's the minimum page size I should target? A: Aim for under 100KB initial HTML + CSS + critical JavaScript. Images and additional assets can be lazy-loaded. On 2G, this loads in 2-3 seconds. For API responses, keep them under 50KB for common requests.

What to do next

Start measuring. Use WebPageTest to profile your product on 2G from a Nigerian server. You'll see immediately where the bottlenecks are. Then:

1. Read Tech stack choices for Nigerian startups in 2026 to ensure your framework choice supports low-bandwidth design.
2. Check Where to host your African startup: VPS vs serverless vs PaaS to ensure your hosting has CDN support and good latency to African users.
3. If you're building an MVP, follow Ship your MVP in 2 weeks: a Nigerian founder's playbook-and build with low bandwidth in mind from the first line of code.