Caching Strategies That Accelerate Every Request
Without thoughtful caching, your server recomputes every page from scratch — even if the same request was made ten seconds ago. We implement multi-tier caching architectures that make browsers, servers and CDNs work together intelligently, permanently reducing response times to under 100 milliseconds.
95%
cache hit rate in optimized projects (project experience)
80%
less server load after full caching implementation (project experience)
< 2.5s
target LCP
50+
optimized projects with caching implementation
Caching is the single most effective lever for reducing server response times. While server optimizations such as database tuning and PHP-FPM configuration reduce the processing time of each request, caching reduces the number of requests that actually need to be processed. A correctly configured browser cache prevents assets from being loaded from the server again. A reverse proxy cache answers identical requests from memory. A CDN edge cache delivers content from the closest server. The interplay of these layers determines whether your website remains stable under load or buckles under pressure. We analyze your current caching configuration as part of our technical performance analysis and implement a strategy that addresses all levels.
The Four Tiers of Modern Caching Architectures
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 Cache
The browser stores static assets locally on the user's device. On repeat visits, CSS, JavaScript, images and fonts are loaded directly from the local cache — without any network request. Correctly configured, the browser cache eliminates up to 90 percent of all requests on repeat visits (project experience).
Application Cache
The application cache stores computed values, database query results and fragment HTML in memory — typically in Redis or Memcached. Instead of executing the same SQL query multiple times, the application returns the cached result in under one millisecond.
Reverse Proxy Cache
A reverse proxy such as Varnish or nginx cache stores fully rendered HTML pages. Requests from anonymous visitors are answered directly from the proxy without PHP, the database or application logic being involved at all. This dramatically relieves the server during traffic spikes.
CDN Edge Cache
A content delivery network distributes cached content across edge servers worldwide. Users receive resources from the geographically closest node — for German audiences typically from Frankfurt or Amsterdam with under 20 milliseconds latency, rather than from a single origin server.
Getting started with cache optimization
- Analysis of browser, server, proxy and CDN cache
- Concrete top measures with an effort-to-impact rating
- Ongoing cache monitoring optional from €59 per month net
The Performance Quick Check reviews your caching configuration across all tiers and delivers a prioritized action plan. Every engagement starts with a free initial assessment — with no obligation.
Browser Caching: Eliminating Network Requests
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.
Cache-Control Headers
We configure differentiated Cache-Control directives: max-age for maximum cache time, stale-while-revalidate for seamless background updates and no-store for sensitive, user-specific content such as shopping carts or account views.
Content Hashing
Build tools generate a hash for each file based on its contents. When a file changes, its hash changes — and the browser loads the new version. Unchanged files are served from cache, which accelerates deployment cycles and reduces user data consumption.
Conditional Requests
ETag and Last-Modified headers enable conditional requests. The browser asks the server whether a resource has changed since the last retrieval. If it has not, the server replies with HTTP 304 (Not Modified) without a file transfer — saving bandwidth and reducing perceived load time.
Server-Side Caching: Redis, Memcached and OPcache
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).
opcache.memory_consumption is set to the size of your application code plus 20 percent headroom, and opcache.max_accelerated_files to at least twice the actual number of PHP files. We disable timestamp validation (opcache.validate_timestamps) in production and clear the cache only deliberately during deployments.allkeys-lru) that automatically remove the least recently used entries when memory is scarce.Caching and TTFB: Two Sides of the Same Coin
Reverse Proxy Caching with Varnish and nginx
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.
How a Reverse Proxy Cache Distributes Requests
Cache Hits vs. Cache Misses
On a cache hit, the proxy delivers the stored response in 2 to 5 milliseconds directly from memory. On a cache miss — e.g. the first call to a page or after invalidation — the proxy forwards the request to the application, stores the response and simultaneously delivers it to the user. All subsequent requests for the same URL are served from cache again. The cache hit rate determines how much load the application server actually has to bear.
- Cache hit: 2–5 ms response time directly from in-memory storage
- Cache miss: request is computed once by the application and then cached
- Grace mode: delivery of stale content while background revalidation runs
- Health check: automatic failover on backend issues
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.
How fast does your server respond today?
We check your caching configuration across all four tiers — browser, server, reverse proxy and CDN — and show which layer is going unused. The initial assessment is free and non-binding.
CDN Caching: Global Delivery at Local Speed
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).
Static Asset Caching
CSS, JavaScript, images and fonts are cached at the edge and served directly to nearby users. Content-hash-based cache busting enables cache lifetimes of one year without deployment issues. The origin server is fully relieved of asset requests.
Dynamic Edge Caching
HTML pages can also be cached at the edge when the invalidation strategy is right. Cache tags and surrogate keys enable targeted invalidation of individual pages on content changes without clearing the entire edge cache. This combines caching efficiency with current content.
DDoS Protection and Load Distribution
A CDN absorbs traffic spikes and DDoS attacks at the edge before they reach the origin server. Volumetric attacks are buffered by the distributed infrastructure. At the same time, rate limiting at the edge prevents bot traffic from poisoning the cache.
Cache Invalidation: Staying Current with Long Cache Times
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.
Time-Based Invalidation (TTL)
Time-to-live values specify after how long a cache entry expires automatically. For static assets, we set TTLs of one year in combination with content hashing. For semi-dynamic pages such as category listings, we choose TTLs of 10 to 60 minutes. For real-time data such as product availability or pricing, we set no TTL or very short ones. Choosing the right TTL means balancing cache hit rate against data freshness.
Event-Based Invalidation
When a product is updated, an article published or a price changed, the cache should be updated immediately — regardless of the TTL. Event-based invalidation couples cache purging to database changes or webhook events. We implement invalidation hooks in CMS and shop systems that selectively remove affected cache entries on every content change.
Tag-Based Invalidation
Tag-based invalidation groups cache entries by content category. A product page might receive the tags product-42 and category-electronics. When product 42 changes, all entries tagged product-42 are invalidated — the product page, the category listing and any search results containing the product. This minimizes invalidation overhead while ensuring no stale pages are served.
Cache Warming After Invalidation
After a mass invalidation — e.g. after a deployment or a large data import — the cache is initially empty and all requests hit the slow application (cold-start problem). We implement cache warmer scripts that proactively request the most-visited pages after invalidation and load them into the cache, so users never experience a performance dip after deployments.
Stale-While-Revalidate
The stale-while-revalidate directive allows the browser or cache to serve a stale entry for a defined period while the updated version loads in the background. Users never see a loading spinner because a version is always available. The new version is already ready for the next request. This pattern combines maximum cache hit rate with seamlessly updated content.
Caching for CMS and Shop Platforms
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.
WordPress
Redis object cache for database queries, full-page cache for anonymous visitors, fragment cache for widgets and sidebar elements. Correct invalidation on post updates and plugin actions. We cover the details on the WordPress performance page.
Shopware CE
HTTP cache for all product listing pages, product detail pages and CMS pages. Redis as session store and application cache. Correct invalidation via the Shopware event bus on product, price and stock changes for optimal shop performance.
TYPO3, Drupal, Contao
TYPO3 caching framework with Redis backend, tag-based invalidation via page-tree cache tags. Drupal dynamic page cache and cache API. Contao page cache with configurable exceptions for interactive elements. System-specific configuration for maximum cache hit rate.
Caching Alone Is Not Enough
Typical caching projects from our practice
Illustrative examples from typical project histories (project experience) — anonymized.
Measuring and Monitoring Caching
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. Our articles on caching with Varnish and Redis and CDN and edge caching explain how the individual layers interact.
- Cache hit rate: the share of requests answered from cache — target above 85 percent for the reverse proxy cache
- TTFB differentiation: separate measurement of TTFB for cache hits (target under 20 ms) and cache misses (benchmark for raw server performance)
- Cache size and eviction rate: monitoring of used cache memory; high eviction rates indicate that the cache is too small for the working dataset
- Invalidation frequency: excessive invalidations can lower the cache hit rate — a sign of suboptimal TTL values or overly aggressive invalidation logic
- Detecting cache poisoning: anomalies in cached content caused by incorrect Vary headers or misconfigured cache key settings
Typical Caching Configuration: Step by Step
Analysis of the Current Cache Situation
Measuring current cache hit rates at all levels using HTTP header analysis, Redis statistics and server monitoring. Identifying resources that should be cached but are not, and resources that are incorrectly cached (e.g. user-specific pages). The findings feed into our performance analysis.
Configuring Browser Cache Headers
Configuring Cache-Control headers in the web server and CMS. Implementing content hashing in the build process for long-term browser caching without deployment issues. Correct Vary headers for content that differs by Accept-Language or Accept-Encoding.
Setting Up Server-Side Caching
Installing and configuring Redis or Memcached as an application cache. Adjusting OPcache parameters to the actual code size. Implementing application-level caching logic for frequent database queries. Defining TTL values per data entity.
Configuring the Reverse Proxy
Setting up Varnish or nginx proxy cache, configuring cache key logic, implementing cookie handling for anonymous versus logged-in users. Connecting the invalidation mechanism to the application. Implementing cache warmers for the most important pages.
CDN Configuration and Monitoring
CDN integration for static assets, edge caching for suitable HTML pages, cache tag management for targeted invalidation. Setting up a monitoring dashboard for cache hit rate, TTFB and invalidation frequency. Defining performance budgets for cache metrics.
Key takeaways
- Four coordinated cache tiers — browser, application (Redis), reverse proxy and CDN — intercept every request as early as possible
- In optimized projects up to 95 % (project experience) of all requests are answered from cache, and server load drops by up to 80 % (project experience)
- Cache hits are served from memory in under 3 ms (project experience) instead of roughly 800 ms of recomputation
- Cache invalidation by time, event and tag keeps content current despite long cache times
- Get started with the Performance Quick Check from €349 net, ongoing cache monitoring optional from €59 per month net — after a free initial assessment
Frequently Asked Questions About Caching Strategies
max-age=31536000) with the immutable flag. Content hashing ensures that changed files receive a new URL fingerprint and the browser automatically loads the new version — regardless of how long the old version is cached. Without content hashing, we recommend shorter cache times of one to seven days.Cache-Control: private header prevents shared caches (CDN, reverse proxy) from storing user-specific content. For logged-in users, caching is applied at the application level (Redis with a user-specific cache key) rather than at the HTTP level.