Speed test

What does it do?

Measures the speed of the website, including factors like file size and application response time.

Example results

Example of speed test results

Why is it important?

Slow pages deter users and search engines from exploring your site. Google is so convinced of the merits of website performance, that they have openly started to use website speed as a criterion in their website rankings.

How is it measured?

Sitebeam simulates the behavior of a real web browser, and downloads all of the files required to render a webpage. These measurements are then used to estimate how fast the website would load over a theoretical internet speed you have chosen (you can change this target speed under Site settings > Test configuration).

The score is based on how long the average webpage will take to load in its entirety, for the targeted bandwidth. The ideal loading time – for a perfect score of 10 – is 0.5 seconds. The worst possible loading time is 10 seconds. Pages with a higher importance contribute a greater weight to the overall score.


How is “Load time” different from “Response time”?

Load time is how long an entire webpage takes to load, including all of the images, stylesheets, etc. A good time here would be 1-2 seconds.

The “Response time” is how long a webpages takes to start to load. Generally if you click a link to a webpage, there is a short delay before something starts to happen – this is usually the response time. If a website takes too long to respond, users give up; they usually assume the site is broken. A good response time is usually less than half a second.

Technical explanation

Sitebeam mimics the behavior of a real web browser very accurately, but not perfectly:

  • A maximum of 6 HTTP connections can be opened to a single host at any time. This is in line with modern browsers.
  • The order of resources, and the dependency of resources is considered as for a real browser (we have modeled Google Chrome’s behavior where possible). For example, images are loaded in the order they are listed on a page; CSS files must load before the images they reference can be loaded, etc.
  • Because Sitebeam is not a real browser, it cannot execute Javascript. Therefore any resources loaded via Javascript will not be found. For most sites this is not a problem; even when a site uses resources in this manner, they are generally loaded after the rest of the page.
  • Files are not downloaded more than once. If a file has already been downloaded on another page, Sitebeam will re-use that resource, and pretend it downloaded it again to estimate the overall page speed. Therefore the actual order of downloaded files may vary from what is used to calculate the results (in practice, the results are almost invariably identical).

The speed of a page is typically estimated based on the target bandwidth requested for the site (e.g. 4Mb). There is also an option to measure real-world speeds from our datacentre, if you wish.

Assuming you use a simulated speed, Sitebeam calculates the time taken for individual files to download by measuring the transfer size of the file (i.e. how much data needs to be sent) and adding to this the application time measured for that file (i.e. how long it took between receiving a request and returning with the first byte of data). The measured DNS and connection times are ignored.

If you used a measured speed, the full time for each file – including DNS lookup, connection, application response and data transfer is measured exactly. These results may vary significantly if you retest the site however.

Simulated connection speeds are weighted down to use 70% of the theoretical maximum speed, to allow for ‘real world’ conditions.

You can see the calculations in detail by using the Test URL feature.

How is the response time calculated?

The response time is the amount of time between sending the complete request to the webserver, and receiving the first byte of a response from that server. Generally this delay is down to the time taken for the application on the webserver to respond.

The response time is significant because it measures how responsive the application behind the website is, independently of other network factors (such as DNS lookups, connect setup or bandwidth). As such it can be used to evaluate whether a website is poorly coded, using a slow CMS or is running on underpowered hardware. For the vast majority of instances, enabling some form of static caching will result in the greatest improvement to application response times.

Potential problems

File sizes appear too small for some files

This is particularly common with Flash and video files. Sitebeam is reporting the size of the initial file, not the subsequent download which may be initiated by it (for example, the Flash may initiate a pre-loader, which then loads more Flash). There is no way to detect this. Sitebeam is effectively recording the time for the Flash to start.

Some files are not found

Files which are loaded dynamically (i.e. via Javascript) cannot be detected by this test. In practice this is rarely a problem; even when a site uses resources in this manner, they are generally loaded after the rest of the page.

Results vary over time

The response time of the website can vary between tests. If a website is very busy it may be slower when you test it than at another time; this will be reflected in the results.

How to improve this score

Optimize the website to use smaller files, and fewer files where possible. Some general advice:

  • Enable GZIP compression for selected formats. For some common file types, a simple technical change to your webserver can significantly improve performance. Compressing some other file types can actually impair overall performance. Sitebeam will suggest which should be modified in the detailed test results.
  • Optimize image formats. Ensure that the correct file format is being used – generally GIF or PNG for images with solid colour, and JPEGs for photos. Ensure appropriate compression keeps the image sizes in check (e.g. reduce the palette, or use more lossy compression for JPEGs). Avoid error diffusion for GIFs unless absolutely essential, as it massively increases file size – PNGs are usually much better.
  • Avoid bloated Javascript. Only include Javascript files that the page actually requires. Most webpages are better served using server-side scripting, which results in much faster pages that are also more likely to be spiderable, accessible and optimized for search engines.

See Google’s excellent list of rules for website optimization for more.

How to use this test effectively

Firstly, always ensure you have set the target Connection speed correctly for your site before using this test. Most websites target a medium speed broadband audience, but yours may vary.

Use this test as a health check to see whether your pages are loading quickly enough. Wherever possible, take measures to improve the speed of your website to an appropriate level (this depends on what you have set as the target Internet speed of your audience).

Further reading

Was this article helpful? Contact our support team if you have a question.