Mobile developers for a video tutorial app faced an unusual problem—With each release, their users couldn’t access videos without waiting 15 seconds for the application to start up.
The usual approach - looking at the status code attached to the network call - didn’t give any additional information, because it simply showed a 200.
Network calls, the way a device communicates with a server, each have an associated status code (e.g. 2XXs, 4XXs, and 5XXs), method (e.g. POST, GET), header (i.e. cookies) and endpoint. Status codes are a good way to find problems, such as when there are server outages or too many outgoing requests.
The problem is that both well-performing calls and inefficient ones can return a 200, the code for a successful call.
So, how can we investigate what’s causing the slowdown?
One way is to investigate the network body - this is the usual approach developers take with high-duration calls. The network body includes information requested by or returned for a network call, such as a desired video, log-in information, or text describing an endpoint failure.
For these developers, the network body revealed the problem’s source: Every time the application updated, its cache would clear, requiring an excessive amount of calls to repopulate video preview images.
Instead of blindly searching the codebase for the cause of the unexpected behavior, developers saved valuable time by discovering it directly from the network body.
200s aren’t the only type of problem a developer can encounter though: The same team found mysterious 429s (Too Many Requests) spiking seemingly arbitrarily. Given that the call had a GraphQL endpoint, it would be easy to start troubleshooting the query itself or pass over the problem thinking it was an innocuous timeout. But the body revealed the true source—CloudFlare was marking the user’s IP address as “suspicious”, requiring an unfulfillable captcha and rate limiting the user’s connection. Thus, with the status code and body together, teams are able to work with a full information set rather than make assumptions about the user experience to fill in the blanks.
Evaluating the stability of network calls is essential to bettering the user experience. Although not every 401 (Unauthorized) on a log-in flow calls for troubleshooting given that it’s easy to input the wrong password, capturing the network call gives developers another tool to debug tricky issues. Even though the status code tells you a lot about your networking problem, it might not always give you the complete context. Instead, look at the body to take out the guesswork.