Drupal uses PHP to build web pages that are returned to a user's browser. Most of the time, these pages are unchanged between requests, and Drupal is working to build the same page before sending it off to the various users who requested it. IT makes sense then to tell Drupal that if it has created a web page once, it should store a copy of this page and serve that copy instead of going to the trouble of recreating it.

The trade-off when using page caching is that any changes to a page are only shown to users once that cached version has expired and been replaced. This makes caching a suitable method for boosting performance whenever content is not updated very often, or when it is not important to have new content presented immediately.

Caching can have effects on , or be affected by , other modules. Most notably, the Throttle module, which I will discuss at a later date, cannot be used in conjunction with aggressive caching. In the event that caching is desirable for most, but not all, pages then it is worth checking out the Cache Exclude module that can disable page caching for certain, specified pages.

Agressive caching is not really necessary in the vast majority of cases and can cause problems with a variety of modules because it skips their boot and exit functions ( which is how it provides that extra performance boost). Enabling it may well lead to some ugly warnings to this effect from Drupal.

Block caching can offer performance benefits for authenticated users because page caching is only ever enabled for anonymous users. The reason for this is that authenticated users have a lot of customised content that needs to be displayed - along with any changes or posts- without having to wait 6 hours at a time.