How to Build a Website That Doesn’t Break When the Internet Does

Your website probably runs beautifully in your office, on fast Wi-Fi and a new laptop. But most of your users aren't in that environment. They're on trains, in elevators, in remote towns, switching between Wi-Fi and mobile data - or just dealing with dodgy signal on their phones.

For them, the internet isn't a steady stream - it's a lightbulb that flickers.

And when the connection drops, does your website fall apart? Or does it adapt?

If your answer is “it breaks,” you're not just losing functionality - you're losing customers, trust, and opportunities.

Why Dropouts Are Everyone's Problem

• Trains go through tunnels or lose signal between towers
• Wi-Fi cuts out in cafes and hotels
• People switch between networks while moving around
• Rural and regional users often have unreliable infrastructure
• Mobile data gets throttled, capped, or disabled mid-session

These aren't "what if" situations. They're normal user behaviour.

And when your website doesn't handle those dropouts well, users don't blame the network - they blame your brand.

The Cost of Not Planning for Dropouts

• Form submissions fail, and users lose their data
• API requests break, leaving empty screens or endless spinners
• Images and content don't load, making your site unusable
• No feedback is given, so the user thinks the site is broken

And here's the worst part: you might not even see these failures in your analytics. Dropouts leave silent gaps - sessions that vanish without explanation.

How to Build for Connection Dropouts

1. Cache Strategically with Service Workers

Service workers let your site respond even when the network disappears. They can intercept requests and serve pre-cached versions of your pages, styles, scripts, and images.

Here's the idea:

• When users visit your site with a strong connection, you cache key assets in the background.
• If they return with a weak or no connection later, your service worker delivers cached content, keeping your site running.
• You can also show a custom offline fallback page (like offline.html) for routes that can't be cached.

The user sees a functioning, stable experience instead of a broken site.

2. Don't Assume the Network Will Behave

Every fetch request should be written with the assumption that it might fail. If a request to an API breaks due to a lost signal, your user shouldn't be stuck with a broken page.

• Catch network errors with try/catch blocks
• Show fallback UI (e.g. last-known good content, or a helpful message)
• Disable certain buttons or actions until connectivity is restored
• Offer the user a retry button or automatic reconnection option

Always give users feedback, not frustration.

3. Retry with Exponential Backoff

When something fails - like submitting a form - your site should try again. But not immediately and repeatedly. That's how you overload servers and drain mobile batteries.

Use exponential backoff:

• First retry after 1 second
• Then 2 seconds
• Then 4, 8, etc.

You can even store actions in localStorage or IndexedDB and resend them when the user comes back online.

function retryRequest(url, options, attempts = 5, delay = 1000) {
  return fetch(url, options).catch(err => {
    if (attempts === 0) throw err;
    return new Promise(resolve => 
      setTimeout(() => resolve(retryRequest(url, options, attempts - 1, delay * 2)), delay)
    );
  });
}

This strategy lets your site bend instead of break when something goes wrong.

4. Let Users Know When They're Offline

Silence during a dropout is the worst thing you can do. If your app stops responding and gives no hint why, the user will assume something's broken - and leave.

• Show a persistent “You're offline” banner or warning
• Disable or grey-out actions that require a connection
• Re-enable those actions automatically when the connection returns
• Offer manual "Retry" or "Refresh" options

5. Queue Actions While Offline and Sync Later

If your user does something meaningful while offline - submits a form, hits “like,” adds something to a cart - don't throw that action away.

• Save the action to localStorage or IndexedDB
• Monitor the connection status
• Automatically resend those actions when the user is back online

To the user, it feels like everything just worked - even though your site was smartly waiting for the right moment behind the scenes.

6. Detect and React to Connectivity Changes with JavaScript

Your website can detect when a user goes offline - or comes back online - and respond accordingly.

Use navigator.onLine to check status:

if (!navigator.onLine) {
  showOfflineBanner();
}

Listen for connectivity changes:

window.addEventListener('offline', () => {
  showOfflineBanner();
});

window.addEventListener('online', () => {
  hideOfflineBanner();
  resendQueuedActions();
});

Bonus: Use navigator.connection to check connection quality

if ('connection' in navigator) {
  console.log(navigator.connection.effectiveType);
}

Track Connection Status in Your Analytics

function trackConnectionStatus() {
  const status = navigator.onLine ? 'online' : 'offline';
  sendToAnalytics('connection_status', status);
}

window.addEventListener('online', trackConnectionStatus);
window.addEventListener('offline', trackConnectionStatus);

This data helps you build with insight, not guesswork.

7. Test Like It's Real Life

• Use Chrome DevTools → Network → Offline / Slow 3G
• CPU throttling to mimic older devices
• Use WebPageTest, Lighthouse, or Replay.io to simulate dropouts
• Use RUM tools like Google Analytics 4, Sentry, or LogRocket

Test things like:

• Reloading the page while offline
• Submitting a form with no connection
• Navigating back and forth under flaky network conditions

Conclusion: Build for Dropouts, Not Just Downloads

Connection dropouts are not rare. They're a routine part of your users' day-to-day experience...

When it does, does your site power through - or fall to pieces?

Resilient sites:

• Cache smartly, so users always see something useful
• Fail gracefully, with feedback and fallbacks
• Retry intelligently, with exponential backoff and queued actions
• Sync later, without forcing the user to redo anything
• Detect and adapt, showing helpful messaging when the signal drops
• Track everything, so you're not flying blind

So don't just build fast websites. Build forgiving, adaptable, dropout-resistant websites. Because when the connection cuts out, the real test begins - and most sites fail it.