Performance Tests for Web

How can you find if your website is fast enough? You would like to know an answer to this question before angry customers start complaining in social networks, and probably even before your code is deployed to the production environment.

There are two kinds of tests which can be useful: individual web page performance tests and load tests.

Performance of a web page is usually measured in a real web browser. One of the popular tools to automate such tests is WebPageTest. WebPageTest starts a new instance of chosen web browser, for example, Chrome, navigates to specified URL and waits for the page to complete loading. Loading here includes receiving HTTP response, CSS styles, JS scripts, images, fonts and all other stuff on the page, then rendering the page and executing scripts. WebPageTest measures time to render, time to full complete, number of HTTP requests and few other metrics; captures a timeline of loading of different resources and opening/closing HTTP connections. It can also capture video of page loading and a screenshot. Then it starts the process again to measure repeat visit: it is usually faster because some resources are already cached by the browser.

You can either use public instance of WebPageTest or host a private instance. WebPageTest instance should include a server and one or more agents. The server just distributes test jobs and stores results, and agents actually do all the work: starting web browsers and running tests.

The public instance is useful if you want to check website performance for users in different parts of the world. If you host the website in California, but your customers are in Japan and you worry about latency, it is easy to start a test using a test agent located in Tokyo.

However, the public WebPageTest server restricts number of tests by IP, and if you need running many tests it can be an obstacle. Also, you will not be able to run tests for websites which are not exposed to the internet, e.g. your development or staging environments. For such cases, a private WebPageTest instance is a good solution.

WebPageTest tests can be scheduled either from UI or via API. API is fairly simple, based on XML (see documentation here).

It is easy to test performance of individual web pages, but what if you want to test a page with dynamic URL, or a page which is accessible only for logged in users? WebPageTest allows to test complex scenarios. You can describe a scenario like “open http://www.google.com, enter ‘test query’ into search box, click ‘Search’, start measuring, and wait for load complete”. Though this functionality is very buggy and hard to develop and debug. I would not recommend to use it. It could be much better to create a custom tool, for example, based on Selenium framework, to do such complex performance tests.

 

If WebPageTest shows that performance of your pages is perfect, it does not mean that you can relax. It might be that performance is fine when there is only one user on the site, and it will degrade when load increases to 10 or 100 simultaneous users. To test it you need to generate large load: simulate multiple users hitting the site. These tests are called load tests.

There are many tools which can help to perform such tests. Perhaps the most popular one is JMeter. You can describe a scenario as a sequence of HTTP requests, make JMeter execute that scenario repetitiously with multiple threads, and measure execution time of each HTTP request and resource utilization (CPU, Memory, IO, Network, etc.) on the servers. The trick here is to make load testing environment as close to the production environment as possible, and make test scenario close to real user behavior.