Website Performance: Taxonomy of Tips introduced a classification scheme to help us organize the many performance tips found on the Internet. My following three articles reviewed the tips that affect the response’s journey from the server to the client category. Today’s article begins the discussion about the synchronicity category.
Serial vs. Asynchronous Events
Many events occur from the time the user initiates a request to the time the request is completely fulfilled. If all those events occur one at a time, in order, each waiting for the previous one to complete, the total amount of time required to handle the user’s request is the sum of the times of each of the events. This is called serial processing, which is a form of synchronous processing.
If we can make multiple events occur at the same time, we can reduce the amount of time required to fulfill the user’s request. This is the concept behind asynchronous processing. To the extent we do not overtax system resources, asynchronous processing delivers better performance than serial processing. Once we start overtaxing system resources, though, asynchronous processing can actually deliver poorer performance, as demonstrated in figure 4 of Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane.
Postponing Processing
In Performance on the Yahoo! Homepage, Nicholas Zakas defines time-to-interactivity as “the time between the initial page request and when the user can complete an action.” Because the user’s perception of performance is based on when he or she can get on with the next step, time-to-interactivity is a more important measure than time-to-page-load.
If we can postpone processing until after the user thinks the page is loaded, that will give the perception of better performance, even if it is in fact worse performance. This is a form of asynchronous processing wherein we are completing system processing in parallel with human processing. As the user reads the web page and decides what to do next, the system is busily completing all the other things it needs to do.
In general terms, web page components fall into three categories: those that are needed to render the page to the point where it is understandable and useable (e.g., the CSS that formats the page); those that will most likely be needed soon after interactivity has been achieved (e.g., frequently used JavaScript functions); and those that are less likely to be needed until later, if at all (e.g., functionality that is almost never used). Components in the first category need to be downloaded and processed immediately, those in the second category can be processed after interactivity has been achieved, and those in the final category can be processed later or on demand. [We should be careful about on demand processing, though, because it’s a guarantee that the user has to wait.]
Preprocessing
After our code has finished doing everything it needs to do for the current web page, and while the user is still reading the page and deciding what to do next, the system has nothing to do. Or does it? If we can guess what the user will do next, why don’t we start loading and caching the components for the next web page? We don’t even need to be 100% certain about the user’s next move. If we guess wrong, our web application isn’t doing anything anyhow, so let’s go for it.
Of course, there are limits. If we are only 10% certain about the user’s next move, that may not be enough justification to place an additional load on our server (or the client’s machine, for that matter).
Other Opportunities
This article leans heavily on the asynchronous downloading of web page components as an example, but there are other ways of achieving asynchronization. Any event that occurs between the time the user issues a request and the time the request is fulfilled is an opportunity.
Coming Up Next
My next article will look at the asynchronous and deferred loading and execution of JavaScript, a topic that has generated many online articles that seem to all say slightly different things. Coming soon to the monitor.us blog.
References
Best Practices for Speeding Up Your Web Site by Yahoo’s Exceptional Performance Team. Published by Yahoo at developer.yahoo.com/performance/rules.html. Accessed 2011.11.30.
High Performance Web Sites – 14 Rules for Faster-Loading Web Sites by Steve Souders. Published by Steve Souders at SteveSouders.com/hpws/rules.php. Accessed 2011.11.30.
Paid Monitor Free Page Load Testing Tool. Published by Paid Monitor at pageload.monitor.us. Accessed 2011.12.20.
Performance on the Yahoo! Homepage by Nicholas C. Zakas. Published by SlideShare.net at www.slideshare.net/nzakas/performance-yahoohomepage. Accessed 2011.11.30.
Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane by Tenni Theurer and Steve Souders. Published 2007.04.11 by Yahoo at yuiblog.com/blog/2007/04/11/performance-research-part-4. Accessed 2011.12.30.
Top Ten Web Performance Tuning Tips by Patrick Killelea. Published 2002.06.27 by O’Reilly at OReilly.com/pub/a/javascript/2002/06/27/web_tuning.html. Accessed 2011.11.30.
Web Performance Best Practices. Published by Google at code.google.com/speed/page-speed/docs/rules_intro.html. Accessed 2011.11.30.
Website Performance: Taxonomy of Tips by Warren Gaebel. Published 2011.12.29 by Paid Monitor at blog.monitor.us/2011/12/website-performance-taxonomy-of-tips. Accessed 2012.01.02
Try Paid Monitor For Free. A 15-day free trial. Your opportunity to see how easy it is to use the Paid Monitor cloud-based monitoring system. Credit card not required.
The Paid Monitor Exchange at GitHub. This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Paid Monitor system to its full potential.
