Performance By Design

This is a continuation of a series of blog entries on this topic. The series starts  here :  http://computerperformancebydesign.com/why-is-my-web-app-running-slowly-part-1/ Real User Measurements (RUM) The other way to obtain client-side Page Load time measurements – and one that is becoming increasingly popular – is a tool that measures page load time from inside the browser. The web browser-based performance tools we have looked at like ChromeSpeed or the corresponding Network tab in the Internet Explorer Developer Tools measure page load time from inside the web client. But, as we saw, those performance tools function like YSlow, requiring you to have direct (or remote) access to the web client. Real User Measurements refer to measurements of how long it took to access your web site acquired from inside the web browser running on your customers’ machines and operated directly by them. Those are the real users whose experience with our web sites we want to capture and ...

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

This is a continuation of a series of blog entries on this topic. The series starts  here . Since HTTP is a wire protocol built on top of TCP/IP, the network packet sniffer technology that is widely used in network diagnostics and performance optimization is readily adapted to measuring web browser Page Load time. Network sniffers like WireShark can intercept and capture all the HTTP traffic and are typically configured to gather related network events, such as DNS look-ups. It is easy to get overwhelmed with all the information that these network diagnostic tools provide. Often software developers prefer network tools that are more focused on the HTTP protocol and the page composition process associated with assembling the DOM and rendering it in the browser. The Developer Tools that ship with the major web browsers include performance tools that measure Page Load time and help you diagnose why your page is slow to load. These tools work by analyzing the network packets sent an...

This is a continuation of a series of blog entries on this topic. The series starts  here . In this post, I will discuss three approaches to measuring actual web page load times, something which is quite important for a variety of reasons, some of which I have already discussed. Measurements of web page load time capture service level measurements from the standpoint of the customer. Service level measurements also enable performance analysts to use decomposition techniques, breaking down page load time into its components: browser render time, network transmission delays, IP domain name lookup, TCP session connection, etc. The first approach to measuring web page load times was built on top of network packet capture technology, which was already capable of capturing the network packets associated with HTTP GET and POST Requests and their associated Response Messages. Packet tracing is associated with network sniffers like WireShark and Netmon that play a huge role in the data...

This is a continuation of a series of blog entries on this topic. The series starts  here . With the emergence of the Web 2.0 standards that enabled building dynamic HTML pages, web applications grew considerably more complicated, compared to the static view of the page composition process that the YSlow scalability model embodies. Let’s review some of the more important factors that complicate the (deliberately) simple YSlow model of Page Load Time. These complications include the following: YSLow does not attempt to assess JavaScript execution time, something that is becoming more important as more and more complicated JavaScript is developed and deployed. JavaScript execution time, of course, can vary based on which path through the code is actually executed for a given request, so the delay can vary, depending on the scenario requested. The processing capacity of the underlying hardware where the web client that executes the script resides is also a factor. This is especial...

This is a continuation of a series of blog entries on this topic. The series starts  here . The YSlow model of web application performance, depicted back in Equations 3 & 4 in the previous post , leads directly to an optimization strategy to minimize the number of round trips, decrease round trip time, or both. Several of the YSlow performance rules reflect tactics for minimizing the number of round trips to the web server and back that are required to render the page. These include designing the Page so there are fewer objects to Request,  using compression to make objects smaller so they require fewer packets to be transmitted, and  techniques for packing multiple objects into a single request.  For example, the recommendation to make fewer HTTP requests is in the category of minimizing round trips. YSlow rules regarding image compression or the use of “minified” external files containing JavaScript and CSS are designed to reduce the size of Response me...

This is a continuation of a series of blog entries on this topic. The series starts  here . In this post, I will begin to  probe a little deeper into the model of web page response time that is implicit in the YSlow approach to web application performance.  The YSlow performance rules, along with Souder’s authoritative book that describes the YSlow corpus of recommendations and remedies in more detail, have proved to be remarkably influential among the current generation of web application developers and performance engineers. The scalability model that is implicit in the YSlow performance rules is essentially a prediction about the time it takes to compose a page, given the underlying mechanics of web page composition that entails gathering and assembling all of the files associated with that page. One benefit of the model is that it yields an optimization strategy for constructing web pages that will load more efficiently. The YSlow performance rules embody th...