Die wp_postmeta-Tabelle von WordPress ist ein generischer Schlüssel-Wert-Speicher, der an jeden Beitrag angehängt ist. So werden post_title, post_content und custom_field_x gespeichert. Das Schema sieht folgendermaßen aus:
“sql CREATE TABLE wp_postmeta ( meta_id BIGINT(20) PRIMARY KEY, post_id BIGINT(20), meta_key VARCHAR(255), meta_value LONGTEXT, INDEX (post_id), INDEX (meta_key(191)) ); “
Einfach. Flexibel. Funktioniert für jedes Schlüssel-Wert-Paar. Und auf einer typischen pluginlastigen WordPress-Seite ist es enorm — leicht mehrere Millionen Zeilen auf einer 5 Jahre alten E-Commerce-Seite mit vielen Bestellungen und Produktmetadaten.
So läuft es, wenn Sie eine Archivseite mit 20 Beiträgen laden, von denen jeder 10 benutzerdefinierte Felder hat:
“`sql — Abfrage 1: Beiträge abrufen SELECT * FROM wp_posts WHERE post_type = ‘post’ LIMIT 20;
— Abfragen 2-201: Für jeden Beitrag jedes Feld abrufen SELECT meta_value FROM wp_postmeta WHERE post_id = 1 AND meta_key = ‘field_a’; SELECT meta_value FROM wp_postmeta WHERE post_id = 1 AND meta_key = ‘field_b’; — … 198 weitere Abfragen “`
200 separate Abfragen. Jede Abfrage ist einzeln schnell, aber die Round-Trip-Überhead summiert sich. Auf Seiten, die über ein Netzwerk auf die Datenbank zugreifen (häufig bei verwaltetem Hosting), kann dies zu über 500 ms bei jedem Seitenaufruf führen. Der kumulative Layoutverschiebung steigt. Die Core Web Vitals sinken. SEO leidet.
Wiederholungsfelder in ACF werden mit einer Metazeile pro Unterfeld pro Zeile gespeichert. Ein Wiederholungsfeld mit 5 Unterfeldern und 10 Zeilen erstellt 50 Metaeinträge pro Beitrag. Fügen Sie 20 Beiträge zu einem Archiv hinzu und Sie haben über 1.000 Metaanfragen bei einem einzigen Seitenaufruf. Deshalb verlangsamen sich ACF-lastige Seiten notorisch über einen bestimmten Maßstab hinaus.
Field Forge speichert Feldwerte in einer speziellen wp_fieldforge_values-Tabelle:
“sql CREATE TABLE wp_fieldforge_values ( id BIGINT(20) PRIMARY KEY, post_id BIGINT(20) NOT NULL, field_group_id BIGINT(20) NOT NULL, field_name VARCHAR(255) NOT NULL, parent_id BIGINT(20) NULL, -- für verschachtelte Werte (Wiederholer/Gruppe/Flex) row_index INT NULL, -- für die Position der Wiederholungszeile value LONGTEXT, INDEX (post_id, field_name), INDEX (post_id, field_group_id), INDEX (parent_id, row_index) ); “
Wesentliche Unterschiede zu wp_postmeta:
parent_id, row_index) — verschachtelte Werte (Wiederholer, Gruppe, Flex) sind strukturiert, nicht als Zeichenfolgen verkettetwp_postmeta schreiben, verschmutzen die Felddaten nichtwp_postmeta ist es nichtWir haben kontrollierte Benchmarks auf einer Testseite mit 10.000 Beiträgen durchgeführt, von denen jeder eine Feldgruppe mit 15 Feldern enthält (3 Text, 2 WYSIWYG, 1 Bild, 1 Wiederholer mit 5 Unterfeldern, 1 flexibler Inhalt mit 3 Layouttypen).
| wp_postmeta (ACF / SCF) | Field Forge benutzerdefinierte Tabelle | |
|---|---|---|
| SQL-Abfragen | 302 | 1 (batch_load) |
| Abfragezeit (lokale DB) | 840ms | 95ms |
| Abfragezeit (Netzwerk-DB, +20ms RTT) | 6.880ms | 115ms |
| First Contentful Paint | 2.100ms | 340ms |
| wp_postmeta | Field Forge | |
|---|---|---|
| SQL-Abfragen | 16 | 1 |
| Abfragezeit (lokale DB) | 45ms | 12ms |
| Abfragezeit (Netzwerk-DB, +20ms RTT) | 365ms | 32ms |
| wp_postmeta | Field Forge | |
|---|---|---|
| SQL-Abfragen | 1.000 INSERTs | 1 Multi-Row INSERT |
| Zeit (lokale DB) | 1.240ms | 48ms |
| Zeit (Netzwerk-DB) | 21.240ms | 68ms |
Bei netzwerkgebundenen Datenbanken (was bei fast allen verwalteten WordPress-Hosting-Anbietern der Fall ist — Kinsta, WP Engine, Cloudways, SiteGround Cloud usw.) ist der Unterschied dramatisch. Die Round-Trip-Latenz ist die dominierende Kostenstelle, und Field Forge benötigt weniger Round Trips.
Entwicklerorientierte API für explizites Batch-Laden, wenn das automatische Vorladen von Field Forge nicht ausreicht:
“`php // Felder für eine bestimmte Gruppe von Beiträgen in einer Abfrage laden $post_ids = [1, 2, 3, 4, 5]; FieldForge::batch_load($post_ids);
// Jetzt trifft jeder get_field()-Aufruf auf diesen Beiträgen den Cache foreach ($post_ids as $id) { $hero = get_field(‘hero_title’, $id); // Keine DB-Abfrage } “`
Der batch_load()-Aufruf gibt eine einzelne WHERE post_id IN (...)-Abfrage aus und füllt den In-Memory-Cache von Field Forge für alle angeforderten Beiträge. Nachfolgende get_field()-Aufrufe sind Cache-Treffer.
Field Forge integriert sich in den the_posts-Filter von WordPress, um Felder für die Hauptabfrage automatisch vorzuladen. Archivseiten, Suchergebnisse und Kategorielisten erhalten automatisch die Batch-geladenen Felddaten — keine Codeänderungen erforderlich.
Field Forge respektiert die wp_cache_*-API von WordPress:
fieldforge), sodass es nicht mit anderen Plugins oder Kern-Cache-Operationen in Konflikt gerät.Die Cache-Invalidierung erfolgt automatisch bei der Aktualisierung oder dem Löschen von Feldwerten über Aktions-Hooks.
Schnellere Archivseiten, schnellere Suchergebnisse, schnellere dynamische Vorlagen. Die Core Web Vitals verbessern sich. Die Kundenbindung verbessert sich, weil die Seite “flüssig” wirkt.
Produktlistenseiten mit 30+ Produkten und komplexen benutzerdefinierten Feldern werden in der gleichen Zeit gerendert wie einfachere Seiten. Interaktionen im Warenkorb sind schneller, da die Produktmetadaten in Chargen geladen werden.
REST API- und WPGraphQL-Antworten sind schneller. Statische Site-Generatoren (Next.js ISR, Astro, Nuxt) führen weniger Datenbankabfragen pro Build durch. Die Build-Zeiten verbessern sich.
Die ACF-Kompatibilitätsschicht von Field Forge bedeutet, dass get_field()-Aufrufe in Ihrem Theme die gleichen Werte zurückgeben — aber sie stammen aus der benutzerdefinierten Tabelle, nicht aus wp_postmeta. Der Leistungsgewinn erfolgt transparent nach der Migration.
Um fair zu sein: Wenn Ihre Seite weniger als 500 Beiträge und einfache benutzerdefinierte Felder hat (keine tiefen Wiederholer, kein flexibler Inhalt), funktioniert der Ansatz von wp_postmeta. Sie werden keinen Geschwindigkeitsunterschied bemerken. Der Leistungsunterschied von Field Forge wird bei größeren Maßstäben — 1.000+ Beiträgen, komplexen Wiederholern oder Seiten auf netzwerkgebundenen Datenbanken — bedeutend.
Erhalten Sie Field Forge — ab $35/Jahr →
Die benutzerdefinierte Tabellenablage ist in jeder Version von Field Forge enthalten, einschließlich der kostenlosen.