Die wp_cache_*-Funktionen von WordPress bieten eine Cache-Schicht, die zwischen Ihrem Code und der Datenbank sitzt. Standardmäßig verwendet WordPress einen speicherinternen Cache pro Anfrage (der am Ende jeder Anfrage gelöscht wird). Mit einem persistenten Objekt-Cache-Backend wie Redis oder Memcached überlebt der Cache zwischen den Anfragen — nachfolgende Seitenaufrufe greifen auf den Cache zu, anstatt die Datenbank zu kontaktieren.
Auf einer stark frequentierten Seite mit Redis:
Für leseintensive Arbeitslasten ist dies eine 10–100-fache Leistungssteigerung.
Jeder Feldwert, der in Field Forge gelesen wird, durchläuft den Objekt-Cache:
“`php // Innerhalb der get_field()-Implementierung von Field Forge (vereinfacht) $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 (getrennt von anderen Plugins)Wenn ein Feldwert aktualisiert oder gelöscht wird, invalidiert Field Forge automatisch die relevanten Cache-Einträge:
“php // Innerhalb von update_field() (vereinfacht) $this->save_to_database($post_id, $field_name, $value); wp_cache_delete("fieldforge:{$post_id}:{$field_name}", 'fieldforge'); “
Die Invalidierung ist:
fieldforge/cache/invalidate-Hook hinzufügenField Forge funktioniert mit jedem WordPress-Objekt-Cache-Backend:
Am häufigsten für verwaltetes WordPress-Hosting. Kostenlose Plugins: “Redis Object Cache” oder “W3 Total Cache” mit aktiviertem Redis. Bietet persistente Caching über Anfragen hinweg.
Älter, aber immer noch unterstützt. Plugins: “Memcached” oder “W3 Total Cache.”
Einzelserver-Caching, das schneller ist als Redis/Memcached für weniger frequentierte Seiten (kein Netzwerk-Hops). Plugins: “APCu Object Cache.”
Wenn kein persistentes Objekt-Cache-Backend installiert ist, fällt Field Forge auf den Standard-Speicher-Cache von WordPress zurück. Caching findet weiterhin innerhalb eines einzelnen Seitenaufrufs statt, jedoch nicht zwischen Anfragen. Funktioniert überall, null Konfiguration.
Für Archivseiten und Listenansichten, in denen Sie viele Beiträge gleichzeitig rendern, bietet Field Forge eine batch_load()-API, die benutzerdefinierte Felder für mehrere Beiträge in einer einzigen SQL-Abfrage abruft:
“`php $post_ids = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; FieldForge::batch_load($post_ids);
// Alle nachfolgenden get_field()-Aufrufe für diese Post-IDs greifen auf den Cache zu foreach ($post_ids as $id) { $hero_title = get_field(‘hero_title’, $id); // Cache-Hit $hero_image = get_field(‘hero_image’, $id); // Cache-Hit } “`
Ohne batch_load() würden oben 20 separate SQL-Abfragen ausgeführt (10 Beiträge × 2 Felder jeweils). Mit Batch-Laden ist es 1 Abfrage.
Field Forge greift in den the_posts-Filter von WordPress ein, um das Batch-Laden automatisch bei jeder Abfrage auszuführen, die mehrere Beiträge zurückgibt:
“php // Interner Hook von Field Forge add_filter('the_posts', function($posts) { if (!empty($posts)) { $post_ids = wp_list_pluck($posts, 'ID'); FieldForge::batch_load($post_ids); } return $posts; }); “
Archivseiten, Suchergebnisse, Kategorienlisten und REST-API-Listenendpunkte profitieren automatisch. Keine Codeänderungen in Ihrem Theme erforderlich.
Für WP_Query-Aufrufe in benutzerdefinierten Vorlagen können Sie nach der Abfrage explizit Batch-Laden:
“`php $query = new WP_Query([ ‘post_type’ => ‘product’, ‘posts_per_page’ => 30, ‘category_name’ => ‘featured’, ]);
// Batch-Laden benutzerdefinierter Felder für alle 30 Produkte in einer Abfrage if ($query->have_posts()) { $post_ids = wp_list_pluck($query->posts, ‘ID’); FieldForge::batch_load($post_ids); }
// Jetzt wird die Schleife nur bei Cache-Hits gerendert 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; “`
Auf einer Testseite mit 10.000 Beiträgen, 15 benutzerdefinierten Feldern pro Beitrag:
| Aktion | Zeit |
|---|---|
| Einzelner Beitrag Seitenaufruf | 45ms benutzerdefinierte Feldabfragen |
| Archiv (20 Beiträge) | 840ms benutzerdefinierte Feldabfragen (N+1) |
| WooCommerce-Kategorie (30 Produkte) | 1.260ms |
| Aktion | Zeit |
|---|---|
| Einzelner Beitrag Seitenaufruf | 3ms (Cache-Hits) |
| Archiv (20 Beiträge) | 12ms (Cache-Hits) |
| WooCommerce-Kategorie (30 Produkte) | 18ms |
| Aktion | Zeit |
|---|---|
| Einzelner Beitrag Seitenaufruf | 12ms (1 Abfrage + Cache befüllen) |
| Archiv (20 Beiträge) | 95ms (1 Batch-Abfrage + Cache befüllen) |
| WooCommerce-Kategorie (30 Produkte) | 142ms (1 Batch-Abfrage + Cache befüllen) |
Die Kombination aus Objekt-Cache und Batch-Laden ist dramatisch auf stark frequentierten Seiten.
Field Forge bietet WP-CLI-Befehle zur Überwachung der Cache-Leistung:
“`bash
wp fieldforge cache stats
“`
Für Seiten, bei denen die Cache-Hit-Rate niedrig ist (unter 80%), untersuchen Sie:
“php add_filter('fieldforge/cache/expiration', function($seconds) { return DAY_IN_SECONDS; // Cache für 24 Stunden }); “
“php add_filter('fieldforge/cache/should_cache', function($should_cache, $field_group) { if ($field_group === 'frequently-changing-group') { return false; } return $should_cache; }, 10, 2); “
“php add_action('fieldforge/cache/invalidate', function($post_id, $field_name) { // Auch verwandte Daten invalidieren wp_cache_delete("my_custom_cache:{$post_id}", 'my_plugin'); }, 10, 2); “
Field Forge erhalten — ab $35/Jahr →
Die Integration des Objekt-Caches und das Batch-Laden sind in jeder Version von Field Forge enthalten, einschließlich der kostenlosen.