Page loading is an important metric to track for any web developer, having poor load times can decrease user experience, increase abandonment, and wreak havoc on SEO.  Responsive and mobile friendly websites offer a solution for delivering media which will fit to the dimensions of the screen, what if it was to actively gauge the quality of the connection, and responsively deliver content and media to the client based on the connection, this would not only reduce the abandonment rate, but can increase the user experience by getting the page loaded in a timely manner. With these thoughts, would it be feasible to add the extra overhead to gauge the speed of a user’s Internet connection prior to delivering the content, and can it be done with a lightweight, client-side solution such as Javascript?  Several thoughts come to mind, the first being to simply to have the client request an image, and time how long it takes to download.

Javascript Connection Speed Test

The basis of this experiment comes from an article I ran into by Alex Le, where he created a wonderful piece of Javascript code to Detect the connection speed of a client.  A little background on his code:

  • It takes the image url, and the byte size of the image.
  • Gets the current time, queues up a new image object, and using the Image.onload() event to get the time after the image has completed loading.
  • Takes the difference of the start time and the end time.
  • Uses the byte size of the image divided by the difference in time to find the Kbps.

Simple enough.  Time to set a benchmark. Desktop tests using Speedtest.net via Toronto to New York (Optimum Online):

Benchmark – Desktop
Test 115.92 Mbps
Test 215.45 Mbps
Test 315.82 Mbps
Test 415.74 Mbps
Test 515.45 Mbps
Average15.68 Mbps

Mobile speed tests using Speedtest.net iOS app over 3G via Toronto to New York (Optimum Online):

Benchmark – Mobile
Test 12.54 Mbps
Test 21.83 Mbps
Test 31.27 Mbps
Test 41.73 Mbps
Test 51.27 Mbps
Average1.72 Mbps

Single File Test

Using the Javascript code from Alex Le, I have made a demo page which will download a 712,817 byte image (800 x 600 resolution of random noise), and output the speed and time it took to download.

Bandwidth Speed Test – Single File

Here are my results:

 DesktopMobile
Test 12.34 Mbps0.97 Mbps
Test 21.93 Mbps1.45 Mbps
Test 33.02 Mbps1.70 Mbps
Test 41.80 Mbps0.69 Mbps
Test 52.01 Mbps1.22 Mbps
Average2.22 Mbps1.21 Mbps

Using the benchmark reference, it is clear that the numbers returned for the desktop tests are clearly below what was expected, mobile was closer but still under.  However, since we know the exact size of the file (712,817 bytes), and we can use either Chrome Developer Tools or Firefox’s Firebug to check the runtime (the time it took to download), with some math we can validate that the speed returned is accurate.

Why the difference in speed? Something Alex Le touches on, is that the file is simply not large enough to get an accurate measurement.  It has completed downloading the file before hitting peak bandwidth, we can clearly see this on the desktop, mobile tests look more accurate because it is a lower bandwidth device which can get closer to its peak.

Multiple File size Test

If file size is the issue, then lets see what reasonably file size will bring a better result.

Bandwidth Speed Test – Multiple File

DesktopMobile
Test 1 – 34KB0.453 Mbps @584ms0.294 Mbps @900ms
Test 2 – 177KB1.11 Mbps @1235ms0.725 Mbps @1902ms
Test 3 – 697KB2.02 Mbps @2684ms1.49 Mbps @3646ms
Test 4 – 1,391KB2.46 Mbps @4411ms2.20 Mbps @4929ms

While we hit the mark for the Mobile test, the Desktop speed is still far off, but an important number out of this test is the time for the largest file which is almost 5 seconds, this number is in the range where it can start to impact the user experience.

So what can we use this for?

When we look at the numbers we can get a good idea of how large the bandwidth pipe will get as the browser downloads the webpage.  Using the file size 712,817 bytes (the same as in the Single file test, and Test 3 from the Multiple File) as the relative size of many websites, we can average the bandwidth will get up to around 2MB on Desktop and take 2.6 seconds to download a webpage, and on mobile 1.5MB and 3.6 seconds to download.  Referencing the article “How Loading Time Affects Your Bottom Line“, it is the time it takes a page to load which is the important factor when considering user experience, and from the Multiple File test, we can see the estimated load times for various sizes.  If we target a page load time to be under 2 seconds, that means that on the Desktop we need to target around 400KB of data to be transferred  and on around 177KB on Mobile.

By controlling what is being sent to the client, we can speed up the initial load time, here are a few thing to consider:

  • Lazy loading images
  • Lower resolution images
  • Lazy load content
  • Prioritize media to be loaded (example: disable videos; turning off full screen backgrounds)

Finally…

This was just a simple experiment to see if I could get the client bandwidth using Javascript, and I can see that there is a lot more work needed to get the accurate speed.  I think it makes more sense to go down the path of figuring out how to control what your website sends down the bandwidth the client is giving you, within a reasonable time.

I combined both tests: Javascript Connection Speed Test Demo

References:

Connection Speed Detection with Javascript

Detect connection speed with JavaScript

Update

I found a great article measuring DNS Lookup times, IPv6 Support and Latency, as well as some insight on the new NavigationTiming API:

Analyzing Network Characteristics Using JavaScript And The DOM, Part 2

2 Comments

Leave a Reply to Lukas Cancel Reply