Speed is one key factor in achieving good user experience. Although studies show that an app loading in under 3 seconds is acceptable, users are becoming increasingly impatient these days and expect the app to load almost instantly. A good rule of thumb is to aim for less than 3 seconds for the first load and under 1 second for subsequent pages.
Here are some supportive statistics from a recent study:
- 47% of consumers expect a website to load in 2 seconds or less.
- 40% of users will abandon a site that takes more than 3 seconds to load.
- The probability of bounce increases by 32% as page load time goes from 1 second to 3 seconds — rising to 90% as load time reaches 5 seconds.
These statistics highlight the importance of application speed and the potential loss businesses face if they don't meet user expectations. In a highly competitive market, frustrated users would easily find an alternative.
The Problem: Slow API Round-trips
I faced a similar issue with my MVP, goalbook.app, which helps users achieve their personal goals. During testing, we found that one of our critical APIs — which adds goals — could be optimized to 2.371 seconds at best, depending on user connectivity.
When a user submits a new goal, it sends a PUT request to the server to add the data to the database. This is followed by another GET request to fetch the latest data. So there are a total of 2 API requests plus process time. With this method, it's nearly impossible to reduce the overall time to less than 2 seconds without high-end servers and server clusters.
Background Sync: The Solution
This is where the background sync technique helps. It gives users the illusion of updating content instantly without a delay. But technically, the data takes the same time to update the server.
Instead of holding the user until both API requests are complete, the app instantly updates the content and handles the API requests in the background, allowing the user to continue working without interruption.
This simple code change lets the user work uninterrupted, with a subtle sync indicator at the bottom of the screen. Even though the server takes the same time to handle every request, we give the user the experience of good speed because they see their edits instantly.
Note: this technique works for PUT requests (writes), not GET requests (initial data fetches). But the vast majority of user actions are writes, so the improvement is significant. If users try to close the tab before sync completes, a warning message prevents data loss.
Handling Failures
Since the user might have moved on without waiting for server feedback, what if the data transaction failed? The easy fix is to retry the request until it is successfully updated. If it fails multiple times, it's most likely a server error — display a warning and prevent the user from doing any activity until it's ready.
This simple design change can significantly improve the user experience. Though it requires some code tweaks, the effort is absolutely worth it.