Drupal Caching: Performance Optimization in Practice

Drupal benefits from multiple caching methods operating at different levels:

PHP OpCode Cache. PHP is a scripting language that is interpreted before each execution. An OpCode cache stores the result of this processing. Since PHP 5.5, the Zend OPcache is included in the core. This cache is mandatory for any Drupal installation.

Database Cache. The default method in Drupal: rendered pages, menu structures, field configurations, and more are stored in cache tables in the database. Drupal core includes over 10 such tables.

In-Memory Cache (Redis, Memcached). Data is held in RAM instead of the database. This is significantly faster. Redis is the preferred partner for Drupal — stable, persistent, and well supported.

Reverse Proxy (Varnish). A reverse proxy sits in front of the web server and serves cached pages without Drupal even starting. For high-traffic sites, Varnish is the biggest performance lever.

CDN (Content Delivery Network). Static files like images, CSS, and JavaScript are served via distributed servers. This reduces load on the web server and improves load times for international users.

Drupal offers two central cache mechanisms configured via the backend:

The page cache stores fully rendered pages for anonymous users. The number of database queries drops dramatically, and response time improves measurably. The page cache is automatically invalidated on content changes — for pages with frequent edits, an expiration time can be useful.

The block cache stores rendered blocks independently of the page cache. Blocks can be context-dependent — their content varies by page or user role. Drupal caches blocks per user role by default.

Cache tags in Drupal 11. The modern cache system works with tags instead of time-based expiration. When content changes, all cache entries with the corresponding tag are invalidated. This is more precise and efficient than blanket cache clearing.

Disabling cache completely. Drupal's cache cannot be fully disabled — theme registry and menu structures always remain cached. Disabling the page cache loses the biggest performance gain.

Running cron too frequently. Cron clears temporary cache entries. If cron runs too often, the cache is constantly cleared and must be rebuilt. That costs performance instead of gaining it.

Wrong cache method for the use case. Large files do not belong in a database cache. Highly dynamic content (e.g., personalized dashboards) benefits little from the page cache. The art lies in the right combination.

At arocom, we analyze the requirements of each project and configure a caching strategy that makes a real difference — measurable, not just perceived.

Let us analyze where the bottlenecks are together. The Future Check uncovers performance issues and delivers concrete recommendations. Or write to us directly — our team responds within 4 business hours on weekdays.