Drupal performance optimization means layering page cache, Views cache, database relief, and CDN delivery so pages render fast for both anonymous and logged-in visitors. Cache speeds repeat page delivery, Views cache cuts repeated queries, database tuning removes write load, and a CDN serves cached bytes near the reader. In Drupal, a cache stores finished work so the site reuses it. A cache context marks how a page fragment varies, such as by user role or URL.
Table of Contents
- What do the core page caches cover?
- How do you set Views caching without stale lists?
- How do you cut database load?
- Where do Varnish and a CDN fit?
What do the core page caches cover?
Start with Internal Page Cache for anonymous traffic. Drupal.org docs explain in the Internal Page Cache guide that it stores full rendered pages and is enabled by default. It suits small to medium sites, but disable it when anonymous output is personalized, such as shopping carts.
The Drupal.org User Guide describes Dynamic Page Cache as coverage for authenticated users. It caches reusable page fragments that vary by cache context. BigPipe handles the remaining personalized placeholders, so the cacheable shell appears first and slow parts fill in after.
How do you set Views caching without stale lists?
Views caching is off by default, so listings rebuild on every view until you set it. Pantheon Docs notes that caching is set per display under Advanced > Caching.
You can set separate lifetimes for raw query results and rendered markup, plus block caching for block displays. Use this practical order: Pantheon docs recommend in the Views caching guide that raw results stay cached for at least one minute while rendered output uses the longest safe lifetime, because new query results automatically refresh the output.
- Cache raw query results for at least one minute to reduce database queries.
- Cache rendered output for as long as possible for listings that change rarely.
- Check one edit cycle to confirm new results refresh the display.
How do you cut database load?
Move logging off the main database on busy sites. Acquia directs high-traffic sites in the Cloud Platform performance guide to enable core Syslog and disable Database Logging. Database Logging writes events to the main database, so every page event adds write pressure during production traffic.
Acquia also lists layered caching as Drupal cache, Varnish, Memcache or Redis object cache, PHP opcode cache, and CDN. Turn on CSS and JavaScript aggregation to reduce requests. Offload core search where possible to avoid stressing MySQL with heavy queries.
Where do Varnish and a CDN fit?
Varnish acts as a caching reverse proxy in front of Drupal. The Drupal.org Cache API guide describes cache tags sent in response headers, which let Purge and Purger modules BAN only changed pages. Sites must enable Drupal reverse-proxy settings for addresses and headers to work correctly.
Place a CDN outside Varnish for static files and repeat anonymous page hits. Keep Drupal cache tags accurate so an edit clears only related pages, not the whole site. Enable reverse-proxy settings, publish a test edit, and confirm only tagged pages purge.
