Caching levels in hosting: opcode, object, page & CDN caching explained

Caching levels in hosting accelerate PHP execution, database access and the delivery of complete pages through to global provision via edge servers. I will show you how opcode, object, page and CDN caches work together, where they come into play and which settings have the greatest effect.

Key points

• Opcode Cache pre-compiles PHP and reduces the load on CPUs for each request.
• Object Cache keeps frequent database results in RAM and saves queries.
• Page Cache delivers finished HTML to visitors in milliseconds.
• CDN Cache distributes content to edge servers worldwide and reduces latencies.
• Interaction of all levels eliminates bottlenecks from backend to edge.

What caching layers do

I use four Levelsto reduce loading times and server load: opcode, object, page and CDN. Each level addresses a different bottleneck and works on its own level of the infrastructure. In this way, I save CPU time when executing code, reduce database queries, deliver HTML directly and bring content geographically closer to the user. I prioritize the biggest bottleneck first and gradually add to the remaining caches. This clear Sequence makes optimization measurable and stable.

Opcode Cache: Execute PHP immediately

The opcode cache stores precompiled PHP opcodes in the RAMso that the interpreter does not work again with every request. I activate OPcache with sensible limits for memory, file cache and revalidation so that hot code paths are permanently available. CMS pages in particular benefit because recurring calls no longer trigger compilation. This noticeably reduces the CPU load and the response time of the web server. I regularly check the OPcache statistics to check the Cache hit rate high.

Object cache: Relieve database

The object cache stores frequent results from Queries in memory, for example menus, product lists or user rights. I use in-memory services such as Redis or Memcached for this and allocate meaningful TTLs for volatile data. This allows me to significantly reduce round trips to the database, which remains stable, especially with heavy traffic. In WordPress, I combine persistent object caching with targeted exclusions so that personalized content is not distorted. If you want to get started, you can find a compact guide in my article on Redis for WordPress. I observe the Miss rateto readjust keys with too short a service life.

Page Cache: Deliver HTML

The page cache creates complete HTML-pages that the system has generated dynamically. I define clear rules: anonymous visitors receive static copies, logged-in users bypass the cache. During updates, I specifically clear affected pages so that content remains up-to-date. This pays off, especially during traffic peaks, because I reduce the backend load to virtually zero. A practical sequence of steps is shown in my Website caching guide. I regularly check Time-To-First-Byte to ensure the Effect to verify.

CDN cache: globally fast

A CDN brings content to Edge-server close to the user, thus reducing latency. I cache assets such as images, CSS and JS and, if required, complete pages via full-page caching. Rules for cookies, headers and query parameters prevent incorrect delivery of personalized content. For international target groups, I noticeably shorten loading times and reduce the load on my origin server. If you want to read more about the setup, click on my overview of the CDN optimization. I have purge mechanisms ready to ensure that when releases are made, fresh Versions to be delivered.

Comparison of the caching levels

The following table classifies Use and effect so that I address the right level first.

Level	Storage location	Typical application	Main advantages
Opcode cache	Server (RAM)	PHP-based websites, CMS	Faster execution, less CPU
Object cache	Server (RAM)	Frequent DB queries in shops/CMS	Fewer queries, short response times
Page Cache	Server and/or CDN	Anonymous page views	Very short TTFB, load reduction
CDN Cache	Edge server	Global delivery of pages/assets	Low latency, high scalability

I set the levels in this Sequence first opcode, then object, then page and finally CDN. This way I avoid duplicating work and get the most noticeable effects first.

Interaction of the levels

In my process, the Opcode Cache first PHP without recompilation. The object cache delivers frequent data from RAM, leaving the database free. The page cache serves recurring pages directly and saves PHP and DB layers. A CDN provides content close to the user worldwide and intercepts traffic peaks. This chain reduces any waiting time because I specifically make each stage faster and reduce dependencies. I keep this Path transparent so that debugging remains easy.

TTL, purge and cache validation

I consciously forgive TTLs for each level so that content is neither too old nor too short-lived. For releases, I use purge by path, tag or key to purge specifically instead of deleting everything. Edge caches respect control signals such as cache control, surrogate control or ETag. For personalized content, I use Vary headers or cookie rules to prevent cache mixing. I test invalidation in staging systems before placing larger campaigns. This keeps content consistenteven if I combine many levels.

Measurement: Hit rate and misses

I measure the Hit rate separately for each level so that cause and effect remain clear. For OPcache, I check memory allocation, revalidations and compilations. For the object cache, I observe misses per key and adjust TTLs. For the page cache, I correlate HIT/MISS with TTFB to see the effect on users. In the CDN, I monitor regional latencies and edge hit rates to ensure that all sites perform reliably. These key figures control my next Optimizations.

Edge cases: dynamic content

I cache login pages, shopping baskets or personalized dashboards a lot careful. I work with exceptions, no-cache headers, short TTLs or Edge Side Includes (ESI) for sub-areas. Search parameters or session cookies can generate variants that I deliberately limit. APIs also benefit from caching, but require exact invalidation for releases. For highly volatile content, I use object cache rather than page cache. So answers remain correctwithout losing speed.

Configuration by hosting type

In shared hosting I activate OPcache and use a persistent object cache, if available. In VPS or dedicated environments, I provide Redis/Memcached, isolate resources and set up monitoring. For page cache, I choose server-side solutions or integrated modules of the stack. I also activate a CDN if target groups are distributed or peaks are pending. I document all cache rules so that team members can roll out changes safely. Uniform Standards prevent misconfigurations.

Security and caching

I combine CDN-caching with protection mechanisms such as rate limiting and WAF rules. This buffers load peaks and keeps malicious patterns away before they reach the origin. TLS termination at the edge reduces latency and relieves the load on the host systems. I never cache sensitive content, for example admin areas or personal data. I check logs regularly so that cache bypasses and purges remain traceable. Security and Speed are not mutually exclusive if the rules are clear.

HTTP header in detail: precise control

Clean headers determine how reliably caches work. I use Cache control as the primary signal and combine it depending on the level: public, max-age for browsers/proxies and s-maxage for shared caches. stale-while-revalidate allows you to briefly deliver outdated content while it is updated in the background. With stale-if-error I keep the site online, even if the source is temporarily unavailable. ETag and Last-Modified help with conditional queries; I use them specifically when content needs to be frequently revalidated instead of completely retransmitted. Vary I limit them to really necessary dimensions (e.g. cookie for logged-in users, accept encoding for compression) so that there is no uncontrollable explosion of variants. For edge caches I use Surrogate controlto control CDN-specific TTLs without affecting browser caching.

Cache warming and preloading

To avoid cold starts, I warm up caches proactive on: After a deployment, I have important routes, category pages and landing pages automatically rendered and placed in the page and CDN cache. I prioritize according to traffic, sales relevance and depth of navigation. Sitemaps, internal link graphs or logs from the last few days serve as a source. Preloading is throttled so that the source is not overloaded. For object caches, I prefill expensive aggregations or authorization structures so that the first wave of users after a release receives consistently fast responses.

Versioning and cache busting

I provide static assets with Content hash in the file name (e.g. app.abc123.css). This allows me to set very long TTLs without the risk of stale. On release, only the URL changes, caches keep old versions until they expire. For HTML or API responses, I work with Cache tags or structured keys that allow targeted purging (e.g. all pages of a product). Where tagging is not possible, I plan purges by path and ensure sufficient headroom in the cache so that new objects can be placed immediately. Important: no unnecessary no-store on assets, otherwise I give away global performance gains.

Avoid cache stampede

If a frequently used key falls out of the cache, there is a risk of a Thundering stove-situation. I prevent this with Request coalescingOnly the first miss is allowed to calculate, all others wait for its result. In object caches, I set locks with a short TTL to prevent duplicate work. I also use Early RefreshIf a key is about to expire, it is renewed by a few background processes, while users still receive the old, valid version. I use jitter (random offset) to distribute processes so that thousands of keys do not expire at the same time. At API level, idempotency helps to enable repetitions without side effects.

Personalization, A/B tests and variants

Where personalization is unavoidable, I limit it. minimal off. Instead of varying the whole page, I render small, non-cacheable fragments (ESI) or reload them on the client side. With A/B tests I avoid cookie-based variants for all assets; otherwise everything ends up in the browser's private cache and shared caches become useless. Instead, I only encapsulate the relevant part of the page or work with server-side playout that does not break up the page cache. For currency or language selection, I define unique paths (e.g. /de/, /en/) instead of Accept-Language so that caches receive deterministic keys.

Compression, formats and Vary

Gzip or Breadstick reduce the transfer size, but also influence cache keys: I keep Vary: Accept encoding lean and ensure that edge caches are allowed to save pre-compressed variants. I optimize images with modern formats (WebP, AVIF) and device-compatible sizes. I take care not to set any unnecessary vars on user agents in order to avoid a flood of variants. A few, clearly defined breakpoints or responsive image attributes that can be cached cleanly are better. For critical CSS/JS bundles, I use long caching plus versioning to serve recurring traffic from the cache at practically zero cost.

OPcache fine-tuning in practice

For OPcache I plan RAM generously so that frequently used scripts are not displaced. I monitor the number of revalidations and compilations; if they increase, I increase the script memory or optimize the autoloader. file cache for preloading can reduce cold starts if deployments are rare. A consistent deploy strategy is important: If timestamps change frequently, OPcache invalidates permanently - I minimize unnecessary changes to many files at the same time. I use preloading to initialize critical classes at the start so that the first requests benefit immediately.

API and microservice caching

Receive APIs own Cache strategies. GET endpoints with stable results get clear TTLs and ETags, while POST/PUT are not cacheable. I tag keys according to domain objects (e.g. user:123, product:456) and derive invalidation directly from system events. For GraphQL, I aggregate at field level and cache frequent subtrees to mitigate N+1 queries. I combine rate limits with caching so that expensive aggregations are not recalculated unchecked. Edge caches can store API responses regionally as long as consistency requirements allow.

Monitoring and observability

I extend answers by Diagnostic header (e.g. HIT/MISS, Age, Revalidate) to see the behavior in the field. In logs, I correlate status codes, TTFB and upstream times; a sudden increase in MISS with a simultaneous CPU peak indicates cache eviction or faulty invalidation. I separate dashboards by level: OPcache utilization, Redis latencies, page cache hit rate, CDN edge hit rate and regional latencies. For releases, I define SLOs (e.g. 95th percentile TTFB below X ms) and rollbacks if the metrics tilt. I supplement synthetic checks with real user monitoring to cover real devices and networks.

Operation, costs and scaling

I also optimize TTLs under Cost aspectsLonger CDN TTLs increase the edge hit rate and reduce origin traffic, but reduce purge windows. Short TTLs increase transfer and load. I control purges finely (by tag/key) instead of globally to avoid edge cold starts. For multi-region setups, I take replication times into account so that one region does not remain stale while the other is already fresh. I plan capacity for stampedes (autoscaling, burst RAM) and have emergency routes ready that remain performant with greatly simplified responses even in the event of partial failures. This keeps the system economical and robust.

SEO and Core Web Vitals

Heavy use of cache improved TTFB and subsequently LCP, which has a positive impact on user satisfaction and crawling budget. It is important that caching does not deliver outdated metadata, canonicals or hreflang variants. I decouple HTML cache from highly volatile parts and update critical pages (homepage, categories) as a priority. For bot traffic, I set realistic TTLs and avoid unnecessary 304 responses by actually keeping content fresh instead of revalidating every request. This keeps the site fast and consistent - for humans and crawlers.

Briefly summarized

I arrange Caching strategic: accelerate code first, then data, then pages and finally distribute globally. This schedule delivers measurably better loading times and saves server costs. I keep TTLs, purges and exceptions cleanly documented so that releases run smoothly. Metrics such as hit rate, TTFB and edge latency guide my next steps. If you combine these levels consistently, you create fast, scalable and reliable Websites.