Caching means your website keeps a ready copy of work already done, so the next visitor does not wait. When the copy matches the live page, the site feels fast. When the copy is old, or a page that should never be shared gets copied, visitors see stale prices or broken forms. The fix is not to avoid caching. It is to know which layer holds which copy, and what to check first.
The short answer: caching stores a ready copy — fast when it is right, stale when it is wrong
Every cache does the same job: it stores a result and reuses it until it expires or is cleared. A file served from a stored copy is a cache hit; one not stored yet, so the server must build it, is a cache miss. A hit on an unchanged page saves time. A hit on a price you changed this morning serves yesterday's price. Your developer sets each layer so public pages are copied and personal pages are not; your job is to test that split before customers do.
The problem: you were told to "add caching" and then your prices went stale
The usual story: a speed report flags your site, someone recommends caching, a switch gets flipped, and the site loads faster. Then a customer quotes an old price, a banner outlives its promotion, or a form starts failing for visitors who are not logged in. Because nobody explained that "caching" is four layers with different freshness risks, the failure looks like caching misbehaving. Usually one layer lacked exclusions, or a copy was never cleared after an update. Both are configuration problems, not reasons to run a slow site. If the site is simply slow, start with our owner diagnosis for a slow website instead.
The four layers, in plain language: browser, page, object and CDN cache
| Layer | Where the copy lives | What it stores | What it helps |
|---|---|---|---|
| Browser cache | The visitor's own device | Images, stylesheets, scripts and fonts | Repeat visits and moving between your pages |
| Page cache | Your server or hosting layer | Finished pages, ready to send | Visitors who all see the same public page |
| Object cache | Server memory | Results of repeated database questions | Busy pages that cannot be copied whole, such as accounts and admin screens |
| CDN cache | Servers in other locations, closer to visitors | Files, and sometimes whole pages | Visitors far from your hosting, and load on your own server |
The browser cache is governed by instructions your server sends, called Cache-Control headers, saying how long a file may be reused before checking. Page and CDN caches hold copies outside the visitor's device, so clearing your browser never clears them. An object cache matters mainly for stores and membership sites. Our wider guide to technical SEO and Core Web Vitals explains where this work sits in overall site health. Choosing a CDN is a separate decision: see our CDN guide for UAE websites.
What caching genuinely fixes: repeat work, slow repeat visits and server load
Without caching, a dynamic site rebuilds the same page for every visitor: running code, asking the database and assembling the same result. Caching removes that repetition. Returning visitors reuse files on their device instead of downloading your logo, styles and scripts. Public pages are served ready-made, and your server copes better under simultaneous visitors. A deliberate surge is a separate job: see our guide to preparing your website for traffic spikes. None of this repairs a heavy page or weak hosting. A large unoptimised image is still large on a first visit. Caching fixes repeated work, not the work itself.
What caching can break: stale prices and banners, forms, logins, carts and checkout
Every caching failure is a freshness failure. A copied page shows old content until it expires or is purged, so price changes, banners and opening hours can lag your edit. Forms can fail when a copied page carries an expired security token. The serious failures are personal: if a cart, checkout or logged-in page is copied and shared, one visitor can see another visitor's information. That is why exclusions matter more than speed settings, and why a careful developer tests logged-in and checkout behaviour afterwards.
The never-cache list: pages that must always load fresh
Ask for these exclusions in writing first:
- Cart, checkout and payment pages
- Login, account and order-history pages
- Any page showing one visitor their own details, bookings or documents
- Forms that rely on one-time security tokens, unless the system refreshes them safely
- Admin and editing screens
- Search results and other pages generated from each visitor's own input
Public pages identical for everyone — service pages, blog posts, landing pages — are natural candidates. A page that differs by viewer should load fresh, never as a shared copy.
"I updated the page but I still see the old one": the purge order that finds the stale copy
When an update does not appear, one layer holds the old copy. Work through them in order, not at random. First, check in a private window, which bypasses your browser cache. Second, purge that page in the page cache. Third, if database-driven content still looks old, ask for the object cache to be cleared. Fourth, purge the same address in the CDN. Note which layer held the stale copy: a good setup purges automatically on publish, and a recurring one is a fault to fix once.
How to know it is working: the owner's after-setup checks (private window, logged-in test, form test)
You do not need a speed tool to sign off. Open the updated page in a private window and confirm the new content appears. Log in as a customer and confirm you see only your own details. Add a product, reach checkout, and confirm the totals are yours and current. Submit the contact form and confirm the enquiry arrives. If a developer mentions Core Web Vitals, the published thresholds on web.dev are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile. Our Core Web Vitals launch checklist covers those checks in full.
Ten questions to ask your developer before caching is switched on
- Which layers are you enabling: browser, page, object, CDN, or a combination?
- Which pages are excluded, and is my never-cache list covered in full?
- What happens to carts, checkout and logged-in pages?
- How long does each kind of copy live before it expires?
- Are changed files given new versioned names, so browsers cannot keep old styles or scripts?
- Does publishing a page purge its copies automatically, at every layer?
- If a price changes urgently, how do I get the fresh page live, step by step?
- Are you using one page-caching tool only, or could two overlap?
- How will you test forms, logins and checkout after the change, and can I watch the results?
- If we later need the distance layer too, what would that involve? Our guide to how a website is developed shows where delivery choices are made.
Common mistakes (stacking two page caches; caching everything; never testing after a change)
The three mistakes behind most complaints are simple. Stacking two page caches, a plugin over a hosting cache, creates unpredictable conflicts. Caching everything, with no exclusions, trades a small speed gain for stale prices and privacy risk on personal pages. And never testing after a change lets a bad rule run until a customer reports it. One tool per layer, a written exclusion list and the checks above prevent nearly all of it.
FAQ
What is a cache hit and a cache miss?
A cache hit means the stored copy was found and served, so no rebuilding was needed. A cache miss means no copy was stored yet, so the server built the page and stored it for the next visitor. First-visit misses are normal; constant misses mean the cache is not working.
Why do I still see the old version of my page after an update?
Because one layer still holds the old copy. Check in a private window first, then have the page cache purged, then the object cache if the content comes from the database, and finally the CDN copy. A well-configured site purges automatically when you publish.
What should never be cached on my website?
Cart, checkout and payment pages, login and account pages, anything showing a visitor their own details, admin screens, and forms relying on one-time security tokens. These must load fresh for each visitor, or one customer could see another customer's information.
Is an object cache necessary for my site?
Not for a simple brochure site whose public pages can be copied whole. It becomes useful for stores, membership sites and busy admin areas, where pages cannot be shared but the same database questions repeat. Your hosting must support it, so ask first.
Will caching make my website faster on its own?
It removes repeated work, so repeat visits and public pages usually load faster. It does not fix oversized images, heavy design or weak hosting. Treat it as one layer of a sound build, which our core web development services page describes.
Want caching set up — and tested — properly? (CTA)
If your site got faster and stranger, the setup needs checking, not abandoning. WebStackRank builds websites where caching is configured with exclusions and tested against forms, logins and checkout before launch. Bring your never-cache list and the ten questions above, and talk to our website development company in Dubai about a setup review.
