La table wp_postmeta de WordPress est un magasin de clés-valeurs générique attaché à chaque publication. C’est ainsi que post_title vs post_content vs custom_field_x sont tous stockés. Le schéma ressemble à ceci :
“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)) ); “
Simple. Flexible. Fonctionne pour n’importe quelle paire clé-valeur. Et sur un site WordPress typiquement chargé de plugins, c’est énorme — facilement des millions de lignes sur un site e-commerce vieux de 5 ans avec beaucoup de commandes et de méta-produits.
Voici ce qui se passe lorsque vous chargez une page d’archive avec 20 publications, chacune ayant 10 champs personnalisés :
“`sql — Requête 1 : Récupérer les publications SELECT * FROM wp_posts WHERE post_type = ‘post’ LIMIT 20;
— Requêtes 2-201 : Pour chaque publication, récupérer chaque champ 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 autres requêtes “`
200 requêtes séparées. Chaque requête est rapide individuellement, mais le coût de l’aller-retour s’accumule. Sur les sites qui accèdent à la base de données via un réseau (commun avec l’hébergement géré), cela peut ajouter plus de 500 ms à chaque vue de page. Le décalage de mise en page cumulatif augmente. Les Core Web Vitals chutent. Le SEO en souffre.
Les champs répéteurs dans ACF sont stockés avec une ligne méta par sous-champ par ligne. Un répéteur avec 5 sous-champs et 10 lignes crée 50 entrées méta par publication. Ajoutez 20 publications à une archive et vous regardez plus de 1 000 requêtes méta sur une seule vue de page. C’est pourquoi les sites chargés d’ACF ralentissent notoirement au-delà d’une certaine échelle.
Field Forge stocke les valeurs des champs dans une table dédiée wp_fieldforge_values :
“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, -- pour les valeurs imbriquées (répéteur/groupe/flex) row_index INT NULL, -- pour la position de ligne du répéteur value LONGTEXT, INDEX (post_id, field_name), INDEX (post_id, field_group_id), INDEX (parent_id, row_index) ); “
Différences clés par rapport à wp_postmeta :
parent_id, row_index) — les valeurs imbriquées (répéteur, groupe, flex) sont structurées, pas concaténées en chaînewp_postmeta ne polluent pas les données de champwp_postmeta ne l’est pasNous avons réalisé des benchmarks contrôlés sur un site de test avec 10 000 publications, chacune avec un groupe de champs contenant 15 champs (3 texte, 2 WYSIWYG, 1 image, 1 répéteur avec 5 sous-champs, 1 contenu flexible avec 3 types de mise en page).
| wp_postmeta (ACF / SCF) | Table personnalisée Field Forge | |
|---|---|---|
| Requêtes SQL | 302 | 1 (batch_load) |
| Temps de requête (DB local) | 840ms | 95ms |
| Temps de requête (DB réseau, +20ms RTT) | 6 880ms | 115ms |
| Premier Peinture de Contenu | 2 100ms | 340ms |
| wp_postmeta | Field Forge | |
|---|---|---|
| Requêtes SQL | 16 | 1 |
| Temps de requête (DB local) | 45ms | 12ms |
| Temps de requête (DB réseau, +20ms RTT) | 365ms | 32ms |
| wp_postmeta | Field Forge | |
|---|---|---|
| Requêtes SQL | 1 000 INSERTs | 1 INSERT multi-lignes |
| Temps (DB local) | 1 240ms | 48ms |
| Temps (DB réseau) | 21 240ms | 68ms |
Sur les bases de données connectées au réseau (qui est la façon dont presque tous les hébergements WordPress gérés fonctionnent — Kinsta, WP Engine, Cloudways, SiteGround Cloud, etc.), la différence est dramatique. La latence d’aller-retour est le coût dominant, et Field Forge effectue moins d’allers-retours.
API destinée aux développeurs pour un chargement par lots explicite lorsque le préchargement automatique de Field Forge n’est pas suffisant :
“`php // Charger les champs pour un ensemble spécifique de publications en une seule requête $post_ids = [1, 2, 3, 4, 5]; FieldForge::batch_load($post_ids);
// Maintenant, tout appel à get_field() sur ces publications touche le cache foreach ($post_ids as $id) { $hero = get_field(‘hero_title’, $id); // Pas de requête DB } “`
L’appel batch_load() émet une seule requête WHERE post_id IN (...) et remplit le cache en mémoire de Field Forge pour toutes les publications demandées. Les appels get_field() suivants sont des hits de cache.
Field Forge s’intègre au filtre the_posts de WordPress pour précharger automatiquement les champs pour la requête principale. Les pages d’archive, les résultats de recherche et les listes de catégories obtiennent automatiquement les données de champ chargées par lots — aucune modification de code requise.
Field Forge respecte l’API wp_cache_* de WordPress :
fieldforge) afin de ne pas entrer en conflit avec d’autres plugins ou opérations de cache de base.L’invalidation du cache se produit automatiquement lors de la mise à jour ou de la suppression de la valeur du champ via des hooks d’action.
Des pages d’archive plus rapides, des résultats de recherche plus rapides, des modèles dynamiques plus rapides. Les Core Web Vitals s’améliorent. La fidélisation des clients s’améliore car le site “semble réactif”.
Les pages de liste de produits avec 30+ produits et des champs personnalisés complexes se rendent dans le même temps que des sites plus simples. Les interactions avec le panier d’achat sont plus rapides car les chargements de méta-produits sont regroupés.
Les réponses de l’API REST et de WPGraphQL sont plus rapides. Les générateurs de sites statiques (Next.js ISR, Astro, Nuxt) effectuent moins de requêtes de base de données par build. Les temps de construction s’améliorent.
La couche de compatibilité ACF de Field Forge signifie que les appels get_field() dans votre thème renvoient les mêmes valeurs — mais elles proviennent de la table personnalisée, pas de wp_postmeta. L’amélioration des performances se produit de manière transparente après la migration.
Pour être juste : si votre site a moins de 500 publications et des champs personnalisés simples (pas de répéteurs profonds, pas de contenu flexible), l’approche wp_postmeta fonctionne. Vous ne remarquerez pas de différence de vitesse. L’avantage de performance de Field Forge devient significatif à grande échelle — 1 000+ publications, répéteurs complexes, ou sites sur des bases de données connectées au réseau.
Obtenez Field Forge — à partir de 35$/an →
Le stockage de table personnalisée est inclus dans chaque version de Field Forge, y compris la version gratuite.