Field Forge integrates with WordPress’s object cache API (wp_cache_*) for fast field value lookups, plus provides a batch_load() API for eliminating N+1 query problems on large sites. Combined with custom table storage, this makes Field Forge the fastest WordPress custom fields plugin on high-traffic sites.
WordPress’s wp_cache_* functions provide a caching layer that sits between your code and the database. By default, WordPress uses a per-request in-memory cache (cleared at the end of each request). With a persistent object cache backend like Redis or Memcached, the cache survives between requests — subsequent pageviews hit the cache instead of the database.
On a high-traffic site with Redis:
For read-heavy workloads, this is a 10–100x performance improvement.
Every field value read in Field Forge goes through the object cache:
// Inside Field Forge's get_field() implementation (simplified)
$cached = wp_cache_get($cache_key, 'fieldforge');
if ($cached !== false) {
return $cached;
}
$value = $this->fetch_from_database($post_id, $field_name);
wp_cache_set($cache_key, $value, 'fieldforge', 3600);
return $value;
fieldforge:{post_id}:{field_name}fieldforge (separate from other plugins)When a field value is updated or deleted, Field Forge automatically invalidates the relevant cache entries:
// Inside update_field() (simplified)
$this->save_to_database($post_id, $field_name, $value);
wp_cache_delete("fieldforge:{$post_id}:{$field_name}", 'fieldforge');
Invalidation is:
fieldforge/cache/invalidate hookField Forge works with any WordPress object cache backend:
Most common for managed WordPress hosting. Free plugins: “Redis Object Cache” or “W3 Total Cache” with Redis enabled. Provides persistent caching across requests.
Older but still supported. Plugins: “Memcached” or “W3 Total Cache.”
Single-server caching that’s faster than Redis/Memcached for lower-traffic sites (no network hop). Plugins: “APCu Object Cache.”
If no persistent object cache backend is installed, Field Forge falls back to WordPress’s default in-request cache. Caching still happens within a single pageview, but not between requests. Works everywhere, zero configuration.
For archive pages and list views where you’re rendering many posts at once, Field Forge provides a batch_load() API that fetches custom fields for multiple posts in a single SQL query:
$post_ids = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
FieldForge::batch_load($post_ids);
// All subsequent get_field() calls on these post IDs hit the cache
foreach ($post_ids as $id) {
$hero_title = get_field('hero_title', $id); // Cache hit
$hero_image = get_field('hero_image', $id); // Cache hit
}
Without batch_load(), the above would fire 20 separate SQL queries (10 posts × 2 fields each). With batch loading, it’s 1 query.
Field Forge hooks into WordPress’s the_posts filter to run batch loading automatically on any query that returns multiple posts:
// Field Forge's internal hook
add_filter('the_posts', function($posts) {
if (!empty($posts)) {
$post_ids = wp_list_pluck($posts, 'ID');
FieldForge::batch_load($post_ids);
}
return $posts;
});
Archive pages, search results, category listings, and REST API list endpoints all benefit automatically. No code changes needed in your theme.
For WP_Query calls in custom templates, you can explicitly batch-load after the query:
$query = new WP_Query([
'post_type' => 'product',
'posts_per_page' => 30,
'category_name' => 'featured',
]);
// Batch load custom fields for all 30 products in one query
if ($query->have_posts()) {
$post_ids = wp_list_pluck($query->posts, 'ID');
FieldForge::batch_load($post_ids);
}
// Now rendering the loop is cache-hit only
while ($query->have_posts()) : $query->the_post();
$price = get_field('price'); // Cache hit
$sku = get_field('sku'); // Cache hit
$features = get_field('features'); // Cache hit
endwhile;
On a test site with 10,000 posts, 15 custom fields per post:
| Action | Time |
|---|---|
| Single post pageview | 45ms custom field queries |
| Archive (20 posts) | 840ms custom field queries (N+1) |
| WooCommerce category (30 products) | 1,260ms |
| Action | Time |
|---|---|
| Single post pageview | 3ms (cache hits) |
| Archive (20 posts) | 12ms (cache hits) |
| WooCommerce category (30 products) | 18ms |
| Action | Time |
|---|---|
| Single post pageview | 12ms (1 query + cache populate) |
| Archive (20 posts) | 95ms (1 batch query + cache populate) |
| WooCommerce category (30 products) | 142ms (1 batch query + cache populate) |
The combination of object cache and batch loading is dramatic on high-traffic sites.
Field Forge provides WP-CLI commands for monitoring cache performance:
# Show cache stats
wp fieldforge cache stats
# Output:
# Cache hits: 94.3%
# Cache misses: 5.7%
# Avg hit time: 0.2ms
# Avg miss time: 8ms
For sites where cache hit rate is low (below 80%), investigate:
add_filter('fieldforge/cache/expiration', function($seconds) {
return DAY_IN_SECONDS; // Cache for 24 hours
});
add_filter('fieldforge/cache/should_cache', function($should_cache, $field_group) {
if ($field_group === 'frequently-changing-group') {
return false;
}
return $should_cache;
}, 10, 2);
add_action('fieldforge/cache/invalidate', function($post_id, $field_name) {
// Also invalidate related data
wp_cache_delete("my_custom_cache:{$post_id}", 'my_plugin');
}, 10, 2);
Get Field Forge — from $35/year →
Object cache integration and batch loading are in every version of Field Forge, including the free one.