This is a continuation of a series of blog entries on this topic. The series starts here.
Focusing as the original YSlow approach does on the web page composition process performed inside the browser, one of YSlow’s legacies is that it spawned the development of web application performance tools that measure the page load time, addressing one of the important limitations of the original YSlow approach. Browser-based tools like Chrome’s PageSpeed do measure page load time and visualize the page composition process as a waterfall diagram unfolding over time. The browser-based approach still faces the limitation that it can only measure page load time from a single vantage point on the network, which is hardly representative of actual network latencies.
Figure 10 is a screen shot from a WebPageTest timing test that I performed on the Amazon Home page. There is so much going on in that rich display of performance data – partly because WebPageTest provides so much information about page load time and partly because the Amazon home page itself is so complex – that a single screen shot hardly does justice to the tool. You can, however, access this example directly using the following hyperlink to the performance test results for the Amazon page: http://www.webpagetest.org/result/140912_6Y_R46/1/details/. Better yet, you can sign up to use the site, which is free of charge, and run the performance test against your own web site.
In addition, WebPageTest attempts to provide a set of more representative and realistic network latencies to measure by being able to host your test at a range of different locations scattered around the globe. After selecting one of the available locations for the performance test, WebPageTest builds a waterfall view of the page composition process that is similar to PageSpeed, as illustrated in Figure 10, where I again used the Amazon.com home page for an example. The WebPageTest view even incorporates YSlow-like performance rules and letter grades. In this example, the Amazon web page initially took about 5 seconds to load, but then continued to load content for another 6 seconds or so after the onload event fired and the window.load event handler began to execute.
In an attempt to address the second measurement issue, WebPageTest considers the web page to be visually complete after 13.7 seconds, a measurement that is based on comparing successive video images until a final, static video is captured. The “visually complete” measurement is intended to augment page load time measurements, particularly useful when, as in this example, the window.load event handler performs extensive and time-consuming DOM manipulation.
Another innovative aspect of the WebPageTest toolset that is innovative is its UI enhancements to the waterfall diagram used to show the page composition process over time. Figure 10 illustrates how the delay associated with each GET Request is decomposed into the consecutive stages required to resolve the Request. If any DNS lookup is required, TCP protocol connection hand-shaking, or SSL negotiation, these delays are indicated visually. In addition, the Time to First Byte is also distinguished visually from any subsequent packets that may have been required to send the full Response message. (These are distinguished in the tool as a delay associated with “content download.”)