Caching Strategies That Accelerate Every Request

Effective caching does not happen at a single level but as a coordinated interplay of multiple layers. Each layer has its own strength: the browser cache eliminates unnecessary network requests; the application cache stores the results of expensive database queries; the reverse proxy cache intercepts fully rendered pages before the application is contacted at all; and the CDN reduces the physical distance between server and user to a minimum. We implement all four layers in a coordinated fashion so that each request is intercepted as early as possible.

Browser caching is controlled via HTTP response headers that the server sends with every reply. These headers tell the browser how long a resource may be cached and under what conditions it must be revalidated. The most important headers are Cache-Control, ETag and Last-Modified. A common problem is the absence of these headers for static assets: without caching directives, the browser either stores assets not at all or for very short periods, leading to unnecessary network requests on every repeat visit.

For static assets — CSS, JavaScript, images, fonts — we set Cache-Control: public, max-age=31536000, immutable. This corresponds to one year of cache time, which the immutable directive marks as unchanging. Browsers do not need to revalidate the resource on page refreshes, further reducing load times for repeat visits. To prevent these long cache lifetimes from causing deployment problems, we implement content hashing: every changed file receives a new fingerprint in its filename (e.g. app.a3f9c2.js). This automatically invalidates the browser cache without requiring manual purging — a technique known as cache busting.

At the server level, we distinguish between three types of caches: the PHP OPcache, which holds compiled PHP bytecode in shared memory; the application cache for database query results and computed values; and the fragment cache for individual HTML blocks. All three work in a complementary fashion and address different bottlenecks in request processing. In practice, combining these layers reduces PHP execution time per request by 50 to 80 percent (project experience).

A reverse proxy is the most effective measure against high server load. Varnish and nginx store fully rendered HTTP responses in memory and serve identical subsequent requests in under 5 milliseconds — without PHP, the database or application logic being contacted at all. In projects with a well-configured reverse proxy cache, the proxy answers over 90 percent of all requests directly from cache (project experience). In concrete terms: nine out of ten page views cost the application server not a single CPU cycle.

The biggest challenge with reverse proxy caching is the correct handling of cookies and personalized content. By default, Varnish and nginx do not cache requests containing cookies — because cookies indicate personalized content. This is correct for logged-in users but wrong for anonymous visitors with cookie-banner or analytics cookies. We configure the cache bypass logic so that genuine personalization cookies (session ID, shopping cart) bypass the cache, while harmless tracking cookies are ignored and the cache remains active. This achieves high cache hit rates even for websites with cookie consent banners.

A content delivery network complements server-side caching with a geographically distributed delivery layer. Instead of routing all requests to a single origin server, cached content is served from edge servers close to the user. For websites with primarily German audiences, these are edge nodes in Frankfurt, Amsterdam and Paris with response times under 20 milliseconds. For international projects, a CDN reduces load times for visitors from North America or Asia by 200 to 400 milliseconds (project experience).

Cache invalidation — the timely discarding of stale entries — is the most technically demanding component of any caching strategy. Cache times that are too short waste the performance gain; cache times that are too long result in users seeing outdated content. We implement invalidation strategies that combine high cache hit rates with current content, distinguishing between three fundamental approaches.

Every platform brings its own caching layers, configuration parameters and invalidation specifics. Generic caching configurations do not fit all systems. We know the platform-specific nuances for all common platforms and implement tailored caching strategies that exploit the full potential of each.

Caching is not a "set it and forget it" topic. New features, content structure changes and traffic patterns can degrade cache efficiency over time. We set up monitoring that permanently tracks the cache hit rate, TTFB for cache hits and cache misses, and invalidation frequency. Critical deviations trigger automatic alerts. All metrics are optimized on the basis of current usage patterns as part of a regular performance audit.