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