{"id":17700,"date":"2026-02-15T18:21:01","date_gmt":"2026-02-15T17:21:01","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-custom-post-types-langsamkeit-optimierung-cacheboost\/"},"modified":"2026-02-15T18:21:01","modified_gmt":"2026-02-15T17:21:01","slug":"wordpress-custom-post-types-optimisation-de-la-lenteur-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/wordpress-custom-post-types-langsamkeit-optimierung-cacheboost\/","title":{"rendered":"Pourquoi WordPress est plus lent avec beaucoup de Custom Post Types"},"content":{"rendered":"<p>De nombreux types de messages personnalis\u00e9s ralentissent WordPress, car chaque requ\u00eate est en plus accompagn\u00e9e de <strong>M\u00e9tadonn\u00e9es<\/strong> et les taxonomies, ce qui entra\u00eene davantage de jointures, de balayages et de tris. Je vais montrer pourquoi cela se produit et comment <strong>Performance<\/strong> en prenant des mesures simples et v\u00e9rifiables.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<p>Je r\u00e9sume d'abord les points cl\u00e9s suivants.<\/p>\n<ul>\n  <li><strong>Mod\u00e8le de donn\u00e9es<\/strong>: Un tableau wp_posts pour tous les types entra\u00eene des jointures \u00e9paisses pour de nombreux champs Meta.<\/li>\n  <li><strong>Requ\u00eates<\/strong>: Les mod\u00e8les meta_query et tax_query non cibl\u00e9s co\u00fbtent du temps et de la RAM.<\/li>\n  <li><strong>Indices<\/strong>: Les cl\u00e9s manquantes sur wp_postmeta et les tableaux de termes allongent les temps de r\u00e9ponse.<\/li>\n  <li><strong>Mise en cache<\/strong>: les caches de pages, d'objets et de requ\u00eates att\u00e9nuent nettement les pics de charge.<\/li>\n  <li><strong>Cabinet m\u00e9dical<\/strong>: moins de champs, des templates propres, des WP_Query cibl\u00e9s et un bon h\u00e9bergement.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-langsame-posttypes-9372.png\" alt=\"Temps de chargement lent dans WordPress avec de nombreux types de messages personnalis\u00e9s\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pourquoi de nombreux types de custom post freinent<\/h2>\n\n<p>WordPress enregistre tout le contenu, y compris <strong>Personnalis\u00e9<\/strong> Post Types, dans wp_posts et ne les distingue que par le champ post_type. Cela semble simple, mais cr\u00e9e une pression sur la base de donn\u00e9es d\u00e8s que j'int\u00e8gre beaucoup de champs m\u00e9ta et de taxonomies. Chaque WP_Query doit alors passer par wp_postmeta et les trois tableaux de termes, ce qui augmente le nombre de comparaisons et de tris. Si certains types augmentent fortement, par exemple un grand stock de produits ou de cam\u00e9ras, le temps de r\u00e9ponse bascule d'abord dans les archives et les recherches. Je le reconnais au fait que la m\u00eame page se charge plus rapidement avec moins de champs, tandis que les ensembles de donn\u00e9es denses avec de nombreux filtres <strong>Latence<\/strong> \u00e0 la hausse.<\/p>\n\n<h2>Comment WordPress organise les donn\u00e9es en interne<\/h2>\n\n<p>Le champ s\u00e9lectionn\u00e9 <strong>post_type<\/strong> dans wp_posts est index\u00e9 et rend les requ\u00eates simples rapides, mais la musique se joue dans wp_postmeta. Chaque champ personnalis\u00e9 atterrit dans ce tableau comme une entr\u00e9e s\u00e9par\u00e9e et multiplie les lignes par post. Si une publication poss\u00e8de 100 champs, il en r\u00e9sulte 100 enregistrements suppl\u00e9mentaires que chaque meta_query doit examiner. \u00c0 cela s'ajoutent les tableaux de taxonomie wp_terms, wp_term_taxonomy et wp_term_relationships, que j'int\u00e8gre pour les archives, les filtres et les facettes. Si le nombre de jointures augmente, le temps CPU et la consommation de m\u00e9moire augmentent \u00e9galement, ce que je constate imm\u00e9diatement dans Top, htop et Query-Monitor \u00e0 la <strong>Taux d'occupation<\/strong> voir.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_speed_meeting_7283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Reconna\u00eetre les mod\u00e8les SQL co\u00fbteux<\/h2>\n\n<p>Je v\u00e9rifie d'abord les \u00e9chantillons chers, car c'est l\u00e0 que se trouvent les gros b\u00e9n\u00e9fices pour <strong>Performance<\/strong>. Les meta_query avec plusieurs conditions et les comparaisons LIKE sur meta_value deviennent particuli\u00e8rement critiques, car elles ne rencontrent souvent pas d'index. De m\u00eame, les tax_query larges avec plusieurs relations prolongent le temps n\u00e9cessaire \u00e0 MySQL pour trouver un plan d'ex\u00e9cution appropri\u00e9. Je limite les champs, normalise les valeurs et garde les comparaisons aussi pr\u00e9cises que possible pour que les index fonctionnent. Le tableau suivant m'aide \u00e0 classer les bottlenecks fr\u00e9quents et leur alternative :<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Pattern<\/th>\n      <th>Co\u00fbts typiques<\/th>\n      <th>Sympt\u00f4me<\/th>\n      <th>Meilleure option<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>meta_query avec LIKE sur meta_value<\/td>\n      <td>\u00e9lev\u00e9 sans <strong>Index<\/strong><\/td>\n      <td>temps de requ\u00eate long, CPU \u00e9lev\u00e9<\/td>\n      <td>utiliser des valeurs exactes, des colonnes normalis\u00e9es, INT\/DECIMAL<\/td>\n    <\/tr>\n    <tr>\n      <td>tax_query avec plusieurs relations (AND)<\/td>\n      <td>moyen \u00e0 \u00e9lev\u00e9<\/td>\n      <td>Les archives sont lentes, la pagination est lente<\/td>\n      <td>Mise en cache de la facette, pr\u00e9filtre dans son propre index<\/td>\n    <\/tr>\n    <tr>\n      <td>posts_per_page = -1<\/td>\n      <td>tr\u00e8s \u00e9lev\u00e9 pour les grands types<\/td>\n      <td>La m\u00e9moire se remplit<\/td>\n      <td>Pagination, curseurs, listes asynchrones<\/td>\n    <\/tr>\n    <tr>\n      <td>ORDER BY meta_value sans cast<\/td>\n      <td>\u00e9lev\u00e9<\/td>\n      <td>Le tri est lent<\/td>\n      <td>champs num\u00e9riques, colonne s\u00e9par\u00e9e, tri pr\u00e9-agr\u00e9g\u00e9<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>L'influence des champs personnalis\u00e9s sur wp_postmeta<\/h2>\n\n<p>J'ai vu des configurations dans lesquelles des centaines de <strong>Champs<\/strong> par article et que la table post-meta a augment\u00e9 de plusieurs gigaoctets. Dans de tels cas, le nombre de lignes que MySQL doit analyser explose et m\u00eame les filtres simples tr\u00e9buchent. Les champs qui sont en fait num\u00e9riques, mais qui sont enregistr\u00e9s sous forme de texte, sont critiques, car les comparaisons et le tri sont alors plus co\u00fbteux. J'externalise les donn\u00e9es rarement utilis\u00e9es, je r\u00e9duis les champs obligatoires au strict n\u00e9cessaire et j'utilise les champs r\u00e9p\u00e9titeurs avec parcimonie. Les tableaux restent ainsi plus \u00e9troits et les planificateurs de requ\u00eates trouvent plus rapidement le chemin d'acc\u00e8s appropri\u00e9.<\/p>\n\n<h2>rationaliser de mani\u00e8re cibl\u00e9e les taxonomies, les flux et les archives<\/h2>\n\n<p>Les taxinomies sont fortes, mais je les place <strong>cibl\u00e9<\/strong> sinon je vais surcharger inutilement chaque page d'archives. Les flux et les archives globales ne devraient pas m\u00e9langer tous les types de messages si un seul est pertinent. Je contr\u00f4le cela via pre_get_posts et j'exclus les types de messages qui n'ont rien \u00e0 faire l\u00e0. Les pages de recherche profitent \u00e9galement de l'exclusion des types inappropri\u00e9s ou de la cr\u00e9ation de mod\u00e8les de recherche s\u00e9par\u00e9s. Si la base de donn\u00e9es pr\u00e9sente une charge de lecture \u00e9lev\u00e9e, je r\u00e9duis le nombre de tables de jointure et je mets en m\u00e9moire tampon les vues d'archives fr\u00e9quentes dans le cache des objets.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-custompost-slowdown-3941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Des strat\u00e9gies de mise en cache qui portent vraiment leurs fruits<\/h2>\n\n<p>Je combine <strong>Cache de page<\/strong>, Cache d'objets et Transients, pour \u00e9viter l'ex\u00e9cution de requ\u00eates co\u00fbteuses. Le cache de page intercepte les visiteurs anonymes et soulage imm\u00e9diatement PHP et MySQL. Le cache d'objets (par ex. Redis ou Memcached) conserve les r\u00e9sultats de WP_Query, les termes et les options et permet d'\u00e9conomiser des allers-retours. Pour les filtres, les facettes et les m\u00e9ta-requ\u00eates co\u00fbteuses, j'utilise des transients avec des r\u00e8gles d'invalidation propres. Ainsi, m\u00eame les grandes archives restent rapides, m\u00eame si certains Custom Post Types poss\u00e8dent des dizaines de milliers d'entr\u00e9es.<\/p>\n\n<h2>D\u00e9finir des index et g\u00e9rer la base de donn\u00e9es<\/h2>\n\n<p>Sans <strong>Indices<\/strong> chaque r\u00e9glage agit comme une goutte d'eau dans l'oc\u00e9an. J'ajoute des cl\u00e9s sur wp_postmeta pour (post_id, meta_key), souvent aussi (meta_key, meta_value) selon l'utilisation. Pour les relations de terme, je v\u00e9rifie les cl\u00e9s pour (object_id, term_taxonomy_id) et je nettoie r\u00e9guli\u00e8rement les relations orphelines. Ensuite, je contr\u00f4le avec EXPLAIN si MySQL utilise vraiment les index et si le tri par filesort dispara\u00eet. Pour une introduction structur\u00e9e \u00e0 ce sujet, je vous invite \u00e0 lire ce billet sur <a href=\"https:\/\/webhosting.de\/fr\/wordpress-wordpress-base-de-donnees-indices-performance-boost-optimise\/\">Index des bases de donn\u00e9es<\/a>Je l'utilise comme liste de contr\u00f4le.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_custom_types_8742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De bonnes habitudes de recherche plut\u00f4t que des extraits complets<\/h2>\n\n<p>J'utilise WP_Query avec des <strong>Filtrer<\/strong> et j'\u00e9vite posts_per_page = -1, car cela fait tourner la m\u00e9moire et le processeur de mani\u00e8re exponentielle. Au lieu de cela, je pagine durement, j'utilise un ordre stable et je ne fournis que les colonnes dont j'ai vraiment besoin. Pour les pages de renvoi, je tire des teasers avec peu de champs que je pr\u00e9-agr\u00e9ge ou que je mets en cache. En outre, je v\u00e9rifie les r\u00e8gles de r\u00e9\u00e9criture, car un mauvais routage d\u00e9clenche des occurrences inutiles dans la base de donn\u00e9es. <a href=\"https:\/\/webhosting.de\/fr\/wordpress-rewrite-rules-performance-frein-routing-optimizer\/\">Les r\u00e8gles de r\u00e9\u00e9criture comme frein<\/a> me permet souvent d'\u00e9conomiser plusieurs millisecondes par requ\u00eate. En s\u00e9parant la recherche, les archives et les flux et en utilisant des requ\u00eates appropri\u00e9es, on r\u00e9duit sensiblement la charge.<\/p>\n\n<h2>Garder les outils, les plugins et la conception des champs l\u00e9gers<\/h2>\n\n<p>Les plugins pour les champs et les types de messages offrent beaucoup, mais j'examine leurs <strong>Overhead<\/strong> avec Query Monitor et New Relic. Si un CPT utilise des centaines de champs, je divise le mod\u00e8le de donn\u00e9es et j'externalise les groupes rarement utilis\u00e9s. Tous les champs n'ont pas leur place dans wp_postmeta ; certaines donn\u00e9es sont conserv\u00e9es dans des tables s\u00e9par\u00e9es avec des index clairs. J'\u00e9vite les hi\u00e9rarchies inutiles dans les post-types, car elles alourdissent les arborescences et les requ\u00eates. Des mod\u00e8les propres (single-xyz.php, archive-xyz.php) et des boucles \u00e9conomes permettent de r\u00e9duire les temps de rendu.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_custompost_slow_4927.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>H\u00e9bergement et WP scaling dans la pratique<\/h2>\n\n<p>A partir d'une certaine taille, on <strong>WP scaling<\/strong> sur la question de l'infrastructure. J'utilise beaucoup de RAM, un stockage NVMe rapide et j'active le cache d'objet persistant pour que WordPress ne se recharge pas constamment. Une configuration de mise en cache au niveau du serveur plus PHP-FPM avec un nombre de processus adapt\u00e9 permet de planifier les temps de r\u00e9ponse. Ceux qui misent fortement sur les Custom Post Types profitent d'un h\u00e9bergement avec Redis int\u00e9gr\u00e9 et OpCache-Warmup. Pour l'h\u00e9bergement de wordpress, je veille \u00e0 ce que la plateforme amortisse les pics de charge par le biais de la mise en file d'attente et de l'Edge Cache.<\/p>\n\n<h2>Utiliser efficacement la recherche, les flux et l'API REST<\/h2>\n\n<p>La recherche et l'API REST ressemblent \u00e0 de petits <strong>D\u00e9tails<\/strong>, Mais ils g\u00e9n\u00e8rent beaucoup de requ\u00eates par session. Je limite les points de terminaison, je mets en cache les r\u00e9ponses et j'utilise des requ\u00eates conditionnelles pour que les clients ne retirent pas tout. Pour l'API REST, je minimise les champs dans le sch\u00e9ma, je filtre strictement les types de messages et j'active les ETags. Si des frontaux headless sont en cours d'ex\u00e9cution, il vaut la peine de mettre en place une strat\u00e9gie de cache sp\u00e9cifique par CPT et par route ; j'en ai un aper\u00e7u pratique ici : <a href=\"https:\/\/webhosting.de\/fr\/wordpress-rest-api-optimisation-des-performances-perfboost\/\">Performance de l'API REST<\/a>. Les flux RSS\/Atom sont courts et j'exclue les types inutiles, sinon les robots d'indexation en r\u00e9cup\u00e8rent trop.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-performance-6147.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Options WP_Query qui aident imm\u00e9diatement<\/h2>\n\n<p>Je r\u00e9sous de nombreux freins avec quelques param\u00e8tres bien cibl\u00e9s dans WP_Query. Ils r\u00e9duisent la quantit\u00e9 de donn\u00e9es, \u00e9vitent des comptages co\u00fbteux et \u00e9conomisent la bande passante du cache.<\/p>\n<ul>\n  <li><strong>no_found_rows = true<\/strong>: d\u00e9sactive le comptage total pour la pagination. Id\u00e9al pour les widgets, les teasers et les listes REST qui n'affichent pas le nombre total de pages.<\/li>\n  <li><strong>champs = \u201aids\u2018<\/strong>: ne fournit que des ID et \u00e9vite de construire des objets postaux complets. Ensuite, je r\u00e9cup\u00e8re des m\u00e9tadonn\u00e9es cibl\u00e9es en une seule fois (m\u00e9ta-cache-priming).<\/li>\n  <li><strong>update_post_meta_cache = false<\/strong> et <strong>update_post_term_cache = false<\/strong>: permet d'\u00e9conomiser la mise en cache si je n'ai pas besoin de m\u00e9tas\/terms dans cette requ\u00eate.<\/li>\n  <li><strong>ignore_sticky_posts = true<\/strong>: Emp\u00eache une logique de tri suppl\u00e9mentaire dans les archives qui ne b\u00e9n\u00e9ficient pas de Sticky Posts.<\/li>\n  <li><strong>orderby<\/strong> et <strong>order<\/strong> choisir de mani\u00e8re d\u00e9terministe : \u00c9vite les tris co\u00fbteux et les caches instables, en particulier pour les CPT de grande taille.<\/li>\n<\/ul>\n<p>Ces commutateurs permettent souvent d'obtenir des pourcentages \u00e0 deux chiffres sans modifier la sortie. Il est important de les d\u00e9finir par mod\u00e8le et par utilisation, et non globalement.<\/p>\n\n<h2>Acc\u00e9l\u00e9rer le backend et les listes d'administration<\/h2>\n\n<p>Les grands types de messages ne ralentissent pas seulement le frontend, mais aussi le backend. Je fais les <strong>Vue en liste<\/strong> plus rapidement en r\u00e9duisant les colonnes et les filtres au strict n\u00e9cessaire. Les compteurs pour les taxonomies et la corbeille prennent du temps dans les grands tableaux ; je d\u00e9sactive les compteurs inutiles et j'utilise des filtres compacts. En outre, je limite le nombre d'entr\u00e9es visibles par page afin que la requ\u00eate admin ne soit pas limit\u00e9e en m\u00e9moire. Avec pre_get_posts, je diff\u00e9rencie le frontend et l'admin, j'y d\u00e9finis d'autres param\u00e8tres (par ex. no_found_rows) et j'emp\u00eache les meta_query larges dans l'aper\u00e7u. R\u00e9sultat : des flux de travail plus rapides pour les r\u00e9dacteurs et moins de risques de timeout.<\/p>\n\n<h2>Mat\u00e9rialisation : des valeurs pr\u00e9calcul\u00e9es plut\u00f4t que des filtres de dur\u00e9e co\u00fbteux<\/h2>\n\n<p>Si les m\u00eames <strong>Filtre<\/strong> et les tris reviennent souvent, je mat\u00e9rialise les champs dans une table de recherche sp\u00e9cifique. Exemple : un CPT de produits trie souvent par prix et filtre par disponibilit\u00e9. Je conserve pour cela une table avec post_id, prix DECIMAL, disponible TINYINT et les index correspondants. Lors de l'enregistrement, je mets \u00e0 jour ces valeurs ; dans le frontend, j'y acc\u00e8de directement et r\u00e9cup\u00e8re les post-id. Ensuite, WP_Query se contente de r\u00e9soudre la quantit\u00e9 d'ID en messages. Cela r\u00e9duit consid\u00e9rablement la charge sur wp_postmeta et rend l'ORDER BY \u00e0 nouveau avantageux sur les colonnes num\u00e9riques.<\/p>\n\n<h2>Typage des donn\u00e9es et colonnes g\u00e9n\u00e9r\u00e9es<\/h2>\n\n<p>De nombreux champs m\u00e9ta se pr\u00e9sentent sous forme de LONGTEXT dans meta_value - <strong>non indexable<\/strong> et cher. J'utilise deux mod\u00e8les : premi\u00e8rement, des champs miroirs typ\u00e9s (par ex. prix_num comme DECIMAL), sur lesquels j'indexe et je compare. Deuxi\u00e8mement, <strong>Colonnes g\u00e9n\u00e9r\u00e9es<\/strong> dans MySQL, qui fournissent un extrait ou un cast de meta_value et le rendent indexable. Ces deux \u00e9l\u00e9ments font en sorte que les cas LIKE disparaissent et que les comparaisons reviennent sur les index. Outre la vitesse des requ\u00eates, cela am\u00e9liore \u00e9galement la planification de la pertinence des caches, car le tri et le filtre sont d\u00e9terministes.<\/p>\n\n<h2>R\u00e9vision, autoload et nettoyage<\/h2>\n\n<p>Outre les requ\u00eates elles-m\u00eames, les <strong>D\u00e9chets de donn\u00e9es<\/strong>. Je limite les r\u00e9visions, je supprime les anciens autoloads et je vide r\u00e9guli\u00e8rement la corbeille pour \u00e9viter que les tables ne se d\u00e9veloppent ind\u00e9finiment. Dans wp_options, je v\u00e9rifie le stock d'autoloads : trop d'options autoload\u00e9es allongent chaque requ\u00eate, ind\u00e9pendamment des CPT. Je nettoie les postmetas et les relations de terme orphelines, je supprime les taxonomies inutilis\u00e9es et j'all\u00e8ge les t\u00e2ches Cron qui effectuent de grandes recherches. Cette hygi\u00e8ne assure des plans stables de l'optimiseur de requ\u00eates et emp\u00eache les index de perdre en efficacit\u00e9.<\/p>\n\n<h2>Surveillance et m\u00e9thodologie de mesure<\/h2>\n\n<p>Sans <strong>salons<\/strong> reste de l'optimisation \u00e0 l'aveugle. J'utilise Query Monitor pour la partie PHP, EXPLAIN et EXPLAIN ANALYZE pour MySQL, ainsi que le Slow-Query-Log avec des seuils proches de la pratique. Je regarde les indicateurs tels que Rows Examined, Handler Read Key\/Firts, Sorts per Filesort et Temp Tables on Disk. Je contr\u00f4le sous charge avec des quantit\u00e9s de donn\u00e9es r\u00e9alistes, afin que les ch\u00e2teaux de cartes ne se r\u00e9v\u00e8lent pas seulement lors de l'exploitation en direct. Je documente chaque modification avec un instantan\u00e9 avant\/apr\u00e8s ; les mesures deviennent ainsi une liste de contr\u00f4le fiable que je transf\u00e8re \u00e0 de nouveaux projets CPT.<\/p>\n\n<h2>Conception coh\u00e9rente de la m\u00e9moire cache : Invalidation et Warmup<\/h2>\n\n<p>Le cache n'aide que si <strong>invalidation<\/strong> est vrai. Pour les archives et les facettes, je d\u00e9finis des cl\u00e9s qui n'expirent qu'en cas de modifications pertinentes - par exemple lors du changement d'une disponibilit\u00e9 ou d'un prix. Je regroupe les invalidations dans des hooks (save_post, updated_post_meta) pour \u00e9viter que toute la page ne refroidisse. Apr\u00e8s les d\u00e9ploiements, je pr\u00e9chauffe les itin\u00e9raires fr\u00e9quents, les sitemaps et les archives. Au niveau de la p\u00e9riph\u00e9rie ou du cache du serveur, je d\u00e9finis des TTL variables par CPT afin que les chemins chauds restent plus longtemps, tandis que les listes rares re\u00e7oivent des TTL plus courts. En combinaison avec un cache d'objets persistant, les taux d'\u00e9chec restent pr\u00e9visibles.<\/p>\n\n<h2>Multisite, langue et relations<\/h2>\n\n<p>Installations avec plusieurs <strong>Sites<\/strong> ou les langues renforcent la charge de jointure, car des filtres suppl\u00e9mentaires entrent en jeu par contexte. C'est pourquoi j'isole si possible les grands CPT sur leurs propres sites et j'emp\u00eache les widgets globaux de parcourir tous les r\u00e9seaux. Pour les traductions, je maintiens des relations l\u00e9g\u00e8res entre l'original et la traduction et j'\u00e9vite les m\u00e9ta-champs redondants. Un typage coh\u00e9rent et un jeu de facettes uniforme par langue r\u00e9duisent sensiblement le nombre de requ\u00eates n\u00e9cessaires.<\/p>\n\n<h2>Contr\u00f4le des ressources et d\u00e9lais d'attente<\/h2>\n\n<p>Un parall\u00e9lisme \u00e9lev\u00e9 entra\u00eene, pour les grands CPT, des <strong>Verrouillage<\/strong> et saturent les E\/S. Je planifie les workers FPM de mani\u00e8re \u00e0 ce qu'ils correspondent au profil du CPU et des E\/S, et je limite les grandes requ\u00eates de listes simultan\u00e9es avec des limites de taux dans le front-end. Les processus par lots (r\u00e9indexation, importation) fonctionnent de mani\u00e8re d\u00e9coupl\u00e9e pendant les heures creuses afin d'\u00e9viter l'effondrement des caches. MySQL b\u00e9n\u00e9ficie de pools de tampons bien dimensionn\u00e9s et de p\u00e9riodes avec ANALYZE TABLE, afin que les statistiques restent \u00e0 jour et que l'optimiseur choisisse de meilleurs plans.<\/p>\n\n<h2>Strat\u00e9gies de d\u00e9ploiement pour les CPT de grande taille<\/h2>\n\n<p>Modifications structurelles des grands types de courrier je roule <strong>incr\u00e9mental<\/strong> en ligne. Je place les nouveaux index en ligne, je remplis les tables de mat\u00e9rialisation en parall\u00e8le et je ne commute les requ\u00eates que lorsqu'il y a suffisamment de donn\u00e9es. Pendant les migrations, je s\u00e9curise les caches avec des TTL plus longs, ce qui r\u00e9duit de moiti\u00e9 l'impression en direct. Les indicateurs de fonctionnalit\u00e9s permettent de faire des tests avec une partie du trafic. Il est important que je <em>Chemins de retour en arri\u00e8re<\/em> d\u00e9finir : les anciennes requ\u00eates peuvent prendre le relais \u00e0 court terme si n\u00e9cessaire, jusqu'\u00e0 ce que le nouvel itin\u00e9raire soit optimis\u00e9.<\/p>\n\n<h2>Avenir : Mod\u00e8les de contenu dans le noyau de WordPress<\/h2>\n\n<p>J'observe le travail sur les natifs <strong>Contenu<\/strong> Models, car ils rapprochent les d\u00e9finitions de champs du noyau. Une moindre d\u00e9pendance vis-\u00e0-vis des grands plug-ins de champs pourrait simplifier les chemins de requ\u00eate et rendre la mise en cache plus stable. Lorsque les types de champs sont clairement typ\u00e9s, les index sont plus efficaces et les tris sont plus avantageux. Cela est particuli\u00e8rement utile pour les archives qui poss\u00e8dent de nombreux filtres et qui d\u00e9pendent aujourd'hui fortement de wp_postmeta. En attendant, il vaut la peine de typer proprement les champs et de cr\u00e9er des valeurs num\u00e9riques sous forme d'INT\/DECIMAL.<\/p>\n\n<h2>Configuration de la pratique : Pas \u00e0 pas vers un site CPT rapide<\/h2>\n\n<p>Je commence toujours par <strong>salons<\/strong>: Query Monitor, Debug Bar, EXPLAIN et des quantit\u00e9s de donn\u00e9es r\u00e9alistes sur Staging. Ensuite, je mets en place un cache de page, j'active Redis et j'optimise les trois requ\u00eates les plus lentes avec des index ou une mat\u00e9rialisation. Dans un troisi\u00e8me temps, je r\u00e9duis les champs, remplace les listes -1 par la pagination et supprime les tris inutiles. Quatri\u00e8mement, j'\u00e9cris des archives d\u00e9di\u00e9es par CPT et je supprime les mod\u00e8les larges qui chargent trop. Enfin, je durcis l'API REST et les flux pour que les robots ne r\u00e9veillent pas la base de donn\u00e9es en permanence.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>Nombreux <strong>Personnalis\u00e9<\/strong> Les post-types ralentissent WordPress parce que les m\u00e9ta et les taxinomies chargent la base de donn\u00e9es. Je garde les requ\u00eates l\u00e9g\u00e8res, j'\u00e9tablis des index, je mets en cache les chemins les plus co\u00fbteux et je r\u00e9duis les champs au strict n\u00e9cessaire. Des templates propres, des filtres WP_Query clairs et un h\u00e9bergement adapt\u00e9 garantissent des temps de r\u00e9ponse constants. En rationalisant en plus les r\u00e8gles de r\u00e9\u00e9criture, l'API REST et les flux, on \u00e9conomise encore des millisecondes. Ainsi, m\u00eame une grande collection de Custom Post Types reste rapide, maintenable et pr\u00eate pour un futur WP scaling.<\/p>","protected":false},"excerpt":{"rendered":"<p>Pourquoi WordPress est plus lent avec beaucoup de custom post types : Causes, **wordpress custom post types performance**-conseils et **WP scaling** avec le meilleur **hosting wordpress**.<\/p>","protected":false},"author":1,"featured_media":17693,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-17700","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1105","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Custom Post Types","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"17693","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17700","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=17700"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17700\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/17693"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=17700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=17700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=17700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}