Exploratory Testing with the Chrome Network Tab

I needed to the loading time of a login over a slow network. The internet connection I had was too fast to see all the visual behavior and the backend redirects happening during the process. I opened the Network tab in the Chrome developer tools and switched the throttling option to Slow 3G. (A yellow triangular yield symbol appeared next to the Network tab to remind me that I’d throttled my network.) Running over Slow 3G allowed me to see what someone trying access the site from a phone or tablet might experience.

The screenshots below are from the login on hackdesign.org, a program I highly recommend for getting up-to-speed on user experience design.

With the Network tab open, I could do a few things:

  1. I could see what API calls were being made. I looked at the bottom of the Name column to see how many calls there were overall, and sorted it to discover if we were retrieving things from the server that I expected to be cached. I clicked the Preserve log checkbox before I started so I could see what happened even after I went to another page.
  2. I could see which calls were redirects. The Statuscolumn had numbers in the 300 range for redirects. I love httpstatuses.com for what each one means more precisely. Redirects might indicate something could be optimized.
  3. I could tell how much time each of those network calls took. The Time column allowed me to sort by milliseconds to find the call that took the longest.
What I used in the Network tab of the Chrome developer tools. HackDesign.org login only took 6 seconds.

I discovered logging in and logging out took about 20 seconds on the test environment over Slow 3G. (This time appeared in the Load text in red at the bottom of the Network tab.) Was this too slow? To answer this question, I needed an oracle.

I decided to compare the behavior on the test environment to our production environment. On production, login took 60 seconds! When I sorted the network calls by Time, I could see that the bulk of loading time was spent retrieving messages to display on the logged-in page. Both 20 and 60 seconds for a login seemed unacceptably slow to me, so I took it to my team.

My team agreed that this behavior was bad. Unfortunately, we decided to prioritize users on fast networks over users on slow ones, and changing this behavior wasn’t a priority for our release.

When I sorted the network calls by Name, I found some unexpected URLs I did not expect to be involved during a login. I tested a bit more around the feature in different places, found a bug in the behavior, and asked around a few different teams before I got the bug reported to the correct team.

Moral of the story

You have a powerful web performance testing tool at your disposal. Give it a try and see what you find.