1.2.2 Unnecessary re-creation of page data
When analyzing a Web site, we will generally find pages that rarely change. Often only a small part of the page may change. Caching pages or page fragments that change on an infrequent basis improves performance significantly.
The process of identifying the cacheable fragments and developing the correct strategy will be one of the mandatory activities during your caching analysis phase.
Figure | -2 shows an example Java Server Page (JSP™) made up of several fragments.
Figure 1-2 An example parent JSP with its child JSPs fragments
We could analyze each of the individual JSPs and assess their cacheability based on:
| What each child JSP fragment actually does |
|
| How often the fragment changes |
|
| The cost of generating each fragment |
|
| Reducing the number of queries executed on the database server even if this does not reduce response times directly |
Characteristically, the header, menu, and footer JSPs rarely change in most applications and therefore are ideal for caching.
Your analysis of the catalog and marketing page in Figure | -2 should involve assessing the volatility and processing overhead required to create the data for those components. However, before dismissing these fragments as uncacheable, you should still check whether there are subcomponents within them that could be cached, such as inventory numbers displayed by the catalog.jsp or marketing information targeting specific groups in the marketing.jsp.
It may be possible to reduce the volatility of data on a page without significantly reducing the effectiveness of the page. For example, rather than displaying how may items are in stock, just display whether the item is in stock or not.
Although inventory list items change over time, they may change infrequently enough that they warrant consideration for caching. If you keep recreating parts of pages that do not change you are wasting valuable system resources.