Web caching is the mechanism by which copies of resources — HTML pages, images, CSS, JavaScript — are stored at different points along the chain between the server and the user's browser, so that future requests can be answered faster without regenerating or re-downloading the resource from scratch. In short: caching eliminates repeated work and cuts load times.
There are four main caching layers, each sitting at a different point in the delivery chain. Here's what each one does, how to configure it, and when to use it.
Browser Cache
This is the cache that lives on the user's own device. When you visit a site for the first time, the browser downloads all the required resources — images, stylesheets, scripts, fonts — and stores them on the local disk. On the next visit (or on another page of the same site), the browser can reuse those files instead of downloading them again.
How it's controlled
The server tells the browser how long to store each resource using HTTP headers:
Cache-Control: max-age=31536000— stores the file for one year (ideal for versioned assets likeapp.v3.js).Cache-Control: no-cache— the browser stores the file but must verify with the server that it's still fresh before using it.Cache-Control: no-store— the browser stores nothing (for sensitive or real-time data).ETag/Last-Modified— enable conditional revalidation: the server only sends the full resource if it has changed.
When to use it
Always. Browser caching is the cheapest layer to implement and has immediate impact on returning visitors. Static resources that rarely change — logos, base CSS, JS libraries — are perfect candidates for long cache durations. Resources that change frequently should use cache busting — including a hash in the filename — so changes reach users without requiring a manual cache clear.
Server-Side Cache
This lives on the web server itself or in the application layer. Instead of running PHP, querying the database, and building HTML on every request, the server stores the final result and delivers it directly on subsequent visits.
Types of server-side cache
- Full-page cache: stores the complete HTML for each URL. It's the most effective way to reduce TTFB on dynamic sites. Tools: Varnish, Nginx FastCGI cache, WP Rocket (WordPress).
- Object cache: stores results of database queries or expensive computations in memory. Redis and Memcached are the most popular solutions. Useful when the page is dynamic but certain data doesn't change often.
- Opcode cache: PHP compiles every
.phpfile to bytecode on each execution. OPcache stores that bytecode in memory to avoid recompiling on every request. It's enabled by default in PHP 5.5+ and is completely transparent to the application.
When to use it
Full-page caching is especially valuable for high-traffic sites where the same URLs are hit repeatedly — blogs, online stores, news portals — and where the HTML doesn't change between anonymous visitors. Object caching complements full-page caching when content does vary (by user, session, or parameters) but reusable fragments exist.
CDN Cache (Content Delivery Network)
A CDN is a network of geographically distributed servers. When a user requests a resource, the CDN serves it from the node closest to their location instead of from the origin server. Beyond shortening physical distance, the CDN also stores a copy of the resource at that node for future requests from the same region.
What a CDN typically caches
| Content type | Typically CDN-cached? | Typical cache duration |
|---|---|---|
| Images (JPG, WebP, PNG, SVG) | Yes | 7 days to 1 year |
| CSS and JavaScript | Yes | 1 day to 1 year (with versioning) |
| Web fonts | Yes | 1 year |
| Dynamic HTML | Optional (edge caching) | Seconds to minutes |
| Personalized API responses | No (by default) | — |
When to use it
A CDN is essential when your users are spread across multiple countries or regions. Without one, every user hits the same origin server — with whatever latency their distance implies. With a CDN, each user receives content from the nearest node. Cloudflare, Fastly, BunnyCDN, and Amazon CloudFront are the most widely used options.
Proxy Cache
A proxy cache is an intermediary server sitting between users and the origin server. It can be under the control of the organization (corporate proxy or reverse proxy) or the internet provider. Any resource requested through the proxy gets stored there; if another request asks for the same resource, the proxy serves it directly without contacting the origin.
Reverse proxy vs. forward proxy
- Reverse proxy: sits in front of the origin server and intermediates requests from clients. Nginx and Apache acting as reverse proxies with caching are common examples. Varnish is a reverse proxy designed specifically for high-performance caching.
- Forward proxy: sits on the client side — in corporate networks, for example — and caches resources for all users on that network. Less relevant for the site operator, but it can affect how users receive content.
When to use it
A reverse proxy is especially useful in self-managed infrastructure when you want to control caching at the server level without relying on an external CDN. Varnish in front of Apache or Nginx can absorb thousands of requests per second by serving cached content, freeing the application server for requests that actually require dynamic processing.
How the Four Layers Work Together
The four layers aren't mutually exclusive — the optimal strategy is to use them together. A typical flow for a high-traffic site looks like this:
- The browser has CSS and images cached from the previous visit → served in 0 ms.
- If the resource isn't in the browser cache, the request reaches the CDN → the local node serves it in tens of milliseconds.
- If the CDN also misses (cache miss), the request reaches the reverse proxy / Varnish → serves the HTML from disk cache in ~5 ms.
- If no proxy cache exists either, the request reaches the PHP application, which first checks the object cache (Redis) before hitting the database.
This layered model means very few requests ever reach the database — the most expensive resource in terms of time and server load.
To understand how caching directly impacts specific metrics like TTFB or LCP, visit our web performance article archive for technical step-by-step guides.
If you need help designing and implementing the right caching strategy for your site, the team at elenlace.com can architect the correct solution for your stack and traffic volume.
Key Takeaways
- There are four main web caching layers: browser, server, CDN, and proxy.
- Browser caching reduces downloads on return visits; controlled with HTTP headers like
Cache-Control. - Server-side caching (full-page, object cache, OPcache) avoids regenerating pages and repeated database queries.
- CDNs reduce network latency by distributing content on servers close to the user.
- Reverse proxies absorb traffic spikes by serving cached content before requests reach the application.
- The optimal strategy uses all four layers together, each complementing the others.
Ready to build a complete caching strategy for your site? Contact the team at elenlace.com and get a proposal tailored to your infrastructure and performance goals.
FAQ
When should I invalidate or clear the cache?
Invalidate the cache whenever you publish new content or update a resource that is being cached. Modern CMS and CDN systems let you do this automatically on publish or via URL-based rules. For static assets, cache busting with versioned filenames is the most reliable solution.
Can caching cause users to see outdated content?
Yes, if not configured correctly. For dynamic personalized content — shopping carts, user dashboards — caching must either exclude those URLs or be scoped per session. For public content that changes frequently, short cache durations or active invalidation solve the problem.
What's the difference between Varnish and Redis?
Varnish is an HTTP accelerator (reverse proxy cache) that stores complete HTTP responses — entire pages — and serves them directly without involving PHP. Redis is an in-memory object cache that stores data fragments (query results, sessions, counters) for the PHP application to retrieve quickly. They're complementary: Varnish works at the HTTP layer, Redis at the application data layer.
Does browser caching affect all users equally?
No. Browser cache is local to each device. The first-time visitor always downloads all resources; only return visits from the same device benefit. Server-side cache and CDN cache, however, benefit every visitor from the very first request.
Useful resources
Other providers and guides worth comparing:
