Website load testing is only subtly different from web application load testing because it implies anonymous browsing static pages rather than authenticating and being served dynamically created pages.
That may not be true in many cases because people use the terms “website” and “site” to designate any browser-based user interface. For example, I could say that your site looks good, and underneath your UI is a content management system generating every page on the fly.
So by my definition, website load testing is technically about using a web server such as Apache or IIS to deliver HTML pages with images or other embedded-media. Requesting a specific “file.html” or perhaps randomly clicking links found on a page is the norm for website load testing. It would not include logging in, posting a blog, buying a T-shirt, or registering for contest.
The “web” part of website load testing also is significant. HTTP traffic is the key differentiator for web load testing as contrasted to load testing of a client server application.
The key performance indicators are response times, requests per second, throughput, error rate, and concurrent users. There would, however, be no focus on database access monitoring. Performance tuning a website is much easier than an application because there is no PHP or Ruby code to debug. There is also no concern for expensive SQL queries, nor will programmers be worried about JVM thread pools.
Website load testing may involve analyzing data from a load balancer on the front end. Tuning aspects of the web server configuration is also in play. Turning on GZIP would apply for website testing because it will assist in speeding up static page delivery by compressing resources before transmitting to the browser. Stylesheets may be involved. AJAX libraries may be requested and returned. Don’t be fooled into thinking that website load testing is a piece of cake – it still requires knowledge of many moving parts in today’s web architecture.
Web load testing usually requires a tool that can generate large amounts of users taking certain actions against a target domain or set of servers. The objective is to measure how the site responds to the clicks and page requests when the web server is under heavy load of simulated virtual users.
Under heavy load, web servers will start to return status codes indicating errors are occurring. For instance, when the web system gets overwhelmed it may deny a user’s connection at the TCP layer. Web application load testing usually generates more variety of errors to diagnose because there is another two layers of architecture to fail: application and database.