Caching
Cache plugin compatibility and configuration
CR Bee Connect handles caching at two levels: API response caching (transients) and page cache compatibility (WP Rocket, LiteSpeed, etc.).
API Response Caching
The plugin caches API responses as WordPress transients to reduce API calls:
| Data | Cache Key | TTL |
|---|---|---|
| Settings | crbc_settings_{locale} | 5 minutes |
| Cars | crbc_cars | 5 minutes |
| Single Car | crbc_car_{slug} | 5 minutes |
| Featured Cars | crbc_cars_featured | 5 minutes |
| Locations | crbc_locations | 15 minutes |
| Categories | crbc_categories | 15 minutes |
| Addons | crbc_addons, crbc_addons_{carId} | 15 minutes |
| Features | crbc_features | 15 minutes |
Transactional data (sessions, bookings, quotes) is never cached.
Automatic Cache Invalidation
When you make changes in the CR Bee admin dashboard (e.g., add a vehicle, update prices), a catalog.updated webhook is sent to the plugin, which:
- Flushes the relevant transient cache (e.g.,
crbc_cars*) - Triggers a full page cache purge via the
crbc_cache_flushedaction
This ensures your WordPress site always shows up-to-date data.
Page Cache Compatibility
The per-session booking flow pages must not be cached by your page cache plugin, as they render live state (selected vehicle, dates, prices, session). The search landing page is the exception — it renders a static, visitor-identical form and is cacheable for speed. The plugin handles this split automatically.
Automatic Exclusion
On the per-session booking flow pages (results, vehicle details, addons, checkout, confirmation, manage), the plugin:
- Sets the
DONOTCACHEPAGEconstant - Sends
nocache_headers()(Cache-Control, Pragma, Expires)
The Search Landing Page Is Cacheable
The search/landing page (the [cr_bee_search] page, e.g. /book/) is left cacheable so it loads as fast as your homepage. It is safe to cache because:
- It renders a static search form with no per-user server-side state and fires no nonce-dependent AJAX (the submit is a plain navigation to the results page).
- Its location and operating-hours data is refreshed by the
catalog.updatedwebhook purge whenever you change locations or settings. - Visitors already in a booking flow (with a
crbc_sessioncookie) always bypass the cache and get a fresh render.
If the CR Bee API is briefly unreachable while the page is being (re)cached, the plugin declines to cache that degraded render (via DONOTCACHEPAGE) so a broken form is never frozen and served — it self-heals on the next request. The same guard protects the [cr_bee_search_widget] hero widget when it's embedded on a cached homepage.
Edge caches that sit in front of WordPress (a standalone CDN such as Cloudflare or Bunny, or an Nginx/FastCGI layer) are refreshed by the catalog.updated webhook purge and their own TTL. If you run such a layer and see stale search-form options after a settings change, lower its TTL for the landing page or trigger a manual purge.
Supported Cache Plugins
| Plugin | Integration |
|---|---|
| WP Rocket | Excludes CR Bee scripts from Delay JS; bypasses cache when crbc_session cookie exists; skips per-session flow pages from preload; full cache purge on webhook |
| LiteSpeed Cache | Full purge on webhook via litespeed_purge_all |
| WP Super Cache | Full purge on webhook via wp_cache_clear_cache() |
| W3 Total Cache | Full purge on webhook via w3tc_flush_all() |
WP Rocket Specifics
The plugin automatically configures these WP Rocket filters:
- Delay JS Exclusion — CR Bee scripts (
cr-bee-connect,crbc,flatpickr,splide) are excluded from JavaScript delay - Cookie Bypass — Cache is bypassed when the
crbc_sessioncookie exists - Preload Exclusion — The per-session flow pages are excluded from preload crawling (the cacheable search landing is allowed, so its cache stays warm)
No manual WP Rocket configuration is needed.
Manual Cache Flush
Go to CR Bee Connect > Cache tab and click Flush Cache to manually clear all cached API data.
DNS Optimization
The plugin automatically adds DNS prefetch and preconnect resource hints for the CR Bee API domain, improving connection speed for API calls.
Optimistic Page Transitions
To make the booking flow feel instant, the plugin uses an optimistic redirect pattern for the following actions:
| Action | Behavior |
|---|---|
| Search → Results | Results page paints immediately. Vehicle prices load asynchronously and replace skeleton placeholders inside each card. |
| Book Now → Extras | Browser navigates to the Extras page instantly with a skeleton layout. The plugin creates the booking session in the background, then reloads into the full Extras UI. |
| Continue → Checkout | Browser navigates to Checkout instantly with a skeleton. Addon selections are saved in the background, then the full Checkout renders. |
What you and your customers will see:
- A brief shimmer animation on parts of the page that are still loading (typically 100–500ms).
- The URL changes to the destination page the instant the button is clicked.
- If a validation error occurs (e.g., vehicle no longer available), the user is automatically bounced back to the previous page with a notice.
This pattern only affects the visual flow — booking data, payment processing, and confirmation pages are unchanged. The final Place Booking submit remains synchronous so payment outcomes are always confirmed before the confirmation page loads.
Customers with Reduce Motion enabled in their OS will see static placeholders instead of the shimmer animation.
Troubleshooting
- Stale data after changes — Click Flush Cache, or verify the webhook is registered
- Booking flow not working — Check that your cache plugin isn't caching booking pages
- WP Rocket conflicts — The plugin handles all WP Rocket configuration automatically; if issues persist, manually exclude booking page URLs from caching