Building for 2G or metered data goes beyond compression. Learn how skeleton screens, lazy hydration, delta syncing, and asset budgets keep your app fast and usable for every user.

How to Design Low-Bandwidth UIs That Don't Sacrifice UX

Half a billion people in Africa access the internet primarily through mobile data — and a significant share of them are on 2G or congested 3G networks. If your app takes six seconds to load on a fibre connection, it may never fully load for those users at all. That is not a fringe use case. It is a market.

The good news: designing for low bandwidth does not mean stripping your product down to a text-only shell. With the right architectural and design decisions, you can ship an experience that feels responsive, communicates progress, and respects data costs — without gutting the features that make your product worth using.

Here is how to do it correctly.

Start With a Performance Budget

Before writing a single line of UI code, define what you are willing to spend. A performance budget is a hard ceiling on the resources a page is allowed to load.

A practical starting point for low-bandwidth targets:

Total page weight (initial load): under 200 KB compressed
JavaScript bundle (parsed and executed): under 100 KB
Largest Contentful Paint (LCP): under 3 seconds on a simulated 3G connection
Time to Interactive (TTI): under 5 seconds

Tools like Lighthouse, WebPageTest, and Bundlephobia can enforce these during CI. If a new dependency pushes you past budget, the team decides whether the feature justifies the cost — not the build pipeline.

Progressive Enhancement Is Not Optional Here

Progressive enhancement is often framed as an accessibility courtesy. In low-bandwidth contexts, it is load-bearing architecture.

The principle: build the core experience in HTML and CSS first. JavaScript enhances it. This means your content is readable and your forms are submittable before a single script tag finishes executing.

In practice:

Server-render critical content. Frameworks like Next.js, Nuxt, and SvelteKit make this straightforward.
Use <noscript> fallbacks for interactive elements that are not strictly necessary.
Defer non-critical scripts with defer or type="module".
Avoid client-side routing for content that does not need it.

The mental shift is this: JavaScript is a cost, not a default. Every kilobyte of JS must earn its place.

Skeleton Screens Over Spinners

A loading spinner tells the user "something is happening." A skeleton screen tells the user "here is what is coming, and it is almost ready." That distinction matters enormously for perceived performance.

Skeleton screens — placeholder shapes that mirror the layout of incoming content — reduce perceived wait time by giving the brain a visual scaffold to anchor to. Users tolerate the same objective wait time significantly better when they can see the structure of what is loading.

Implementation is straightforward with CSS:

.skeleton {
  background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
  background-size: 200% 100%;
  animation: shimmer 1.4s infinite;
  border-radius: 4px;
}

@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

Match the skeleton dimensions to your actual content as closely as possible. A skeleton that does not resemble the real layout causes a jarring shift and undermines the trust you were trying to build.

Lazy Hydration: Stop Paying for What Users Cannot See

In server-rendered apps, hydration — the process where JavaScript takes over a server-rendered HTML page and makes it interactive — is often one of the most expensive operations on page load. By default, most frameworks hydrate the entire page at once.

Lazy hydration defers this cost until it is actually needed.

Strategies include:

Hydrate on visibility: Use IntersectionObserver to trigger hydration only when a component scrolls into view.
Hydrate on interaction: Attach event listeners that trigger hydration on first user interaction (hover, focus, tap).
Islands architecture: Frameworks like Astro ship zero JavaScript by default and hydrate individual "islands" independently. This is particularly effective for content-heavy pages with a few interactive regions.

For a SaaS dashboard where most users look at the top three widgets, lazy hydrating the rest of the page can cut JavaScript execution time by 40–60%.

Delta Syncing for Data-Heavy Features

If your app displays frequently updating data — analytics dashboards, logistics trackers, financial feeds — polling for full data payloads on every refresh is wasteful. Delta syncing sends only what has changed since the last known state.

Implement this with a since timestamp or a cursor-based API pattern:

GET /api/orders?since=2025-07-01T08:00:00Z

The server returns only records modified after that timestamp. The client merges the delta into its local state. On a 2G connection, the difference between a 40 KB response and a 4 KB delta is the difference between a usable app and an unusable one.

Pair delta syncing with a lightweight local cache — IndexedDB for web, SQLite for mobile — so users can continue working with stale-but-valid data while the sync completes in the background.

Asset Budgets and Adaptive Serving

Images and fonts are typically the largest contributors to page weight. A few concrete rules:

Images:

Use WebP or AVIF. AVIF can be 50% smaller than WebP at equivalent quality.
Always specify width and height attributes to prevent layout shift.
Use loading="lazy" on below-the-fold images natively — no library required.
Serve responsive images with srcset so mobile devices do not download desktop-resolution assets.

Fonts:

Subset your fonts to the characters your app actually uses.
Use font-display: swap to render text immediately with a system fallback.
Seriously evaluate whether a custom font is worth 60–100 KB on a data-metered connection.

Adaptive serving: Use the Network Information API (navigator.connection.effectiveType) to detect connection quality and serve a lighter asset variant when the connection is 2g or slow-2g. This is not a replacement for good defaults, but it adds a meaningful layer of respect for user context.

Communicate Honestly With Users

When data cannot load, say so clearly. Generic error states ("Something went wrong") erode trust. A message like "Unable to load your dashboard — you appear to be offline. Your last data from 10 minutes ago is shown below" is actionable, honest, and reassuring.

Build offline-first thinking into your UX copy from the start, not as an afterthought.

Why This Matters for Your Project

The techniques above are not workarounds for edge cases. They are the architectural decisions that separate products built to scale across diverse markets from products that quietly exclude half their potential users. In a region like West Africa — where mobile data costs represent a meaningful percentage of household income — building lean is a form of respect. It is also a competitive advantage. Teams that ship fast, efficient software on constrained networks build habits and discipline that make their products better everywhere.