Batcache VIP platform specific

This document is for sites running on VIP.

Learn more

Overview # uses Batcache to store and serve cached versions of rendered pages. Batcache uses memcached as its storage and is aimed at preventing a flood of traffic from breaking your site. It does this by serving old pages to new users. The caching is introduced after the same page has been requested at least 4 times in 5 minutes. This reduces the demand on the web server CPU and the database. It also means some people may see a page that is up to 5 minutes old.

↑ Top ↑

Who receives a cached pageview? #

By default, all new users receive a cached pageview.

New users are defined as anybody who hasn’t interacted with your domain—once they’ve left a comment or logged in, their cookies will ensure they get fresh pages. People arriving from Reddit won’t notice that the comments are a minute or two behind, but they’ll appreciate your site being up.

↑ Top ↑

Cache Groups #

We bucket users into different cache groups depending on the type of user they are. This means that you can vary the content you serve to each of these groups without worrying about cache collisions, as long as you use our helper functions.

* Logged-in user or commenter (no cache)
* Desktop
* Smartphone
* Dumbphone
* iPad
* Tablet

↑ Top ↑

Exemptions #

Note that most URLs with query strings are automatically exempt from Batcache caching. (Query string variables tend to signal dynamic input that informs dynamic output, so we provide an uncached result every time.) This can be undesirable in many cases as popular pages linked to with query strings can significantly reduce the effectiveness of our caching setup and can affect the overall performance of your site.

These query string parameters are an exception to this, and if a URL only contains one or more of these, it will still be subject to Batcache:

  • hpt
  • eref
  • iref
  • fbid
  • om_rid
  • utm
  • utm_source
  • utm_content
  • utm_medium
  • utm_campaign
  • utm_term
  • fb_xd_bust
  • fb_xd_fragment
  • npt
  • module
  • iid
  • cid
  • icid
  • ncid
  • snapid
  • hootPostID
  • _

Note that these query-string parameters will be removed from requests prior to processing, and thus they will not be accessible during processing of requests.

Hashbang URLs are cached based on the part of the URL prior to the hashbang. Any AJAX-originated HTTP requests based on hashbang state information may be subject to caching as well.

↑ Top ↑

Avoid server-side operations #

Because Batcache caches fully rendered pages, per-user interactions on the server-side can be problematic. This means usage of objects/functions like $_COOKIE, setcookie, $_SERVER['HTTP_USER_AGENT'], and anything that’s unique to an individual user cannot be relied on as the values may be cached and cross-pollution can occur.

In most cases, any user-level interactions should be moved to client-side using javascript.

In some cases, we can help you set up Batcache variants if you’re limiting your interactions to a small set of distinct groups (e.g. serve different content for users depending on whether the cookie “customer-type” is set, or equals “paid” or “pending”). Please get in touch if this something you’re interested in setting up.

↑ Top ↑

Additional Resources #

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.