When your web architecture evolves to the point where it serves up applications where the data and the user interface are separate components, you will have achieved the best solution regarding bandwidth, generally, and energy consumption within the server farm.
Today’s solution(s) present the user interface completely integrated with the data. This is the reason we must satisfy ourselves with the “World Wide Wait”. Each time we want to view some associated information, we must click again, and wait, until the web and the server regenerate this (user interface) new view. When you consider that most web sites web pages are deployed using panels (or windows), containing “views” from other sites, any breakdown at any server slows down your web page.
In order to minimize this effect on our web pages, we migrated to using the HTML <FRAME> element, which was very handy at the time, but is not supported by the W3C specification anymore. In addition, future support for the <FRAME> element is not guaranteed, eventually forcing developers to find a better way to achieve better results. As a side-note, sites deploying frames as part of the user-interface are inadvertantly shunning those customers (or users) who may be blind or have other disabilities. Most, if not all Government agencies, both Federal and State, have laws in place that ensure that government web-sites comply with those development techniques that support the use of divergent browser viewers.
By far, however, the most rationale reason for deploying “low-bandwith” solutions is to minimize your cost. If you are planning a ‘cloud computing’ architecture, you need to read this article.
(work in progress)