If you’re reading this blog, you probably know that load time matters when it comes to user experience, a lot. And it’s even a major factor determining the success of a website.
Server response time, speedindex or start render, or again fully loaded time, whatever is the metric you want to collect, your measurement method should take into account several major parameters if you want reliable results through time.
Measure load time using a Real Browser
Nowadays, using a real web browser is not optional when it comes to performance testing. Times when we were allowed to focus only on server performance are gone for a while, and you should have no doubt about that with the Performance Golden Rule (tldr; most waiting time is spent due to the front-end, not the back-end).
Every web browser (Chrome, Firefox, Safari, etc) comes with some specificities, but whatever the one you choose for performance measurement, your goal is to create a reference environment. You’re not doing Cross Browser testing here, and you’re not trying to find the faster browser neither.
However, if your website is using User Agent Sniffing mechanism to adapt some content, some significant changes can exist. Particularly when UA Sniffing is used to redirect mobile devices to a dedicated version. So do not forget to test all of these versions!
If you have an account on our service, you can test any page using Chrome or Firefox, and all our customers are able to customize the User Agent string for each test!
Test Probe location and Latency
Latency is a delay related to telecommunications, related to transport time required for data to go from a A point to a B point. Even if it’s fast, it is not instantaneous, and when you have visitors all around the world, the distance between them and your server can be significant, and so will be the latency they’re facing (yet, you can reduce its impacts using a CDN).
Latency is not only due to distance, it’s also related to the kind of network used. For instance, 3G network latency is very expensive compared to the one over a DLS network.
And the latency is generally a big deal for the loading time of a web page, as it will impact every single request (a typical web page requires a hundred of them).
When measuring the load time of a web page, you absolutely have to master the latency. Some tools might randomly use test probes all around the world, so latency will widely vary, and you’ll be facing random results according to the used probe. There’s another issue with a lot of tools not managing latency impacts properly. Test probes are located in datacenters in most of the cases, so network is offering race conditions, not the one you have as a visitor of a website. Limiting the bandwidth is required, and the same goes for the latency if you want to perform a realistic measurement.
So you have to test your website from several locations, according to the characteristics of your own visitors, and be aware of latency effects when reading your test results. Indeed, Internet network is facing fluctuations, and latency can sometime skyrocket!
With our tool, you can benefit from 6 test locations (Washington DC, Paris, Frankfurt, Sydney, Tokyo and Hong Kong) and all our customers are able to configure a custom latency. We provide a minimal latency, according to the network type selected, in order to guarantee the reliability and stability of our results.
Bandwidth to be used when testing speed
This topic is certainly the most well-known. Whether you’re downloading a file or browsing the web, bandwidth is a key factor. The more heavy is a web page, the more the bandwidth will affect the performance results.
Do not forget that among your visitors, network capacities can widely vary. According to Akamai data (3rd quarter – 2015), average connection is 8,2 Mbps in France, and yet 26% of french are provided with a network offering less than 4Mbps. In Sweden, European best country on this matter, the average connection is more than twice the french one (17.4Mbps).
Finally, we have to take into account mobile networks, with very low bandwidth in most of rural areas. Do not forget neither than in most countries, data have a cost!
In sum, you’ll have to run performance tests on your web pages using several network connectivity, according to the ones used by your visitors. At least, you’ll have to manage two different test settings, one for mobile and the other one for desktop users.
Our website speed test service automatically provide a relevant bandwidth whether you choose to perform a mobile or a desktop test. Several settings are available and you can even use a custom one at any time!
Viewport, A/B Testing and other special use-cases
In this last part, we’ll bring some less known points that might affect your website speed tests.
The screen width might be a significant one if your website is using Responsive Web Design. Indeed, RWD should imply not loading some resources, or different ones according to the viewport. For the same reasons, lazy-loading mechanisms are affected by the screen height, so performance metrics could widely vary according to the used viewport when performing the speed test.
A/B testers should be aware that their tests might affect performance results. Moreover, A/B testing brings complexity in order to have a proper reference use-case. Your speed tests should not alternate randomly between A or B versions, you have to choose one, or to test both separately. A/B Testing products allow to force the version to be used, so using a cookie or a URL param in your test settings would be a good way to do so!
If your page is using asynchronous mechanisms, their might be differences in the results according to the test tool used. Indeed, they’re not working the same way to determine whether or not a test is completed or not, so some asynchronous request might be missed.
If you’re not sure about your results, you can give a look to the page’s weight or the number of request to identify what could be missing.
At last, if a test result seems awkward to you, give a look to the screenshot, the video or the waterfall, that should help you to know what might have gone wrong.
I hope you enjoyed this article, now you can go back to your favorite website speed test tool!