What Website Caching Is and Why Old Pages Show Up

Website caching is the practice of keeping a ready-made copy of content so a site does not have to rebuild everything from scratch on every request. That copy might sit in the visitor’s browser, on the server, inside the application, or closer to the visitor through a CDN. The basic idea is simple: if the same result is needed again and again, it is more efficient to reuse it than to recompute it each time.

What a cached copy actually is

A cached copy is a response that has already been assembled and stored for reuse. If a homepage looks the same for most visitors, the site can keep one prepared version and serve it again instead of repeating the same work. That does not make the source content better. It only changes how much effort is needed to deliver it.

This matters because many site requests are repetitive. A blog post, an about page, or a product description may be viewed over and over without changing between visits. Cache helps a website avoid unnecessary repetition and makes it easier to answer those requests without asking the server to assemble everything again each time.

Where cache can live on a site

People often speak about cache as if there were only one place it lives, but the term covers several layers.

• Browser cache: the visitor’s browser stores files such as images, CSS, and some scripts so they do not need to be downloaded again immediately.
• Page cache: a finished HTML page is stored after it is built, so the next request can receive the ready-made page.
• Server-side cache: the server or application stores prepared results to avoid repeating expensive work.
• Object cache: smaller pieces of data, such as query results or repeated calculations, are stored for reuse.
• CDN cache: copies are stored on servers placed closer to visitors in different regions.

These layers are related, but they do not do the same job. Browser cache helps the same person return to the same site. Page cache helps the site answer many visitors with one prepared page. Object cache helps the application avoid asking the database the same question repeatedly. CDN cache reduces the distance between the visitor and the copy being served.

Static pages and dynamic pages behave differently

Static content is mostly the same for everyone. Dynamic content changes based on who is visiting, what they have done before, what is in their cart, or whether they are logged in. Cache is usually easiest when content is stable. It becomes more delicate when the page depends on the user or on a live state that can change quickly.

A blog article can often be cached with little risk because the article itself does not change for each visitor. A cart page, account page, or checkout page is different because it reflects a session and may need to show unique data. A homepage may also have mixed content: a fixed layout, a rotating announcement, and a personalized message for logged-in users. The site must know which part can be reused and which part must stay dynamic.

Why old content sometimes appears after an update

When a price changes, a paragraph is edited, or a new image is added, that update does not always show instantly to every visitor. The old version may still be held in browser cache, page cache, or CDN cache. That does not automatically mean something broke. It often means the stored copy has not expired yet or has not been purged.

That is where TTL, or time to live, comes in. A cached item may be allowed to live for a fixed period before it is treated as stale. Some systems refresh it automatically after that period ends. Others need a purge or invalidation so the old response is discarded and rebuilt. If that refresh happens later than expected, a visitor can still see the older page for a while.

If you want to separate cache from other reasons a site feels sluggish, see why a website can still feel slow even when caching is in place. Cache is only one part of the overall response path, so stale content and slow content are not always the same problem.

How cache connects to Core Web Vitals

Cache often affects the practical experience people notice, but it is not a score by itself. The page may feel faster because fewer resources need to be rebuilt, while the actual user experience still depends on layout shifts, response timing, and how quickly the browser can show something useful.

If you want to connect the idea of cache to user-facing performance metrics, read what Core Web Vitals measure and why a cached page can still have weak metrics. The point is not that cache replaces those metrics. It is that cache can influence them in real use.

A page can be cached and still feel awkward if the largest image is heavy, if scripts delay rendering, or if the browser must wait on other assets. Likewise, a page can be uncached yet still present acceptable metrics if the rest of the delivery path is clean. Cache is one piece of the puzzle.

Logged-in users, carts, and sessions need special handling

Cache works best when many people can see the same thing. Logged-in visitors are different because their dashboard, account details, saved preferences, or personal notices may not match what anonymous visitors see. If a personalized page is cached as if it were public, the wrong person could briefly see the wrong data. That is why logged-in areas usually need different rules.

Online stores make this more sensitive. Cart contents, shipping selection, and checkout steps are session-dependent. Those pages must be handled carefully so a cached copy does not interfere with the current user’s session. A product page can often benefit from cache, but a cart page generally needs to stay tied to the live session. In practice, the goal is not to cache everything. The goal is to cache the right parts.

• Public content is usually the best candidate for cache.
• Account, cart, and checkout areas should stay session-aware.
• Some pages are partly cached and partly dynamic, which is normal.

When cache helps, and when it can mislead you

Cache helps when the same resource is requested repeatedly and the underlying content does not change every minute. It can also mislead site owners when they expect an instant update and the site is still serving a stored copy. In those cases, the issue is not that cache is bad. It is that the wrong layer is still holding the previous version.

That is why a page can look correct in the editor but still appear old in the browser. The source data has changed, but one of the stored copies has not been replaced yet. Understanding which layer is serving the response is the key to interpreting that behavior correctly.

Cache is not backup or database optimization

These terms are often mixed together, but they solve different problems. A backup is for recovery. It is a safety copy, not a speed layer. Database optimization improves how the database stores and finds information, which can help performance, but it is not the same thing as serving a cached response. A CDN is a distributed network that can serve content from locations closer to visitors, and it may include caching, but it is not identical to site cache.

Keeping the differences clear prevents false assumptions. A backup will not make a page load faster. A CDN will not automatically fix a poorly structured database. Cache will not repair broken content or replace good site architecture. Each tool has its own job, and each one has limits.

Website caching works best when you also understand where the first response time comes from, so TTFB is a natural companion. If cached pages still feel slow, the issue may be deeper in the delivery path or in the application layer.

That is why a CDN, Redis object cache, WordPress, and WooCommerce matter when cache hits need to serve both static and dynamic content efficiently.