KEEP AN EAGLE EYE ON EVERYTHING IT

Tips and Insights on:

  • Website, Server, Database monitoring
  • Optimization and Web Design
  • Uptime and Server performance

Website Performance: Server to Client Wrap-up

Website Performance: Taxonomy of Tips intro­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.  In Emp­ty Src and Href At­tri­butes, Com­po­nent Caching, and Image Processing for Performance, we ex­a­mined tips that af­fect the “jour­ney from the ser­ver to the cli­ent.”  We wrap up this dis­cus­sion today by sum­ma­riz­ing a few other tips that fall in­to this ca­te­go­ry.There are se­ve­ral good tips that af­fect round trip time, but do not fit in­to the “response’s jour­ney from the ser­ver to the cli­ent” ca­te­go­ry.  They can be found in the “request’s jour­ney from the cli­ent to the ser­ver” or “syn­chro­ni­ci­ty” ca­te­gor­ies.

Data Compression

The sizes of .html, .txt, .js, .css, .xml, .json, and other text files can be re­duced sub­stan­tial­ly by com­pres­sion.  For­tu­nate­ly, web ser­vers pro­vide an op­tion to com­press data im­me­di­ate­ly be­fore it be­gins its jour­ney to the cli­ent.

Un­for­tu­nate­ly, our web ser­ver’s de­fault con­fi­gur­a­tion may com­press only .html files.  It may not com­press every­thing it could.  Web ser­vers should be re­con­fi­gured to com­press all text da­ta.  Apa­che, for ex­am­ple, sug­gests this con­fi­gu­ra­tion:

	SetOutputFilter DEFLATE
	BrowserMatch ^Mozilla/4 gzip-only-text/html
	BrowserMatch ^Mozilla/4\.0[678] no-gzip
	BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
	SetEnvIfNoCase Request_URI \
	\.(?:gif|jpe?g|png)$ no-gzip dont-vary
	Header append Vary User-Agent env=!dont-vary

Web cli­ents in­sert the Accept-Encoding head­er line in­to the HTTP re­quest to in­di­cate which com­pres­sion al­go­rithms they sup­port.  The web ser­ver com­press­es the re­sponse us­ing one of these al­go­rithms and in­serts the Content-Encoding head­er line in­to the re­sponse to in­di­cate which me­thod it used.

Image files should not be com­pressed this way be­cause they will be pro­cessed over and over again at a time when it af­fects per­for­mance.  In­stead, i­ma­ges should be com­pressed pri­or to be­ing trans­ferred to pro­duc­tion so the web ser­ver can trans­mit them as-is.

PDF files are al­ready com­pressed.  Ask­ing the web ser­ver to com­press them again not on­ly wastes CPU cyc­les, but may al­so in­crease the file size.

Avoid Redirects, 404’s, and 410’s

Web­pages shouldn’t be ask­ing for com­po­nents that are miss­ing or moved.  The test­ing phase is sup­posed to find and re­move all such prob­lems.  See­ing these in pro­duc­tion makes the user ques­tion the busi­ness’ com­pe­tence, which leads ma­nage­ment to ques­tion the de­ve­lo­pers’ com­pe­tence.

Apart from the da­maged re­pu­ta­tions, there is yet an­oth­er rea­son to a­void re­di­rects.  Send­ing er­ror in­for­ma­tion back to the cli­ent, mak­ing the cli­ent then re­quest a dif­fe­rent re­source, and send­ing the cor­rect re­source back to the cli­ent all af­fect round-trip time, and that af­fects per­form­ance.

Serve Components From Single URLs

Some­times a com­po­nent is re­fe­renced more than once in a web page.  More fre­quent­ly the com­po­nent is re­fe­renced mul­ti­ple times from mul­ti­ple pages.  If the pages use more than one URL to i­den­ti­fy the com­po­nent, the brow­ser’s cach­ing me­cha­nism does not recog­nize the two URL’s as one sin­gle com­po­nent.  This means the brow­ser will esta­blish a con­nec­tion and down­load the com­po­nent again, e­ven though it is al­rea­dy in the cache.

Example:  If we some­times re­fer to Fred’s pic­ture as http://ourDomain.com/image/fred.jpg and some­times as http://www.ourDomain.com/image/fred.jpg, the brow­ser will see fred.jpg as two dif­fe­rent ima­ges and will cache it twice.

Every com­po­nent should be iden­ti­fied ex­clu­sive­ly by one sin­gle URL.

Monitor Network Performance

Web­apps de­pend on the server’s in­fra­struc­ture.  If the sys­tem is not pro­vid­ing ac­cept­able ser­vice, this af­fects the web­app’s per­for­mance.  Keep­ing an eye on low-level per­for­mance is just as im­por­tant as keep­ing an eye on web­app per­for­mance.  Ex­ample  If the ser­ver is ex­peri­enc­ing high packet loss, which re­sults in high re­trans­mission rates, the web­app will take long­er to down­load.

For­tu­nate­ly, Monitis pro­vides an easy-to-use plat­form that lets us mo­ni­tor every­thing, in­clud­ing low-level func­tion­a­li­ty.  WMI con­tains all the Win­dows da­ta we need and Moni­tor­ing WMI Da­ta With VbScript dis­cusses how to mo­ni­tor it.  If we are deal­ing with a Unix sys­tem, Mo­ni­tor­ing Di­rec­tory Size shows us that the out­put from shell com­mands (e.g., iperf, which re­ports net­work per­form­ance) can be mo­ni­tored just as eas­i­ly.

Set up Mo­ni­tis mo­ni­tors to con­tinu­al­ly mea­sure net­work per­formance and to no­ti­fy you when it is un­ac­cept­able.  No­ti­fi­ca­tions can be sent by SMS text mes­sag­ing, e-mail, or post­ing to a web page you cre­ate.  This ap­proach gives you ul­ti­mate flex­i­bi­li­ty with very lit­tle ef­fort on your part.

Eliminate White Space and Comments That Aren’t Needed

Ex­tra­ne­ous white space and com­ments im­prove the read­abi­li­ty and main­tain­abi­li­ty of source code, but there is no rea­son for them to be trans­mit­ted from the ser­ver to the cli­ents.  Af­ter cre­at­ing the source code with all its white space and com­ments, run it through a mi­ni­fi­er to strip out all the stuff the brow­ser doesn’t need.  Keep the o­ri­gi­nal for fu­ture use and trans­fer the mi­ni­fied ver­sion to pro­duc­tion.  Keep life sim­ple by auto­mat­ing this as part of the build pro­cess.

Eliminate JavaScript and CSS That Isn’t Needed

With the com­plex de­pen­den­cies be­tween a large num­ber of CSS and Java­Script files in a ty­pi­cal pro­ject, it is fair­ly com­mon to see du­pli­ca­tion with­in a down­load­ed web page.  Be­cause of this, some brow­sers re­quest the same com­po­nent more than once.  Even worse, CSS and Java­Script are of­ten down­load­ed for a page, then ne­ver used on that page.

Here’s a so­lu­tion:  Write a server-side func­tion to down­load Java­Scripts and an­oth­er to down­load CSS.  The func­tions make sure each com­po­nent is in­clud­ed on­ly once and all de­pen­den­cies are tak­en care of.  They can even in­line sta­tic com­po­nents into sta­tic web pages while keep­ing dy­na­mic com­po­nents ex­ter­nal.

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.

Let’s Make the Web Faster.  Published by Google at code.google.com/speed/articles.  Accessed 2011.11.30.  This is a directory of 20 links to performance-related tutorials.

Minimize Payload Size.  Published by Google at code.google.com/speed/page-speed/docs/payload.html.  Accessed 2011.12.27.

Minimize Round-Trip Times.  Published by Google at code.google.com/speed/page-speed/docs/rtt.html.  Accessed 2011.12.26/

Monitis Free Page Load Testing Tool.  Published by Monitis at pageload.monitis.com.  Accessed 2011.12.20.

Monitoring Directory Size by Warren Gaebel.   Published 2011.12.22 by Monitis at blog.monitor.us/2011/12/monitoring-directory-size.  Accessed 2012.01.07.

Monitoring WMI Data With VbScript by Warren Gaebel.  Published 2011.11.30 by Monitis at blog.monitor.us/2011/11/monitoring-wmi-data-with-vbscript.  Accessed 2012.01.07.

Ten Tips for Writing High-Performance Web Applications by Rob Howard.  Published 2005/01 by Microsoft at msdn.microsoft.com/en-us/magazine/cc163854.aspx.  Accessed 2011.11.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.monitor.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.

This entry was posted in Website Performance and tagged , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.
trusted by
trusted by trusted by trusted by trusted by trusted by
About Monitor.Us

Monitor.Us, the free version of Monitis, the specialist web and cloud systems monitoring service that provides website monitoring, web page load testing, transaction monitoring, application and database monitoring, web page load testing,transaction monitoring, application and cloud resource monitoring, and server and internal network monitoring within one easy-to-use dashboard. Monitor.Us gives home and small business users access to leading-edge availability and performance monitoring within one easy-to-use dashboard. For more information please visit Monitor.Us.

Follow Monitor.Us on Facebook
Follow Monitor.Us on Twitter