> For the complete documentation index, see [llms.txt](https://ctracker-docs.keywordrush.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ctracker-docs.keywordrush.com/running-your-site/caching-and-performance.md).

# Caching and performance

A cashback site has two kinds of page, and a page cache has to treat them differently.

### The rule

**Never cache anything personal.** Everything else, cache freely.

| Cache these                           | Never cache these                                       |
| ------------------------------------- | ------------------------------------------------------- |
| Shop pages                            | The member account page                                 |
| The shop directory and category pages | Any page with `[cashback-account]`                      |
| Coupon pages                          | Any page with `[cashback-balance]` or the Balance block |
| Your posts and static pages           | Anything showing a signed-in member's own data          |

Get this wrong in one particular way and it is serious: a cached account page can show **one member another member's balance**. Most caching plugins skip caching for signed-in users by default, which avoids it — but check rather than assume, because that default is exactly the thing people turn off to speed up a slow site.

### Setting it up

Most caching plugins have a list of pages never to cache. Add:

* your member account page
* any page carrying a balance shortcode or block

If your plugin has a **do not cache for logged-in users** option, switch it on. That single setting covers everything above.

### The Go to shop button

The button itself is safe to cache — it goes to a plugin URL that works out the member and the destination when it is pressed, not when the page is built.

What matters is that the **redirect** is not cached. A cached redirect would send every member to the same destination with the same tag, which would credit one member for everybody else's purchases. No sane caching plugin caches a redirect, but if you have written custom rules, exclude the plugin's tracking URLs.

{% hint style="warning" %}
If members report cashback going to the wrong person, this is the first thing to check. It is rare, and it is nearly always a hand-written cache rule.
{% endhint %}

### Object caching

Redis or Memcached is straightforward here — the plugin uses WordPress's normal caching functions and benefits like anything else. Nothing special to configure.

### What makes a cashback site slow

**The shop directory, with too many per page.** `Settings` → `General` → **Shops per page** defaults to 24 for a reason. Setting it to 100 means 100 logos and 100 rate lookups per page view.

**Enormous catalogues with a page each.** Several thousand shop pages is several thousand posts, plus a logo each in your media library. Before creating a page for every shop in a large network, ask whether you want pages for shops nobody will search for — see [Creating shop pages in bulk](/shops-and-cashback-rates/creating-shop-pages-in-bulk.md).

**Background work landing all at once.** Importing shops, coupons and orders are all queued jobs. On a small host they can bunch up. If your site slows at predictable times, lengthen **Download new orders** and lower **Shops per run** for coupons.

**Unbounded logs.** The log is capped and pruned daily, so this should not happen — but if you have set retention very high, check `Cashback Tracker` → `Logs`. See [Logs and alerts](/running-your-site/logs-and-alerts.md).

### Sorting and filtering are pre-calculated

Sorting the directory by cashback, rating or coupon count does not compute anything at page load — those are worked out in the background and stored ready. That is why the directory stays fast on a large catalogue.

If a sort looks stale after a bulk change, the indexes rebuild in the background; give it a few minutes.

### A reasonable setup

For most sites:

* A page cache, with logged-in users excluded
* The account page explicitly excluded as well
* Object caching if your host offers it
* Shops per page left at 24
* A CDN for images

That is enough. Nothing here needs an unusual host.

### Related

* [Scheduled tasks](/running-your-site/scheduled-tasks.md)
* [Troubleshooting](/running-your-site/troubleshooting.md)
* [The member account page](/members-and-payouts/the-account-page.md)