Sunday, February 15, 2015

Your User's Connection Speed Is Not as Fast as You Think

This last weekend, we took a quick getaway as a family to Wisconsin Dells.  The resort we stayed at offered free WiFi, which is always good.  When we checked in around 1:00 PM, the hotel was not very busy, but I did notice a steady stream of guests at the front desk throughout the day.

Around 5:00 PM, I was trying to use my phone to get online, and I noticed everything was painfully slow.  Web pages took 30 seconds or more to load.  The voice recognition built into Android would not work at all.  Trying to browse items in the Amazon app resulted in this.



It didn't take long to figure out what was happening,   My network connection speeds through WiFi were painfully slow.  Unusable slow.  I did manage to get a speed test app downloaded somehow and ran several tests just to quantify what I was seeing.  Here is what I got.





What you are seeing is correct.  The speed I was getting on WiFi was about 2 Mbps.  That reading of 3.17 Mbps was taken at 5:11 AM, when most everyone in the hotel should have been asleep.  Yes, the resort offered free WiFi, but the quality of that service was effectively unusable, at least during my visit.

This is not my only experience with free or even paid WiFi being so slow that it was effectively worthless.  A few weeks ago, I was at a retailer that offered free WiFi, but when i tried to stream a YouTube video (on web performance coincidentally), I would get abut 10 seconds of video followed by 30 seconds of buffering.  After a few minutes I gave up.  And last year while staying in Chicago, I paid for WiFi at a hotel that ended up being so slow that every web page took 30 seconds or more to load.

Why is this?  My guess would be that there are simply too many users for the size of the connection the business has.  If a hotel has 300 rooms, it would take a connection of 3 Gbps such that every room would have an equivalent of a 10 Mbps connection.  Of course you may have multiple people staying in a room, which means multiple devices.  And it isn't a stretch to say that a number of those people may be trying to stream video to those devices.  Combine this with other users who are streaming audio, users who need to VPN back to their company and general web usage, what we have is a demand for much more bandwidth than is available.

When we are in our workplaces developing web sites, we often have very fast internet connections, because a slow connection would be unproductive.  And at home, as technology professionals, we probably tend to pay for faster connections than the average consumer because we make heavy use of online services. Although even at home, we don't always get the speeds we expect.  My internet package is "up to 15 Mbps".  Focus on those words "up to".  Here is the speed I got when I tested last night at home:



A download speed of 9.43 Mbps is not bad, but it is still 33% below the rated speed of my package.  And I also performed this test when I knew that no one else in my household was performing any Internet activity like streaming Netflix or something like that.

The point is, you can't always assume that someone has an ultra fast internet connection that is able to download images, video and other content in a matter of a couple of seconds.  They may be on a WiFi connection which is shared by 10's or even 100's of users.  They may be viewing your page in the evening, when many other users are streaming content, saturating network connections of their ISP.  Or maybe they are viewing your site over a slow cellular connection.  Whatever the case, there is likely to be a significant number of your users that are accessing your site on a connection with suboptimal performance.

What Can We Do About It?

I wish tomorrow that Google Fiber would magically roll out across the entire United States, no wait, the entire world and fix this problem for us.  Since that is unlikely to happen, we have to take action as web developers to make out pages work better for these users with slow connections.  Those users are our customers too, and their experience matters like everyone else's.

In a blog post last week, I included this graph from the HTTP Archive that showed that the average size of a webpage was now approaching 2 MB.


If we leave out the time it takes the server to respond, DNS lookups, any network latency and the time to render a page, the act of simply downloading a 2 MB page on my (effective) 2 Mbps water park resort connection is 8 seconds.  A 3 MB page would be 12 seconds just for download time and 4 MB would be 16 seconds.  Again, those numbers are just the pure download time, not the total amount of time it takes to render a page.  Eight seconds is not a good user experience.  Sixteen seconds (or longer) and most user's will be giving up.

So we have to carefully pay attention to the size of our web pages.  Every modern browser contains built in developer tools with a network tab.  Open these tools (usually by hitting F12),  go to the network tab and reload the page.  And I suggest you disable caching or clear your cache before doing this, so you can get a feel for what a new user might be looking at needing to download to view each one of your pages.  Below is the output from Google Chrome when viewing the Pluralsight homepage.


There is a lot of good information here.  In the lower left hand corner, we have the total size of the page (792 KB in this case).  We can also click on the "Size" column header to sort the files that make up this page by size (you will actually need to click it twice to get a descending sort).  So we can easily identify the heaviest resources on the page.

We also have a series of buttons like 'All", "Documents", "Stylesheets", "Images" and so on in the top part of the panel.  Clicking on one of those will give display only that file type in the list.  And when we do that, the stats in the lower left hand corner will update to only show the summary for the selected file type.  So in short order, we can understand how large our page is and what files are driving that size.

To address issues with page size, we want to make sure our images are optimized and appropriately compressed and that our JavaScript and CSS is mnified.  At the same time though, we want to think about the content that is on our pages and understand if it really makes sense to be there.  In designing websites, designers often focus heavily on the aesthetics of the site.  For a usable site though, these aesthetics need to be balanced with usability and performance.  Maybe some of that content could go on a separate page that the user clicks through to access.

Finally, I would recommend that you use Web Page Test to simulate access to your page at various network speeds.  This is important, because unlike you, your users do not sit down the hall from the web server serving up your content.  The default choice of a 5 Mbps down/1 Mbps up cable modem is a good choice to start with.  As you can see though, you can test all different combinations and define your own custom combinations:


The idea is that you can simulate users from various different locations and connection speeds.  And as we have seen, there is a great amount of variability in what connection speeds a user may be experiencing at any given time.  With web page test, you can experience what they experience and design your page that even a user with a relatively slow connection speed will still have a reasonable experience in viewing your page.

Summary

Poor network connections are a fact of life that is unfortunately not going away any time soon.  As web developers, we have no control over the connection that a user finds themselves on.  yet that doesn't mean we can't be proactive about addressing the issue.  We have tools that can tell us how large our pages are. We can make sure that our resources like images, CSS and JavaScript are completely optimized so the user doesn't have to wait for unnecessary bytes to be downloaded.  And we can take advantage of caching, to make sure a user doesn't have to re-download the same resource over and over again on every page they visit.  

Slow connectivity will always be frustrating, but by keeping mind that it does exist, and probably exists more often than we would like to admit, we can design sites that at least give a user a reasonable experience when visiting our sites.  

No comments:

Post a Comment