Performance monitoring serves two critical purposes: to check a web site’s availability and to validate the speed at which pages from the web site download. Site availability is very easy to define; it’s either up or it’s down. There isn’t too much in between. Page download speeds can be a bit trickier to define because there are many different ways to delineate a web page’s load time. This is generally due to the nature of performance monitoring, in which an automated browser makes a request for a web page and tracks the time it takes to get all of the data (including images, objects, JavaScript, etc.) for that page. Compare that to how a human would interact with the page. A human would type in the URL, click on ‘Go’ and as data is returned to the browser the user would immediately start interacting with the web page. They may use the search functionality that loads right away while ignoring all other information on the page. Or they may only be interested in an article whose text is already displayed and therefore not concerned with any of the other content that loads as part of the page download. This is the great divide between human and machine. The machine has a repetitive task that it must complete and therefore rarely wanders outside of the boundaries of the absolute, while the human very capably perceives the page as complete in what may seem an arbitrary manner.
This is the difference between actual load time and perceived load time. Actual load time is what machines such as a performance monitoring tool measure – and as a process is repeatable, generic, and objective. Perceived load time is what a human would measure and can be arbitrary and subjective. Take, for example, Amazon’s web page. In the image below the browser window shows content that has been downloaded and rendered, but that’s not all the content that is downloaded and needs to be rendered.
Below the window is content for the top sellers feature, recent history feature, and an Amazon logo that also need to be rendered. To a human that wants to search Amazon’s inventory, or click on the ad for the razor, the page appears to be fully loaded. To a machine, the page may not be fully loaded because it is still requesting objects, rendering CSS, and processing JavaScript to build the part of the page that isn’t showing. So the question becomes, which method is best for measuring page load time performance?
In most cases, performance monitoring data is generated to support a Service Level Agreement (SLA) that has been provided to users of the site or to track load time anomalies and look for trends in performance. In the case of SLA support, a repeatable process and an objective dataset is an absolute must. SLAs are often intended to cover a large set of users and different user behaviors; therefore, load times should be absolute and should involve all data and processes within the delivery chain. This includes data that isn’t currently being displayed to the user but is expected to be delivered. For performance and trend analysis, it is also generally preferred to rely on the actual load time. The actual load time should be used because the purpose of trending performance is to check on the health of the system or to make decisions for all users of the web site based off of that data. In that case, it doesn’t make sense to base those decisions off of data that was generated from the perspective of an arbitrary user (i.e., perceived load time). For example, the portion of the page that is being currently displayed to the end user can be impacted by the size of their browser window and the resolution of their monitor (parameters that will not be consistent across users). In both cases, it is best to rely on metrics that report the actual load time since the dataset is objective and is consistent from sample to sample.
Comments are closed.