Case study

I used this design, each light is of two PNG images, the big one is made of four PNG images.

  • 4 times 15430 bytes of PNG data (61720 bytes ~= 61K)
  • 2 times 5 times 6101 bytes of PNG data for the small light (~= 61K) (Tot: 122730 ~= 122K)
  • 10 + 4 = 14 http connections (slower if https! a lot!)
for these two graphics:

This can be replaced with under a dozen or two lines of html5 and roughly 150 lines of css3(which can probably be reduced); this works in every phone and modern browser I can find. Thus, instead of the above network transit to retrieve graphics from a server, we just draw the buttons. The cost of this is some code sent either as it's own css file or inline, and a tiny amount of HTML.

Thus the savings are:

http:/https connections140
bytes network traffic122K~5K
page load timeuneven due to imagesinstant

These aren't the only lights in the program, there are at least 3X to 4X times as many as this. With 40 lights that's 4 times 122K or 488K - nearly half a meg of traffic. With CSS, once the overhead is paid with a ~5K CSS file, the incremental cost of a new button is strictly limited to the dozen or two bytes of HTML code.

The more you use it the more you save and the break even point for the overhead is less that one set of these lights. This works on all HTML5 platforms, whether mobile, tablet or computer. Is it worth doing for one light? Probably if you don't ever want to see a broken gif icon again. For more than one the incremental cost of setting up expensive https connections and performing network traffic to make a disk drive physically move an arm in some far off country seems ridiculous when we can now just draw the image instead.

The page load time is the most dramatic thing. In a age where bloated paged can be slow to load, use these and page load times are perceived to be instant. This is especially advantageous to apps.