Caching and Performance
Every filter change triggers a database query and HTML render. On busy sites—or large WooCommerce catalogs—repeat visitors hitting the same filter combinations can load the server unnecessarily. WPEnhanced Ajax Filter Blocks includes transient caching to store AJAX results temporarily and serve them faster.
Configure caching under WP Enhanced → WPEnhanced Ajax Filter Blocks → Caching (section name may vary). See Plugin settings for the admin hub.
What gets cached
When caching is enabled, the plugin stores the rendered loop and filter count responses for a given combination of:
- Filter parameter values (category, price, search, etc.)
- Archive Loop query settings on the page
- Pagination state (when applicable)
The next visitor (or the same visitor) requesting the identical combination receives the cached HTML until the entry expires—skipping duplicate query work.
Caching does not replace full-page HTML cache from host or CDN plugins. It optimizes the plugin’s AJAX endpoints specifically.
Enable transient caching
- Go to WP Enhanced → WPEnhanced Ajax Filter Blocks.
- Enable Cache (or Enable transient caching).
- Set Cache expiry—typical values:
- 15–60 minutes — Active catalogs with frequent stock changes
- 2–12 hours — Stable blogs and directories
- 24 hours — Mostly static archives with occasional updates
- Save settings.
When cache is disabled, expiry and advanced cache type fields are hidden.
Cache storage types
| Type | When to use |
|---|---|
| WordPress transients | Default; stored in wp_options—fine for small/medium sites |
| Redis | High-traffic sites with Redis object cache already configured |
| Memcached | Same as Redis; use when Memcached is your object cache backend |
For Redis or Memcached, provide:
- Cache IP / host — Server hostname or IP
- Cache port — Usually 6379 (Redis) or 11211 (Memcached)
The admin UI may show a connection notice after save when Redis/Memcached is selected but unreachable. Fix connection details before relying on external object cache.
External object cache must be configured at the server or via a Redis/Memcached WordPress plugin. WPEnhanced Ajax Filter Blocks connects to your existing cache layer—it does not install Redis for you.
Flush cache
Flush cache when:
- Bulk importing products or posts
- Changing prices, attributes, or categories affecting filters
- Deploying query or template changes that should appear immediately
- Debugging “stale” results reported by QA
Flush cache button in plugin settings clears all Ajax Filter transient entries. A confirmation dialog prevents accidental clears.
You can also flush via admin AJAX action when custom tooling integrates with the plugin (developer hook—see PHP hooks when available).
After flushing, first requests for each filter combination rebuild cache entries (slightly slower), then subsequent hits are fast again.
Interaction with full-page cache
| Layer | What it caches |
|---|---|
| CDN / page cache | Entire HTML document |
| Ajax Filter transients | AJAX filter/loop JSON and HTML fragments |
If a page cache plugin caches filtered pages with query strings, visitors may see outdated full pages even when AJAX cache is fresh. Configure your page cache plugin to:
- Bypass cache for unique filter query strings, or
- Exclude filtered landing pages from full-page cache
AJAX updates after initial load still benefit from transient cache regardless of page cache.
Catalog Index (Pro)
On very large WooCommerce stores, filter count calculation can be slow even with transients. Catalog Index (Pro) pre-builds an index of taxonomy and attribute counts for faster facet updates—complementary to transient caching, not a replacement.
Performance beyond caching
| Technique | Benefit |
|---|---|
| Sensible post count on Archive Loop | Smaller HTML payloads per AJAX response |
| Empty filter options | Fewer DOM nodes in filter panels |
| Higher search typing delay | Fewer search AJAX calls |
| On button click update method | Fewer requests while visitor adjusts multiple filters |
| Optimized product images in loop templates | Faster perceived load |
Monitoring cache effectiveness
- Enable cache with a 1-hour expiry on staging.
- Load a filtered page; note response time in browser Network tab.
- Repeat the same filter combination—second request should be faster.
- Flush cache; confirm first-hit slowdown returns.
If the second request is not faster, verify cache is enabled, no plugin clears transients on every request, and Redis/Memcached credentials are correct.
Troubleshooting
| Issue | Action |
|---|---|
| Changes not visible after edit | Flush cache; check expiry length |
| Redis selected but cache misses | Verify Redis plugin and IP/port |
| Site slow with cache on | WordPress transients on huge sites—move to Redis |
| Counts wrong until flush | Expected after bulk edit—automate flush in import workflow |
Related: Stale or wrong results.
What's next
- Plugin settings — All global admin options
- Catalog Index — Pro count indexing
- Empty filter options — Reduce facet DOM weight