- 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 1||15.92 Mbps|
|Test 2||15.45 Mbps|
|Test 3||15.82 Mbps|
|Test 4||15.74 Mbps|
|Test 5||15.45 Mbps|
Mobile speed tests using Speedtest.net iOS app over 3G via Toronto to New York (Optimum Online):
|Benchmark – Mobile|
|Test 1||2.54 Mbps|
|Test 2||1.83 Mbps|
|Test 3||1.27 Mbps|
|Test 4||1.73 Mbps|
|Test 5||1.27 Mbps|
Single File Test
Here are my results:
|Test 1||2.34 Mbps||0.97 Mbps|
|Test 2||1.93 Mbps||1.45 Mbps|
|Test 3||3.02 Mbps||1.70 Mbps|
|Test 4||1.80 Mbps||0.69 Mbps|
|Test 5||2.01 Mbps||1.22 Mbps|
|Average||2.22 Mbps||1.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.
|Test 1 – 34KB||0.453 Mbps @584ms||0.294 Mbps @900ms|
|Test 2 – 177KB||1.11 Mbps @1235ms||0.725 Mbps @1902ms|
|Test 3 – 697KB||2.02 Mbps @2684ms||1.49 Mbps @3646ms|
|Test 4 – 1,391KB||2.46 Mbps @4411ms||2.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)
I found a great article measuring DNS Lookup times, IPv6 Support and Latency, as well as some insight on the new NavigationTiming API: