Does your Web application know when it’s offline?

I intend to accomplish two purposes through this article:

1. Show you a way to simulate Offline experience in Google Chrome, even when you have internet connection. (Bonus: You can use it to play the dinosaur game in office.)
2. Discuss how your web application could detect when there is no internet connection, and avoid running into errors while the connection is restored.

In Chrome, you can simulate offline experience for a tab through the Developer Tools. You can launch the developer tools for a tab using F12 or Ctrl + Shift + I on Windows, or Command + Option + I on Mac.

In the networks panel, there is a checkbox to toggle “Offline” mode. As you check that the tab goes offline as long as the developer tools are open.

To my knowledge Firefox doesn’t have the feature (yet). So in case you are stuck with it, just remove the LAN cable or turn off Wifi.

So the question is:

How does my web application know when it’s offline? Maybe even display a nice error if so?

Obviously the question has been asked on StackOverflow. The top voted answer from 2008 states:

You can determine that the connection is lost by making failed XHR requests.

The standard approach is to retry the request a few times. If it doesn’t go through, alert the user to check the connection, and fail gracefully.

But this has a few catches. What if the website you are pinging is itself down? Your requests won’t get through and your application will “assume” that it is offline.

Second, how many XHR requests should you make before finally deciding that the user is offline? Maybe ten times is enough, but why not five? Or two? When could you be certain that the user is offline?

It has been 10 years since that answer was posted. There’s gotta be a better way! And there are two ways actually!

The first option is navigator.onLine property. It represents the online status of the browser; true meaning online, and false meaning offline. Simple enough:

if (navigator.onLine) {
  console.log("You are online");
} else {
  console.log("You are offline");
}

The good news is that it is supported by all major browsers. The bad news is that different browsers interpret it differently. To quote MDN:

In Chrome and Safari, if the browser is not able to connect to a local area network (LAN) or a router, it is offline; all other conditions return true. So while you can assume that the browser is offline when it returns a false value, you cannot assume that a true value necessarily means that the browser can access the internet.

The second option is to subscribe to “online” and “offline” events. As you might have guessed, unlike navigator.onLine property, you don’t have to check the status with these events; rather the browser notifies the application when it goes offline.

So you can add an event listener on document, document.body or window for “online” and “offline” events, and when the network connectivity changes appropriate events will be triggered by the browser.

window.addEventListener("online", function() {
  alert("You are online now!");
});

window.addEventListener("offline", function() {
  alert("Oops! You are offline now!");
});

Of course, you can do a lot more than simply alert a message to the user. You could have some logic to disable all buttons/links on the page to prevent the user from performing any actions (that might fail) while the application is offline, or you could attempt to re-synchronize with the server when the application is back online, etc.

I have created a CodePen here in case you wish to experiment with these events yourself.

In case you are wondering about browser support, it’s actually great. It seems to be supported by all browsers except Opera Mini.

So the final question remains is, How reliable are these events?

Just like navigator.onLine property, the browser is definitely offline when the “offline” event is fired, but in case of “online” it may be connected to network, but may still not have internet access.

To me it looked pretty reliable. I tried a couple of times turning Wifi on and off, and the events fired within a couple of seconds.

Personally I feel it is better to rely on these events than making multiple AJAX requests. Plus these events are only going to get more reliable in future.

So let’s hope your application doesn’t have to fail silently when the Wifi is down!