Everything about Web and Network Monitoring

Website Performance: Synchronicity

Web­site Per­formance: Tax­o­no­my of Tips in­tro­duced a clas­si­fi­ca­tion scheme to help us or­ga­nize the many per­for­mance tips found on the In­ter­net.  My fol­low­ing three ar­ti­cles re­viewed the tips that af­fect the re­sponse’s jour­ney from the ser­ver to the cli­ent cat­e­go­ry.  To­day’s ar­ti­cle be­gins the dis­cus­sion about the syn­chro­ni­ci­ty cat­e­go­ry.

Serial vs. Asynchronous Events

Many events oc­cur from the time the user in­i­ti­ates a re­quest to the time the re­quest is com­plete­ly ful­filled.  If all those events oc­cur one at a time, in or­der, each wait­ing for the pre­vi­ous one to com­plete, the to­tal amount of time re­quired to han­dle the user’s re­quest is the sum of the times of each of the events.  This is called ser­i­al pro­cess­ing, which is a form of syn­chro­n­ous pro­cess­ing.

If we can make mul­ti­ple events oc­cur at the same time, we can re­duce the amount of time re­quired to ful­fill the user’s re­quest.  This is the con­cept be­hind asyn­chro­nous pro­cess­ing.  To the ex­tent we do not over­tax sys­tem re­sour­ces, asyn­chro­nous pro­cess­ing de­li­vers bet­ter per­for­m­ance than ser­i­al pro­cess­ing.  Once we start over­tax­ing sys­tem re­sour­ces, though, asyn­chro­n­ous pro­cess­ing can ac­tu­al­ly de­li­ver poor­er per­for­m­ance, as de­mon­stra­ted in figure 4 of Per­form­ance Re­search, Part 4: Max­i­miz­ing Pa­ral­lel Down­loads in the Car­pool Lane.

Postponing Processing

In Per­form­ance on the Yahoo! Home­page, Nicholas Zakas de­fines time-to-in­ter­ac­ti­vi­ty as “the time be­tween the ini­tial page re­quest and when the user can com­plete an ac­tion.”  Be­cause the user’s per­cep­tion of per­form­ance is based on when he or she can get on with the next step, time-to-in­ter­ac­ti­vi­ty is a more im­por­tant mea­sure than time-to-page-load.

If we can post­pone pro­cess­ing un­til af­ter the user thinks the page is load­ed, that will give the per­cep­tion of bet­ter per­form­ance, even if it is in fact worse per­form­ance.  This is a form of asyn­chro­nous pro­cess­ing where­in we are com­plet­ing sys­tem pro­cess­ing in par­al­lel with hu­man pro­cess­ing.  As the user reads the web page and de­cides what to do next, the sys­tem is bu­si­ly com­plet­ing all the other things it needs to do.

In ge­ne­ral terms, web page com­po­nents fall in­to three ca­te­go­ries:  those that are need­ed to ren­der the page to the point where it is un­der­stand­able and use­able (e.g., the CSS that for­mats the page); those that will most like­ly be need­ed soon after in­ter­ac­ti­vi­ty has been achiev­ed (e.g., fre­quent­ly used Java­Script func­tions); and those that are less like­ly to be need­ed un­til later, if at all (e.g., func­tion­al­i­ty that is al­most ne­ver used).  Com­po­nents in the first ca­te­go­ry need to be down­load­ed and pro­cess­ed im­me­di­ate­ly, those in the se­cond ca­te­go­ry can be pro­cessed af­ter in­ter­ac­ti­vi­ty has been achieved, and those in the fi­nal ca­te­go­ry can be pro­cessed la­ter or on de­mand.  [We should be care­ful about on de­mand pro­cess­ing, though, be­cause it’s a guar­an­tee that the user has to wait.]


Af­ter our code has fi­nished do­ing eve­ry­thing it needs to do for the cur­rent web page, and while the user is still read­ing the page and de­cid­ing what to do next, the sys­tem has no­th­ing to do.  Or does it?  If we can guess what the user will do next, why don’t we start load­ing and cach­ing the com­po­nents for the next web page?  We don’t even need to be 100% cer­tain about the user’s next move.  If we guess wrong, our web ap­pli­ca­tion isn’t do­ing any­thing any­how, so let’s go for it.

Of course, there are li­mits.  If we are only 10% cer­tain about the user’s next move, that may not be enough jus­ti­fi­ca­tion to place an ad­di­tion­al load on our ser­ver (or the cli­ent’s ma­chine, for that mat­ter).

Other Opportunities

This ar­ti­cle leans hea­vi­ly on the asyn­chron­ous down­load­ing of web page com­po­nents as an ex­am­ple, but there are other ways of achiev­ing asyn­chro­ni­za­tion.  Any event that oc­curs be­tween the time the user is­sues a re­quest and the time the re­quest is ful­filled is an op­por­tu­ni­ty.

Coming Up Next

My next ar­ti­cle will look at the asyn­chro­nous and de­ferred load­ing and ex­e­cu­tion of Java­Script, a to­pic that has ge­ne­rat­ed ma­ny on­line ar­ti­cles that seem to all say slight­ly dif­fe­rent things.  Com­ing soon to the mon.itor.us blog.


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.

Monitis Free Page Load Testing Tool.  Published by Monitis at pageload.monitis.com.  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 Monitis at blog.mon.itor.us/2011/12/website-performance-taxonomy-of-tips.  Accessed 2012.01.02

Try Monitis For Free.  A 15-day free trial.  Your opportunity to see how easy it is to use the Monitis cloud-based monitoring system.  Credit card not required.

The Monitis Exchange at GitHub.  This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Monitis system to its full potential.

About Warren Gaebel

Warren wrote his first computer program in 1970 (yes, it was Fortran).  He earned his Bachelor of Arts degree from the University of Waterloo and his Bachelor of Computer Science degree at the University of Windsor.  After a few years at IBM, he worked on a Master of Mathematics (Computer Science) degree at the University of Waterloo.  He decided to stay home to take care of his newborn son rather than complete that degree.  That decision cost him his career, but he would gladly make the same decision again. Warren is now retired, but he finds it hard to do nothing, so he writes web performance articles for the Monitor.Us blog.  Life is good!