Skip to main content

Webpagetest and measuring visual completeness -- why is this web app running slowly, Part 8.

This is a continuation of a series of blog entries on this topic. The series starts here.

In this post, I discuss one more performance tool that belongs in the YSlow family. It is called WebPageTest, and it makes a credible attempt at addressing some of the limitations of the YSlow approach I have been writing about. The WebPageTest tool does measure Page Load time, and offers several other useful goodies, including a revised set of performance optimization rules to consider. WebPageTest builds on the legacy of YSlow, while also trying to address some of the limitations of the original approach with today’s JavaScript-enhanced web applications. 

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. 

Another limitation of the browser-based approach is that the traditionally Page Load time measurement, which is signaled by the firing of the DOM’s window.load event, may no longer represent a clear, unambiguous boundary for the response time event. As web pages perform more and more JavaScript manipulation of the DOM during execution of the window.load event handler, this boundary can be blurred beyond recognition in extreme cases. It is another case of evolving web technologies requiring new measurement approaches.

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: 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.

Figure 10. The waterfall view of the page composition process in the tool, which measures the performance of the home page in this example.

Across the top of the Test Result page, the WebPageTest detail report proudly shows its YSlow heritage by computing a “PageSpeed” score and a set of letter grades, similar to YSlow, based on the web page conforming to a set of mostly familiar performance rules, including the usual recommendations to minify Http objects and compress Response messages, enable caching, and defer parsing of JavaScript, etc. You may also notice some distinctly new rules reflecting current trends in more complex web page composition, like prioritizing visible “above the fold” content. The “above-the-fold” terminology is borrowed from grahic design principles of printed (and folded) newspaper layout, where the goal, back in the heyday of the printed press, was to capture Readers’ eyeballs from the content visible on the front page above the fold. The web page load focuses on content that first becomes visible without recourse to scrolling, ignoring for a moment the complication that while the fold was a physical artifact of the manner in which printed newspapers are displayed at a newsstand, the extent of the web page content that is first visible in a browser window is a function of both the physical display size, which is permanent, and the current size of the browser window, which is subject to change.

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 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.”) 

Visually, the WebPageTest also adds an overlay line to indicate in the waterfall diagram when the window.load event fired, which gives you a way to assess how much JavaScript processing of the DOM occurs after the event that signals that the Page is loaded fires. If major DOM manipulation is deferred to the window.load event handler, the WebPageTest waterfall diagram reflects that, in effect, directing you to weigh using the Visually Complete measurement instead of Page Load as the better available performance indicator.

Next: Real User Measurements using the NavTiming API


Popular posts from this blog

Inside the Windows Runtime, Part 2

As I mentioned in the previous post, run-time libraries in Windows provide services for applications running in User mode. For historical reasons, this run-time layer in Windows was always known as the Win32 libraries, even when these services are requested in the 64-bit OS in 32-bit mode. A good example of a Win32 run-time service is any operation that involves opening and accessing a file somewhere in the file system (or the network, or the cloud). A more involved example is the set of Win32 services an application needs to access to play an audio file, including understanding the specific audio file compressed format, and checking authorization and security.
For Windows 8, a portion of the existing Win32 services in Windows were ported to the ARM hardware platform.  The scope of the Win32 API is huge, and it was probably not feasible to convert all of it during the span of a single, time-constrained release cycle. Unfortunately, the fact that the new Windows 8 Runtime library encomp…

High Resolution Clocks and Timers for Performance Measurement in Windows.

Within the discipline of software performance engineering (SPE), application response time monitoring refers to the capability of instrumenting application requests, transactions and other vital interaction scenarios in order to measure their response times. There is no single, more important performance measurement than application response time, especially in the degree which the consistency and length of application response time events reflect the user experience and relate to customer satisfaction. All the esoteric measurements of hardware utilization that Perfmon revels in pale by comparison. Of course, performance engineers usually still want to be able to break down application response time into its component parts, one of which is CPU usage. Other than the Concurrency Visualizer that is packaged with the Visual Studio Profiler that was discussed in the previous post, there are few professional-grade, application response time monitoring and profiling tools that exploit the …

Why is my web app running slowly? -- Part 1.

This series of blog posts picks up on a topic I made mention of earlier, namely scalability models, where I wrote about how implicit models of application scalability often impact the kinds of performance tests that are devised to evaluate the performance of an application. As discussed in that earlier blog post, sometimes the influence of the underlying scalability model is subtle, often because the scalability model itself is implicit. In the context of performance testing, my experience is that it can be very useful to render the application’s performance and scalability model explicitly. At the very least, making your assumptions explicit opens them to scrutiny, allowing questions to be asked about their validity, for example.
The example I used in that earlier discussion was the scalability model implicit when employing stress test tools like HP LoadRunner and Soasta CloudTest against a web-based application. Load testing by successively increasing the arrival rate of customer r…