In an ideal world all users would have fast broadband and spread their visits to ...
| || |
In an ideal world all users would have fast broadband and spread their visits to your site throughout the whole day. Unfortunately sites must still accommodate for dial up and ensure they have the capability to handle high demand. For example does the performance of your site vary by time of day, is performance adequate for your usage (e-commerce applications taking online payments or event bookings) and do you experience loss of service at a particular time, such as during an overnight backup.
Sitemorse provides in-depth information about the most important page on your site: the front page. ...
| || |
Sitemorse provides in-depth information about the most important page on your site: the front page. This is, of course, the page that most visitors to your site will see first, and is also likely to be the last page of your site they will see if its performance is poor.
Users' expectations also vary depending on their own internet connection - modem users understand they have a slow connection speed compared to ADSL, for example, and are correspondingly more likely to be patient.
Download time is benchmarked against acceptable waiting times for users, according to the speed of their connection.
- 56k Modem - 14 seconds target
- 512k ADSL - 6 seconds target
- 1024k Corporate Network - 4 seconds target
When timing the front page of your site, Sitemorse downloads the page, including all the ...
| || |
For the 56k modem, 512k ADSL and 1M corporate LAN figures, Sitemorse calculates how long it would have taken someone with each of those connection types to download your front page - taking into account that these connection types cannot download data as fast as Sitemorse's servers can in the data centre.
Sometimes, however, the limiting factor on the speed of the page download is not the end-user's connection, but your web server. For example, if your web server is only sending data at 20kB/sec, both the 512k ADSL and 1M corporate LAN users can download data faster than this, and so they will both see a 20kB/sec download speed. Therefore they will also see the same total time taken to download the page.
So, if Sitemorse is giving the same figures for the download time for 2 or even 3 of the connection types, this is not a mistake or miscalculation. It just means the limiting factor in those speed tests is not the user's connection, it is your web server.
Download and Response Times shown the average timing figures over the entire test. This is ...
| || |
Download and Response Times shown the average timing figures over the entire test. This is a useful guide as the performance a site visitor would experience when clicking through various pages of your website - recording the performance of individual pages will not provide the same figures.
Think of the test as the time taken to complete a journey, from say London to Birmingham taking into account the different speeds you can achieve during the journey.
The server delay between Sitemorse requesting an object and the server starting to send it, averaged across all requests made during the test.
The speed at which the server transmitted data to the Sitemorse system, averaged across all requests made during this test. Another term for the result of this test is 'bandwidth' - Your provider may say you have an XXmb pipe, which may directly contradict with the Sitemorse results, but we are recording exactly what is being delivered.
The above two figures are combined to produce the final score out of ten.
Performance scores can be difficult to understand, these two examples show how the pass or ...
| || |
Performance scores can be difficult to understand, these two examples show how the pass or fail of a Modem test should be interpreted.
Only Modem test passed
- 56k Modem - 14s target : 12s Pass
- 512k ADSL - 6s target : 8s Fail
- 1024k Corporate Network - 4s target : 8s Fail
In this case, the web server is delivering pages at a rate that is greater than a 56k modem’s maximum speed but considerably slower than either the ADSL or corporate connections’ maximum.
In the first instance the speed of the modem is the limiting factor whereas in the second and third instances it is the speed of the server. This also explains why the download time is the same for both the 512k and 1Mb connections.
Only Modem test fails
- 56k Modem - 14s target - 18s Fail
- 512k ADSL - 6s target - 5.5s Pass
- 1024k Corporate Network - 3s target - 4s Pass
In this case, the speed at which the web server is delivering pages is clearly sufficient for all types of connection, but the page itself is too big for a 56k modem to handle efficiently.
Any page over 84 kilobytes in size will be deemed to have failed the modem test simply because it would take over 14 seconds to download, regardless of the speed at which the server delivers it.
NB: A 56k modem has an effective download speed of 6 kilobytes per second.
The main selling point of multi location is useful, if say your site is accessed ...
| || |
The main selling point of multi location is useful, if say your site is accessed by users around the world and you want to know how the site is being delivered from different points of presence. The problem is majority of monitoring systems can only carried out limited tests and are only looking at what the server is doing – not what is actually happening on the site, the visitor experience.
Measuring the site from multiple UK locations can actually cause very obscured results, this problem is normally compounded when companies provide an average, when one point records a problem – this in turn provides very misleading results.
Sitemorse has a far more intelligent offering to this, we make use of multiple locations but report from one (for UK Local Authority main sites), we are also looking at he delivery and the correct operation of the site not just if a server can respond to a request.
Sitemorse servers are centrally located, close to the Internet hub with multiple high-speed connections and less than a 2 millisecond round trip to the London Internet Exchange (LINX).
Time to first byte (response time) is very important - it gives the minimum possible ...
| || |
Time to first byte (response time) is very important - it gives the minimum possible time in which the user can see any indication of the server responding to their request.
Browsers generally start displaying a page before it has fully downloaded, thus "time to last byte" (download complete) is often largely irrelevant.
Moreover "time to first byte" is often extremely useful in diagnosing the cause of server performance issues.
In addition, "response" (time to first byte) is not the only parameter that Sitemorse measures. "Download speed" is the speed at which data is transmitted after it starts being sent. A site which is very fast at responding, but in practice very slow, will therefore not get a good
Performance score in Sitemorse.