KEEP AN EAGLE EYE ON EVERYTHING IT

Tips and Insights on:

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

Image Processing for Performance

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.  Empty Src and Href Attri­butes and Com­po­nent Cach­ing then start­ed to ex­a­mine the “jour­ney from the ser­ver to the cli­ent” cate­gory.  We con­tinue look­ing at that ca­te­go­ry here by ex­a­min­ing the im­pact that images have on the jour­ney.In ge­ne­ral, the smal­ler the image, the smal­ler the da­ta stream sent from the ser­ver to the cli­ent.  Ob­vi­ous­ly, mi­ni­miz­ing the amount of da­ta sent to the cli­ent im­proves per­for­mance.

Choose the Format that Reduces the Size

There are two types of ima­ges, ras­ter and vec­tor.  Ras­ter ima­ges are stored as pic­ture el­e­ments (pixels); vec­tor ima­ges are stored as curves.  Every image can be stored as either a ras­ter image or as a vec­tor image, but one file will be small­er than the other and one image may look bet­ter than the other.  Example:  A pho­to­graph is usu­al­ly stored as a ras­ter image be­cause pho­to­graphs usu­al­ly do not look good as vec­tor ima­ges of the same size.

Some Com­mon Ras­ter Image File Types:  .jpeg, .gif, .png, .tiff, and .bmp.  Some Com­mon Vec­tor Image File Types:  .wmf, .svg, and .cgm.

An image should be crea­ted in every for­mat that is ac­cept­able to the users’ brow­sers, the ima­ges with un­ac­cept­able qua­li­ty should be dis­carded, and the smal­lest of the re­main­ing files should be used.

Image Size – Number of Pixels

When using ras­ter images (bitmaps), the file size can al­ways be re­duced by re­duc­ing the num­ber of pix­els used to re­pre­sent the image.  Wheth­er or not the small­er file con­tains enough in­for­ma­tion to ade­quate­ly re­pre­sent the image is an­other mat­ter.

1112×1664 = 511KB

To the left is an ex­am­ple.  This image is a .jpg scan of a 1969 pho­to­graph.  It is 1,112 pix­els wide by 1,664 pix­els high.  The file is 522,843 bytes in size, al­most half a me­ga­byte.

Sup­pose we want to put this image on a web page, but we want it to be 150 pix­els wide.  We can ac­com­plish this by in­clud­ing a width=”150″ at­tri­bute in the  <img> tag.  That is how it is por­trayed to the left.

150×224 = 13KB

The second image is the same pic­ture re­sam­pled to the exact re­so­lut­ion we want to dis­play, 150 pix­els wide by 224 pix­els high.  The size of this image is 13,269 bytes, 2½% of the size of the ori­gi­nal image.  The dis­played re­so­lu­tion of the first two pho­to­graphs is iden­ti­cal be­cause the web brow­ser re­sam­pled the first image down to 150×224 when it ren­dered it.

The main point of this dis­cus­sion is that all images should be re­sam­pled down to their ren­der­ing size pri­or to making the jour­ney from the ser­ver to the cli­ent.  Do­ing this does not af­fect the re­so­lu­tion, but can dra­ma­ti­cally af­fect the quan­tity of da­ta that makes the jour­ney.  In this ex­am­ple, we have eli­minat­ed 97½% of the da­ta, but the re­so­lu­tion is iden­ti­cal.

Note:  The two ima­ges are ren­dered with i­den­ti­cal re­so­lu­tions, but we may still no­tice slight dif­fe­ren­ces be­tween them.  These dif­feren­ces are a re­sult of the dif­feren­ces be­tween the in­ter­po­la­tion al­go­rithm used by the brow­ser vs. the li­ne­ar in­ter­po­la­tion al­go­rithm I se­lect­ed in The Gimp.  When pre­par­ing an image for pro­duc­tion, we should se­lect the in­ter­po­la­tion al­go­rithm we like best, but keep an eye on the re­sult­ing file size.

120×180 = 9KB

60×90 = 4KB

90×135 = 6KB

30×45 = 2KB

Can we car­ry this fur­ther?  Can we re­duce the image size even more?  This will af­fect the dis­played re­so­lu­tion, but per­haps the re­so­lu­tion will still be ac­cept­able to us.

The an­swer to this ques­tion is in the re­main­ing images.  Each image is dis­played with a width=”150″ at­tri­bute, so it is ex­act­ly the size we want.  How­ever, each image was re­sam­pled to a pro­gres­sive­ly smal­ler re­so­lu­tion so that the num­ber of bytes making the trip from the ser­ver to the cli­ent is pro­gres­sive­ly re­duced.

It is easy to see the re­duc­tion in re­so­lu­tion from one image to the next.  There is no ques­tion about whether or not the image qua­li­ty de­terio­rates.  The ques­tion, how­ever, is how much de­terio­ra­tion are we will­ing to ac­cept.

In this ex­am­ple, I am sure we would all agree that the 30×45 image at the bot­tom is to­tal­ly un­ac­cept­able.  It has de­stroyed this young man’s good looks com­plete­ly.  How­ever, we may de­cide that the 90×135 image is ac­cept­able for our pur­poses.  There is a re­duc­tion in image qua­li­ty, but per­haps we think of that re­duc­tion as tri­vi­al or ir­re­le­vant.

The size of the 90×135 image is 6,079 bytes, less than half the size of the image that was re­sam­pled to 150×224, and a mere 1.2% of the ori­gin­al image size.  By our de­ci­sion to allow a rea­son­able de­terio­ra­tion in re­so­lu­tion, we have fur­ther re­duced the amount of data tra­vel­ling from the ser­ver to the cli­ent by more than half.

Image Size – Size of Individual Pixels

Reducing the num­ber of pix­els in an image is not the only way to re­duce the size of the da­ta stream be­ing sent to the cli­ent.  Re­duc­ing the stor­age re­quire­ment of each in­di­vi­du­al pix­el can ac­com­plish the same thing.

If every pix­el were either on or off (black or white), we could store eight pix­els in each byte.  How­ever, black and white images are rare­ly used on web pages.  It is more com­mon to see grey­scale images, in which each pix­el is black or white or some­where in be­tween.  If we al­low 256 dif­fer­ent shades of grey, each byte can hold one pix­el.

Colour images are much, much more com­mon than grey­scale.  Full-colour pix­els (with trans­paren­cy) are ty­pi­cally stored in four bytes, one byte each for red, green, and blue, plus one byte to set the amount of trans­paren­cy.  At four bytes per pix­el, these image files can be­come quite large.

It is pos­s­ible to con­trol the num­ber of colours used, which al­lows us to con­trol the amount of stor­age space re­quired for each pix­el.  For ex­am­ple, we could pack two pix­els in each byte if we were will­ing to live with only 16 colours or we could use two bytes for each pix­el if we want­ed 65,536 colours.

The num­ber of colours we use in an image is called its colour depth.  The great­er the colour depth of an image, the great­er the num­ber of bytes that have to make the jour­ney from the ser­ver to the cli­ent.

If we want to re­duce the size of the da­ta stream be­ing sent from the ser­ver to the cli­ent, we can set the colour depth low­er.  How­ev­er, we must con­sid­er what this does to the qua­li­ty of the image.  For ex­am­ple, each of the fol­low­ing images has half the colour depth of the image that pre­cedes it:

In this ex­am­ple, if we were will­ing to ac­cept the third image (64 colours) in­stead of the first image (256 colours), we could re­duce the file size from 22,845 bytes to 12,936 bytes, which would re­duce the num­ber of bytes jour­ney­ing from the ser­ver to the cli­ent by al­most half.

With most por­trait pho­to­graphs, as with this ex­am­ple, image qua­li­ty de­terio­rates ra­pid­ly as colour depth de­crea­ses.  The same is usu­al­ly not true of draw­ings.  It is pos­s­i­ble for a re­duc­tion in colour depth to cause a dra­ma­tic re­duc­tion in file size with­out sig­ni­fi­cant­ly af­fect­ing image qua­li­ty.

Compression

Dif­fe­rent image types use dif­fe­rent le­vels of com­pres­s­ion.  For some types, we are asked how much com­pres­s­ion we want.  If we se­lect the max­i­mum amount of com­pres­s­ion, our file size will be smal­l­er; if we select the mi­ni­mum amount of com­pres­s­ion, our file size will be big­ger.

How­ever, some types of com­pres­sion are los­sy and some are loss­less.  Loss­less com­pres­s­ion can be re­versed to re­cre­ate the ori­gi­n­al image; los­sy com­pres­s­ion re­sults in a per­ma­n­ent de­terio­ra­tion of image qua­li­ty.  In ge­ne­ral, when pro­duc­ing images, we set the com­pres­s­ion as high as pos­si­ble with­out re­du­c­ing the image qua­li­ty be­low what we con­si­d­er ac­cep­t­a­ble.

Most web ser­vers al­low us to com­press com­po­nents on-the-fly be­fore they are sent to the cli­ent.  We should not use this fea­ture for images.  In­stead, we com­press the images be­fore trans­fer­ring them to pro­duc­tion.  The web ser­ver can then send them as-is in­stead of in­cur­ring the ad­di­tion­al cost of com­pres­sing them over and over again at a time when it will af­fect per­for­m­ance.

Combine Images

If a sta­tic image over­laps an­oth­er sta­tic image, the ob­scured por­tion is be­ing down­load­ed even though it is never dis­played.  This ex­tra down­load­ing takes time.  The more we do it, the worse the per­for­m­ance.  To avoid this prob­lem, com­bine over­lap­ping images into a single image pri­or to trans­fer­ring it to pro­duc­tion.

Sprites al­low us to com­bine mul­ti­ple ima­ges into one, and dis­play the small ima­ges that are real­ly part of the big­ger ima­ges.  This re­duc­es the num­ber of con­nec­tions, which com­pletes the down­load pro­cess fast­er.  Sprites are not ful­ly sup­port­ed by all brow­sers yet.  They are be­com­ing in­creas­ing­ly popu­lar, though, so keep them in mind for the not-too-distant future.

Favicon.ico

Most brow­sers re­quest favicon.ico from the doc­root whether we like it or not.  Make sure it’s small – 16×16 with a small colour pa­l­ette works well in ma­ny cases.

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.

The Impact of Image Optimization.  Published 2011.06.07 by Blaze at www.blaze.io/technical/the-impact-of-image-optimization  Accessed 2011.12.26

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

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.

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