Building Crypto Apps for Users With Slow Internet

Many crypto apps are built by teams working on fast connections with powerful laptops. Many of their users are not. Across large parts of the world, people use crypto on mobile data that is slow, expensive or unreliable. An app that downloads several megabytes of scripts before showing anything, or fails when the connection drops mid-transaction, excludes those users.

Designing for slow internet makes apps better for everyone.

Measure what users experience

Start by testing like your users:

• Use browser tools to simulate slow mobile connections
• Test on mid-range and older Android phones
• Measure time to first content and time to interactive
• Try completing key flows while switching between networks
• Check data usage for a typical session

Numbers from a fast office connection hide the real experience.

Keep pages light

Heavy pages are the most common problem:

Issue	Improvement
Large JavaScript bundles	Split code and load features when needed
Big images	Compress, resize and use modern formats
Web fonts	Use system fonts or subset custom fonts
Animation libraries	Use CSS animations or simple canvas drawing
Third-party scripts	Remove anything non-essential
Autoplay video backgrounds	Replace with static images

Serve static content from a content delivery network close to users, and cache assets aggressively.

Show content before wallets

Many dApps load wallet libraries and blockchain data before rendering anything. Instead, render the page structure and key information first, then load wallet functionality when users choose to connect or pay. Users on slow connections should see what the app does within a few seconds.

Design resilient transaction flows

Connections often drop during the most important moments. Design flows that survive interruptions:

1. Save order or transaction state on the server so users can return later
2. Give every order a shareable link that restores its status
3. Detect payments on-chain rather than depending on the browser to report them
4. Let users paste a transaction hash if the app missed an update
5. Avoid flows that require keeping a page open for a long time

A user who loses connection after sending a payment should be able to reopen the page later and see it confirmed.

Communicate status clearly

On slow connections, users need to know what is happening:

• Show loading states for every action
• Distinguish between "sending", "waiting for confirmation" and "confirmed"
• Explain when the app is retrying
• Provide clear error messages with next steps
• Avoid silent failures

Clear status reduces duplicate payments, which often happen when users think a first attempt failed.

Reduce data costs

Data can be expensive. Reduce usage by:

• Polling less frequently and only when a page is visible
• Caching data that changes rarely
• Avoiding large automatic refreshes
• Letting users choose lighter views, such as lists instead of heavy visualisations

Offline-friendly patterns

Some features can work partly offline. Progressive web app techniques let pages load from cache, show saved information and queue non-critical actions until connectivity returns. Payments themselves need connectivity, but viewing receipts, addresses and instructions can work offline.

Test with real users

Invite community members from regions with slower connections to test new features. They will find problems automated tests miss, such as flows that time out or pages that become unusable on their devices.

Built to be light

Proud Globe keeps its pages light: no tracking scripts, compressed images, a globe drawn on a simple canvas and order pages with shareable links that restore status after a dropped connection. Payment detection happens on-chain, so a buyer who loses signal can reopen their order link later and see the result.