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.
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.
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.
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.
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.
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
Last updated