---
title: Web Cache
description: Storing expensive work (HTML, queries, assets) so the next request is faster and cheaper on server resources.
canonical: https://penasihathosting.com/en/hosting-wiki/web-cache
type: wiki
locale: en
updated: 2026-07-15
author: Willya Randika
---

# Web Cache

## Overview

- **Summary:** Storing expensive work (HTML, queries, assets) so the next request is faster and cheaper on server resources.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

**Caching** in hosting means storing expensive work so the next request is faster and cheaper on resources. Without cache, every visit may force [PHP](/en/hosting-wiki/php) and [MySQL](/en/hosting-wiki/mysql) to redo the same computation — from post queries to building full HTML.

Cache is not one magic switch. People often mix layers: browser cache, page cache, object cache, OPcache, and [CDN](/en/hosting-wiki/cdn) edge cache. Knowing which layer is active prevents the “I cleared cache but it is still stale” loop.

## A Simple Analogy

Imagine a kitchen that cooks every order from scratch. Cache is like **keeping popular dishes ready**. The next customer is served faster, and the stove (CPU) is not always on. If the menu changes but yesterday’s dish stays on the counter, guests get stale food — stale content.

## Common Cache Layers

| Layer | What it stores | Examples |
| --- | --- | --- |
| Browser | Static assets on the device | CSS, images, fonts |
| Page cache | Finished HTML | WordPress cache plugins, LiteSpeed Cache |
| Object cache | Query/object results | Redis, Memcached |
| OPcache | PHP bytecode | Built-in PHP extension |
| CDN | Copies at the edge | Cloudflare, Bunny |

## Benefits and Trade-offs

Main benefits: better TTFB, lower [entry process](/en/hosting-wiki/entry-processes-ep) pressure, and more headroom during traffic spikes. Trade-offs: stale content if purge fails; carts, checkout, and logged-in dashboards usually must be excluded from full page cache. A bad config can even cache a private page for the wrong user — a serious risk.

## What to Watch For

- Avoid stacking plugin cache + CDN + server cache without clear rules  
- Always test cart, checkout, and account areas after enabling cache  
- Purge after deploys, theme changes, or important content updates  
- Cache does not fix catastrophic slow queries by itself  
- Watch hit rate when panel or plugin tooling exposes it  

## FAQ

<Accordion>
  <AccordionItem title="Is cache the same as a CDN?">
    CDNs often include edge caching, but origin caches can exist without any CDN at all.
  </AccordionItem>
  <AccordionItem title="Why do visitors still see old content?">
    Page cache or CDN was not purged. Clear the plugin cache, then purge the edge if you use Cloudflare.
  </AccordionItem>
  <AccordionItem title="Can every page be cached?">
    No. Per-user dynamic pages are usually excluded so data does not leak across sessions.
  </AccordionItem>
  <AccordionItem title="Can cache cause Error 508?">
    Healthy cache reduces 508 pressure. Conflicting plugins or bad rules can add load instead of removing it.
  </AccordionItem>
</Accordion>