On te dira qu’un thème enfant, c’est la base d’un site WordPress bien construit. Techniquement, c’est vrai : il permet de modifier un thème parent sans perdre ses mises à jour. Mais sur le terrain, on voit surtout des thèmes enfants qui sabotent les Core Web Vitals sans que personne ne le mesure. Un functions.php qui importe une feuille de styles pour trois blocs Gutenberg jamais utilisés, une Google Font chargée sans font-display, un script de tracking injecté deux fois. Et le pire, c’est que le propriétaire du site croit avoir fait le nécessaire « parce que c’est un thème enfant propre ».
J’ai vu un site e-commerce passer d’un TTFB de 140 ms à 380 ms après l’activation d’un thème enfant « maison ». Le thème parent était GeneratePress, les pages volaient. Le functions.php du thème enfant contenait 350 lignes d’appels à wp_enqueue_scripts, la moitié exécutée sur toutes les pages, y compris les archives. On a nettoyé en conditionnant les hooks et en supprimant une librairie CSS redondante de 70 Ko. Le TTFB est redescendu à 160 ms. Cette histoire, elle se répète tous les mois.
Le mythe du thème enfant comme bouclier de performance
On associe souvent thème enfant et bonne pratique. À raison, pour la maintenance. Mais cette idée finit par devenir un cache-misère : on croit qu’on a optimisé parce qu’on surcharge proprement les templates, alors qu’on empile juste du code mort sur une base saine.
Un thème enfant n’hérite pas que des fichiers : il hérite aussi de la dette de performance du parent. Si le parent charge une police système déjà incluse dans le thème enfant, vous doublez la requête. Si le parent applique un render-blocking sur une feuille de styles que le thème enfant redéclare pour une nuance de couleur, le navigateur attend deux fois. On ne mesure presque jamais cet impact, car on ne teste pas le site sans le thème enfant. C’est pourtant la première chose à faire quand on traque un LCP anormalement haut : activer le parent seul, vider les caches, lancer un Lighthouse. L’écart vous donne le vrai coût du thème enfant.
En parlant de mesures, les outils modernes d’audit de performance, qu’on évoque par exemple dans notre guide sur l’optimisation des Core Web Vitals, montrent systématiquement que les chaînes de requêtes inutiles viennent des surcouches de personnalisation, pas du cœur du thème.
Pourquoi ton functions.php plombe le TTFB
Chaque add_action, chaque add_filter présent dans le functions.php s’exécute à chaque requête serveur, même quand la condition appelée ne sert à rien sur la page demandée. Sur un site qui affiche une landing page statique, un hook prévu pour la fiche produit tourne dans le vide. Résultat : le temps de traitement PHP avant le premier octet s’étire. On a mesuré des dégradations de 120 à 180 ms rien qu’en retirant les fonctions non conditionnées d’un thème enfant WooCommerce. C’est un TTFB qu’on attribue souvent au serveur ou à l’hébergeur, alors que le code PHP est le seul responsable.
CSS et JS : l’héritage qui coûte cher au LCP
La facilité du thème enfant, c’est de pouvoir ajouter des styles et des scripts rapidement. Le piège, c’est qu’on les ajoute souvent sur toutes les pages. Une feuille de styles de 20 Ko chargée sur la page d’accueil pour styliser une popup qui n’apparaît qu’au bout de trois scrolls, ça fait une ressource bloquante de plus dans le chemin critique du LCP. Idem pour un script jQuery appelé en wp_head alors que vous l’utilisez uniquement dans le footer d’un article de blog.
Ce qu’on voit dans les audits, c’est un enchevêtrement de @import dans le style.css du thème enfant, qui fait rebondir le navigateur entre plusieurs fichiers et retarde l’affichage de l’image LCP. Le parent charge une feuille principale, l’enfant en ajoute une deuxième pour les « ajustements », puis une troisième pour une librairie d’icônes. Le navigateur doit télécharger et parser ces trois ressources avant de pouvoir afficher le moindre pixel significatif. Résultat : un LCP à 3500 ms sur une page qui n’affiche qu’un titre et une image optimisée.
Ce qu’on a trouvé en testant un thème enfant « léger »
Prenons un site vitrine basé sur Astra, avec un thème enfant créé pour modifier les couleurs et les espacements. Le thème parent seul produisait un LCP à 1,6 s sur une connexion 4G throttled. Après activation du thème enfant, sans aucune autre modification, le LCP est monté à 2,8 s. La différence ? Une police Google importée par le thème enfant via @import, sans font-display: swap, et une feuille de styles non minifiée de 50 Ko qui redéclarait des propriétés déjà présentes dans le parent.
On a extrait le CSS critique vraiment utile, supprimé l’import de police et remis un lien direct avec display=swap, minifié la feuille. Le LCP est revenu à 1,7 s. La leçon n’est pas qu’Astra est mauvais, mais que n’importe quelle couche ajoutée sans vérification crée un point de contention. C’est exactement l’approche qu’on applique quand on fait du state management avec Zustand dans React : importer uniquement l’état nécessaire au composant, jamais la totalité du store. Ici, importer uniquement le style de la page, pas la feuille globale.
La règle des imports conditionnels
La structure d’un thème enfant doit suivre un principe simple : un fichier chargé est un fichier qui sert à la route en cours. Concrètement, on ne déclare pas wp_enqueue_style les yeux fermés. On l’encapsule dans une condition is_page_template() ou is_singular(). On vérifie que la fonction wp_style_is() ou wp_script_is() ne détecte pas déjà une ressource équivalente dans le parent. Et on supprime systématiquement les Google Fonts appelées par l’enfant si le parent les gère déjà correctement.
L’outillage moderne aide à ce travail d’analyse. Dans notre comparaison Claude Code vs Cursor, on a montré qu’un IDE bien configuré peut identifier en quelques secondes les fichiers CSS non utilisés et les redéclarations de fonctions. Cette même logique de repérage du code mort doit s’appliquer à votre thème enfant avant chaque mise en production.
Comment auditer son thème enfant en 10 minutes
Ouvre la page la plus visitée dans les DevTools, onglet Network, coche « Disable cache ». Regarde le nombre de requêtes CSS et JS. Si tu vois plus de trois fichiers CSS et plus de quatre JS pour une page standard, c’est déjà suspect. Vérifie dans l’onglet Coverage si plus de 50 % du code CSS du thème enfant n’est pas utilisé. Ensuite, connecte-toi au back-office, ajoute ?nocache=1 à l’URL, et mesure le TTFB avec un curl -I. Désactive le thème enfant, reteste. Si l’écart dépasse 80 ms, ton functions.php est en cause.
Les problèmes les plus fréquents, on les trouve en trois questions : les hooks sont-ils conditionnés ? Les styles sont-ils minifiés et combinés ? Les polices sont-elles chargées avec font-display et hébergées localement ou via une requête externe ? Répondre à ces trois points permet déjà de récupérer entre 500 ms et 1,2 s de LCP dans les cas qu’on traite au quotidien.
Questions fréquentes
Faut-il supprimer le thème enfant pour améliorer les Core Web Vitals ?
Pas nécessairement. Il faut plutôt le nettoyer en retirant tout ce qui n’est pas strictement requis par les pages réelles, et conditionner les appels. Un thème enfant squelette, sans functions.php ni feuille de style superflue, n’aura quasiment aucun impact sur les métriques.
Un thème enfant peut-il nuire au crawl de Googlebot ?
Indirectement, oui. Un TTFB élevé ou des ressources bloquantes qui ralentissent le rendu peuvent réduire la profondeur de crawl allouée par Googlebot, car le crawler passe plus de temps à attendre chaque réponse. Si le budget de crawl est serré, certaines pages risquent de ne pas être explorées à temps.
Est-ce qu’un thème enfant reste pertinent dans une architecture headless ?
Si le front est découplé et que WordPress ne sert qu’une API, le thème enfant n’a plus d’impact sur le rendu final. Il reste utile pour organiser les snippets PHP côté API, comme des filtres sur les endpoints REST, mais son poids sur les Core Web Vitals devient nul car le navigateur n’exécute plus son CSS ni son JS.
