A few years ago, I was visiting a customer with a performance problem. I listened to their technitions describe their issues and the symptoms and their plan to address the issue. They assumed the correct plan was to buy more equipment (in fact $1M worth) to solve the problem for a large number of remote users. After a discussion of the symptoms, I suggested that maybe they should look at the caching parameters in the product to reduce the network footprint of the product.
The symptom they saw was that the majority of traffic between the product and users was graphics (jpg and gif). This is unusual as the Oracle Utilities Application Framework products all cache their graphics on the client machine via the browser. Each network resource such as graphics and static HTML based pages are cached by the browser the first time they are requested and when they expire. When a page is served to a user for the first time, the product generates an expiry date and time, based upon a configuration parameter, that is stored on the client machine in the browser cache. When the user goes back to the page, the browser serves it from the cache not the server, unless it has expired where it gets a new version of the page and/or graphics.
By the way, you can find out how much bandwidth is used by the graphics by using a reporting tool against the access.log as it reports the usage of all elements of a page. Refer to the Performance TroubleShooting Guides - Web Application Server whitepaper (DocId: 560382.1 from My Oracle Support) for a description of this log and the various tools available to analyze it.
The idea is that the graphics and pages can be served from the cache and save bandwidth. Ideally one should find the amount of bandwidth used by these elements to be a lower proportion over time to data. In real life, only data should be transmitted regularly to the client rather than graphics or page layouts.
When we do see this higher bandwidth used by these static elements, it means one of two things, either the parameter that controls the caching is set too low (it is set to 8 hours by default - a value most customers use) or the browser is not configured to take advantage of the expiry date so ignores it.
In the case of this customer, it was the latter. The implementor had set the browser cache to refresh the cache "Every time I visit the page" which ignores the cache setting and this setting is typically used by developers who are not interested in caching data during their development. The correct value was "Automatically". This sets the caching to adhere to the expiry date and reduce bandwidth.
The customer set this value to "Automatically" at their site and experienced a substantial performance boost and a reduction in bandwidth usage across the user base.