Un site WooCommerce de 3500 références, un LCP à 4,8 secondes sur mobile, et un propriétaire qui pestait contre son hébergeur. On a désactivé le thème primé acheté sur une marketplace, basculé sur le thème de base livré avec WordPress : 1,9 seconde. Aucune modification d’infrastructure. Juste un thème en moins.
Quand tu tapes « quel thème WordPress utiliser » dans ton moteur de recherche, les résultats te parlent de design, de compatibilité, de notes. C’est la partie émergée. La partie immergée, celle qui intéresse vraiment un développeur ou un SEO technique, c’est le poids dans les Core Web Vitals. Parce que ce que tu vois dans le customizer ne montre ni les 300 Ko de CSS inutilisés, ni les scripts qui bloquent le thread principal, ni le CLS que tu vas traîner pendant des mois.
Le design ne pèse rien, le code du thème si
Un thème WordPress, ce n’est pas ce qui s’affiche à l’écran. C’est un empilement de fichiers PHP, CSS et JavaScript que le serveur assemble à chaque requête. Le design, c’est de l’air. Le code, lui, a une masse. Et cette masse, tu la retrouves en premier sur le LCP et le TTFB.
Le piège classique : confondre look et légèreté. Une maquette épurée peut cacher 2 Mo de polyfills, trois versions de jQuery chargées par des plugins tiers, et une feuille CSS de 8000 lignes dont seules 1100 servent à la page d’accueil. L’œil humain ne voit rien. Lighthouse voit tout.
J’ai passé des dizaines de thèmes au crible sur un banc d’essai standard : un WordPress nu, un article de 1200 mots, une image de couverture, et une page d’accueil avec trois blocs. La différence entre le meilleur et le pire tient dans un seul chiffre : 2,8 secondes de LCP d’écart. Le design était quasiment identique.
Alors si tu t’apprêtes à choisir un thème, ne commence pas par la galerie de démos. Commence par l’onglet Réseau des DevTools.
LCP, TTFB, CLS : ce que le thème impacte vraiment
Peu de gens mesurent à quel point un thème peut saboter les signaux de classement. On a documenté l’impact de chaque couche sur les Core Web Vitals dans un banc d’essai plus large, mais le premier amortisseur, c’est presque toujours le template.
Sur le LCP, le thème agit à deux endroits. D’abord en amont : s’il embarque des requêtes serveur lourdes (menus dynamiques non mis en cache, sidebar chargée via une requête admin-ajax), il augmente le TTFB. Ensuite en aval : il décide de l’ordre de chargement du contenu principal. Un thème qui charge d’abord la sidebar, la bannière pub, puis seulement le contenu de l’article te garantit un LCP minable.
Le CLS, lui, dépend de la structure HTML livrée par le thème. Une grille d’articles montée avec des hauteurs implicites, des images sans dimensions explicites, ou des polices Google chargées sans font-display: swap, et c’est le contenu qui saute à l’affichage. J’ai vu des thèmes réputés provoquer un décalage de 0,23 après chaque interaction, à cause d’un script de lazy-loading maison qui réservait zéro espace.
L’INP n’est pas épargné non plus. Les thèmes qui s’appuient sur des frameworks JavaScript côté client pour animer le menu ou gérer les onglets peuvent verrouiller le thread principal bien après l’interaction utilisateur. Et on ne parle même pas des thèmes « one-page » dont le scroll hijacking rend le site inutilisable sur mobile.
⚠️ Attention : Un TTFB correct masque souvent un thème lent lors d’un audit superficiel. Lance Lighthouse en mode « Slow 4G » dans les DevTools avant de valider un template.
Ce qui alourdit vraiment un thème WordPress
On ne va pas se mentir : le marché des thèmes premium a longtemps fonctionné sur une logique de surenchère. Plus de sliders, plus de widgets, plus de démos pré-packagées. Pour le vendeur, c’est un argument commercial. Pour ton site, c’est un boulet.
La première chose qui plombe un thème, c’est l’accumulation de librairies front-end. Quand tu vois un shortcode qui appelle une animation jQuery UI juste pour faire défiler trois témoignages, demande-toi combien de kilooctets tu vas faire avaler à Googlebot pour zéro valeur ajoutée éditoriale.
La deuxième, c’est le CSS global inutilisé. Beaucoup de thèmes chargent une feuille de style monolithique sur toutes les pages, y compris les Archives, l’auteur, la page 404. Résultat : 70 % du CSS sert une page sur vingt. PurgeCSS fait des miracles, mais ça reste un pansement sur une jambe de bois.
La troisième, c’est la dépendance à un page builder propriétaire. Si ton thème « recommande WPBakery » ou exige Elementor pour fonctionner, tu hérites de leur DOM surchargé, de leurs blocs imbriqués, et d’une cascade de div qui rendent le crawl plus lent. D’ailleurs, la plupart des sites que je reprends avec des problèmes d’indexation ont en commun un thème + builder où le contenu réel se cache après 60 nœuds HTML.
Page builders, sliders, widgets : le trio qui plombe l’indexation
Googlebot lit le HTML. Point. Ce qu’il ne voit pas, il ne l’indexe pas. Et les thèmes qui reposent sur des montages JavaScript pour afficher le contenu principal créent un décalage entre ce que voit ton navigateur et ce que voit le moteur.
J’ai déjà hérité d’un site où la page d’accueil affichait 12 articles récents, zéro dans le code source. Le thème utilisait un widget « Articles populaires » chargé en AJAX via /wp-admin/admin-ajax.php. Googlebot ne déclenchait pas l’appel AJAX, pas de contenu, pas d’indexation. Fallait le savoir.
Les sliders représentent une autre catastrophe. Ils poussent souvent le premier contenu visible vers le bas du DOM, ce qui retarde le LCP et dilue la pertinence thématique. Et quand ils embarquent des images en background-image avec un attribut alt inexistant, ton maillage interne perd des signaux sémantiques.
Quant aux widgets, ils fragilisent la stabilité visuelle. Une barre latérale qui charge une pub via iframe, c’est du CLS garanti. Sans compter les appels à des scripts tiers qui allongent la cascade réseau.
💡 Conseil : Si tu ne peux pas te passer d’un slider, implémente-le en CSS pur ou laisse la première slide en static dans le flux du document. Tu verras la différence dans le rapport « Expérience » de la Search Console.
Le virage FSE enterre la vieille question du thème
Depuis WordPress 5.9 et la généralisation du Full Site Editing, le débat « quel thème utiliser » n’a plus le même sens. Un thème FSE n’est qu’un jeu de modèles HTML construit avec des blocs. Tu peux obtenir le même rendu visuel avec le thème de base et une dizaine de patterns maison qu’avec un pack premium facturé 59 €.
L’avantage côté performance est radical. Plus de feuille CSS générique : le fichier theme.json permet de désactiver les styles des blocs inutilisés. Plus de hooks PHP conditionnels : c’est l’éditeur de blocs qui assemble l’interface. Et surtout, la logique métier sort du template pour entrer dans des blocs réutilisables, bien plus faciles à auditer avec des outils comme Query Monitor.
Le vrai clivage aujourd’hui, c’est entre approche FSE native et thème « hybride » qui prétend marier le meilleur des deux mondes. Cette dernière catégorie réintroduit souvent du JavaScript superflu pour les animations, les menus, ou les galleries. On se retrouve alors avec une architecture qui ressemble à un débat familier dans le développement front end : le choix entre un outil tout-en-un et un environnement minimal n’est jamais simple, un peu comme la discussion claude code vs cursor ide qui partage ce même goût pour les comparaisons acérées.
Si tu pars d’une feuille blanche en 2026, un thème FSE minimal couplé à un déploiement par blocs est presque toujours plus léger. Les overheads se mesurent à quelques dizaines de Ko de CSS inline et à zéro script tiers. Le contenu, lui, reste immédiatement disponible pour Googlebot.
Quand la gestion d’état interne complique le rendu
Certains thèmes modernes, notamment ceux qui intègrent des blocs React complexes, s’aventurent sur le terrain de la gestion d’état sans vraiment le maîtriser. Un carrousel qui maintient la position des slides, une navigation hors-champ qui suit le défilement, un filtre produit asynchrone : ces interactions s’appuient sur un état local qui peut dégrader l’INP si le cycle de mise à jour du DOM n’est pas optimisé.
Sans aller jusqu’à comparer un thème WordPress à une application React à part entière, on retrouve des mécaniques communes. Quand un bloc gère son état avec des techniques qui rappellent un state management react zustand mais sans contrôle fin des re-rendus, le thread principal trinque. Résultat : un menu mobile qui met 300 ms à s’ouvrir, un film de keyframes qui saccade, un FID qui passe dans le rouge.
La bonne approche consiste à privilégier les thèmes qui délèguent l’interactivité aux blocs natifs — ceux qui fonctionnent sans couche d’abstraction JavaScript supplémentaire. Chaque script mis de côté, c’est du temps de blocage économisé.
Avant d’installer un thème, une inspection rapide dans l’arborescence des node_modules ou du dossier assets te renseigne mieux que la fiche Thème sur le catalogue officiel. Si tu repères un dossier redux ou des dépendances à lodash alors que le site n’a que cinq pages, tu as probablement affaire à un marteau-pilon pour enfoncer une punaise.
Questions fréquentes
Un thème gratuit bien noté peut-il rivaliser avec un premium pour les Core Web Vitals ? La note ne dit rien du poids. Un thème gratuit qui se contente de l’architecture FSE et ne charge que les blocs actifs surpassera presque toujours un premium surchargé. Teste-le avec Lighthouse et le Coverage Panel des DevTools avant de te décider.
Faut-il obligatoirement un thème « optimisé SEO » ?
Les optimisations SEO annoncées se résument souvent à un champ meta description et un fil d’Ariane basique. Ce qui importe vraiment, c’est un HTML propre, un chargement rapide et une structure sémantique correcte. Tu peux obtenir tout cela avec un thème très simple et deux réglages dans ton plugin SEO.
Peut-on réparer un thème lent sans en changer ? Oui, jusqu’à un certain point. On peut purger le CSS inutilisé, différer les scripts non critiques, supprimer les sliders et remplacer les widgets dynamiques par du contenu statique. Mais dès que le thème impose son propre page builder, le chantier devient vite disproportionné par rapport au gain. Changer de thème reste souvent l’option la plus propre.
