Skip to content
NEW — AERVIO Sites: Professional websites from $49/month →

Core Web Vitals et thèmes WordPress ThemeForest : quoi corriger en premier

Written by AERVIO, a Montreal studio. Human-reviewed before publish. Contact: hello@aervio.io · +1 438-498-3913.

Core Web Vitals et thèmes WordPress ThemeForest : quoi corriger en premier

Les thèmes polyvalents de ThemeForest échouent généralement aux Core Web Vitals pour les mêmes raisons : ils chargent des scripts, des styles et des polices pour des fonctions que vous n’utilisez pas, ils embarquent de grosses couches de constructeur de pages, et leur contenu de démonstration place des images surdimensionnées dans le premier écran. L’ordre des correctifs : mesurer les données réelles, retirer le poids inutile, corriger le plus grand élément, stabiliser la mise en page, puis décider si le thème vaut d’être gardé. Courir après un score de laboratoire, c’est dépenser une semaine pour ne rien changer de ce que les visiteurs ressentent.

AERVIO est un studio montréalais, en semaine de 9 h à 17 h HE. Voici la séquence que nous suivons quand un site d’entreprise sur un thème acheté est lent et que le propriétaire ne veut pas de refonte sans raison.

Les trois mesures, en langage simple

  • LCP (Largest Contentful Paint) : le temps avant que le plus grand élément visible, souvent une image de bannière ou un titre, soit à l’écran. Le seuil « bon » est de 2,5 secondes ou moins.
  • INP (Interaction to Next Paint) : la rapidité de la réponse de la page après un toucher ou un clic. Le seuil « bon » est de 200 millisecondes ou moins.
  • CLS (Cumulative Layout Shift) : à quel point la mise en page saute pendant le chargement. Le seuil « bon » est de 0,1 ou moins.

Google les évalue au 75e centile des visites réelles : un quart de vos visiteurs peut vivre une moins bonne expérience et la page peut quand même réussir. Voyez le guide Web Vitals de web.dev pour les définitions à jour.

Pourquoi les thèmes ThemeForest peinent

Les thèmes sont conçus pour se vendre grâce à une page de démonstration, donc ils incluent tout ce qu’un acheteur pourrait vouloir.

Habitude courante du thème Effet sur les indicateurs
Des dizaines de carrousels, d’animations et de jeux d’icônes inclus Plus de JavaScript et de CSS sur chaque page
Constructeur de pages inclus, avec modules propres au thème DOM volumineux, travail lourd sur le fil principal
Carrousels en en-tête et vidéos en arrière-plan LCP lent, sauts de mise en page
Plusieurs polices Google et polices d’icônes Délai d’affichage, texte invisible, sauts
Plugiciels jQuery pour les effets Interaction lente sur les téléphones de milieu de gamme
Images de démo importées en pleine taille Pages lourdes, grosse image LCP
Extensions qui injectent leurs ressources partout Scripts de formulaire sur des pages sans formulaire

Rien de malveillant là-dedans. C’est le coût d’un design à usage général.

Étape 1 : mesurer la bonne chose

Commencez par les données de terrain quand elles existent.

  • Search Console, rapport Core Web Vitals : regroupe les URL par état, mobile et ordinateur.
  • PageSpeed Insights : affiche des données d’utilisateurs réels (si disponibles) au-dessus du test de laboratoire.
  • Outils de laboratoire (Lighthouse, WebPageTest) : utiles pour diagnostiquer les causes, pas pour déclarer victoire.

Testez vos pages qui rapportent : accueil, une page de service, la page de contact et l’article le plus visité. Ne faites pas la moyenne du site. Un blogue rapide et une page de contact lente, c’est une page de contact lente.

Si une URL a trop peu de trafic pour des données de terrain, fiez-vous au test de laboratoire, mais avec un profil mobile limité, pas la fibre du bureau.

Étape 2 : retirer ce qui se charge sans servir

C’est généralement le plus gros gain, au plus faible coût.

  1. Listez chaque extension et les pages qu’elle sert réellement.
  2. Désactivez celles que vous n’utilisez pas.
  3. Utilisez un gestionnaire de ressources pour empêcher scripts et styles de se charger là où ils sont inutiles, par exemple les formulaires sur des pages sans formulaire.
  4. Désactivez les modules du thème (carrousels, portfolios, méga-menus) que vous n’utilisez pas.
  5. Supprimez le contenu de démo et les widgets inutilisés.

Retestez après chaque changement. Si quelque chose casse, vous saurez lequel.

Étape 3 : corriger le LCP

Repérez l’élément LCP dans les résultats du test. C’est généralement l’un de ceux-ci :

  • Une image de bannière. Redimensionnez-la à la taille affichée, servez un format moderne comme WebP ou AVIF, et évitez le chargement différé de l’image qui apparaît d’abord à l’écran. Envisagez un préchargement si elle est découverte tard.
  • Un carrousel. Remplacez-le par une image fixe et un titre clair. On lit rarement un carrousel au-delà de la première diapositive.
  • Un titre en police personnalisée. Réduisez les fichiers de polices et prévoyez une police de repli raisonnable pendant le chargement.
  • Une vidéo en arrière-plan. Remplacez-la par une image d’aperçu, ou retirez-la.

Un temps de réponse serveur lent gonfle aussi le LCP. Vérifiez l’hébergement, la mise en cache et si la page est construite par de lourdes requêtes à la base de données à chaque visite. Là, un cache de pages et un hébergement convenable comptent plus que n’importe quel réglage du thème.

Étape 4 : corriger l’INP

Les problèmes d’INP viennent d’un JavaScript qui en fait trop quand une personne interagit.

  • Retirez les widgets tiers inutiles (clavardage, fenêtres contextuelles, fils sociaux)
  • Différez les scripts non essentiels jusqu’après la première interaction
  • Remplacez les menus animés par des menus plus simples
  • Réduisez l’imbrication du constructeur de pages qui crée des DOM énormes
  • Testez sur un Android de milieu de gamme, pas sur un portable de développeur

Si la cause est le JavaScript central du thème et que vous ne pouvez pas le désactiver, c’est une preuve pour la discussion sur le remplacement.

Étape 5 : corriger le CLS

Le décalage de mise en page est rarement mystérieux.

  • Ajoutez largeur et hauteur (ou ratio) aux images et aux intégrations
  • Réservez de l’espace pour les publicités, les bannières de témoins et les widgets de clavardage
  • Chargez les polices avec des réglages `font-display` et des polices de repli ajustées
  • Évitez d’injecter des bannières au-dessus du contenu existant après le chargement

Les bannières de témoins et de consentement sont des coupables fréquents. Elles doivent se superposer ou disposer d’un espace réservé, pas pousser la page vers le bas.

Étape 6 : décider — ajuster, alléger ou remplacer

Après ce qui précède, il reste trois choix honnêtes.

Choix Quand il convient
Ajuster Les scores se sont améliorés, les problèmes restants sont mineurs
Alléger Remplacer le constructeur de pages ou les modules lourds, garder le contenu
Remplacer Le code central du thème est le goulot et ne peut pas être désactivé

Remplacer ne veut pas dire changer de CMS. Un thème WordPress sobre, construit pour vos mises en page, règle souvent le problème. Quand la vraie question porte sur les rédacteurs, la pile technique et la propriété à long terme, nous en parlons dans Next.js ou WordPress pour les entreprises québécoises.

Le lien avec la recherche et les réponses d’IA

La vitesse est une composante de la qualité d’une page. Google regarde aussi si la page répond à la requête, si le contenu est utile et si le site est explorable. Une page rapide au texte vague ne deviendra pas visible parce qu’elle passe un test. Nous traitons performance, contenu et signaux locaux comme un seul système, et notre approche de la visibilité locale se trouve dans SEO et GEO à Montréal.

Nous ne garantissons pas de positions. Nous garantissons la mesure, la liste des changements et ce que nous avons constaté.

À quoi s’attendre la première semaine

  • Jour 1 : recueillir les données de Search Console et tester les cinq principales URL
  • Jour 2 : inventaire des extensions et des ressources
  • Jour 3 : retirer et différer l’inutilisé, retester
  • Jour 4 : images, polices et élément LCP
  • Jour 5 : revue de l’INP et du CLS, puis recommandation écrite

Certains thèmes s’améliorent beaucoup. D’autres un peu, et demandent de refaire la couche des gabarits. Le rapport vous dit lequel.

Prochaine étape

Écrivez à hello@aervio.io avec l’URL du site, le nom du thème et une capture du rapport Core Web Vitals de Search Console, ou appelez le +1 438-498-3913, en semaine de 9 h à 17 h HE. Nous dirons s’il s’agit d’un ajustement ou d’une refonte. Notre page services SEO et GEO explique comment nous combinons correctifs techniques et pages dignes d’être citées.

Questions

Quels sont les seuils des Core Web Vitals?

Selon les repères de Google, une page est jugée bonne quand, au 75e centile des visites réelles, le Largest Contentful Paint est de 2,5 secondes ou moins, l’Interaction to Next Paint de 200 millisecondes ou moins, et le Cumulative Layout Shift de 0,1 ou moins. Consultez web.dev pour les définitions à jour.

Corriger les Core Web Vitals améliorera-t-il notre classement?

Ça peut aider, mais nous ne le promettons pas. L’expérience de page est un signal parmi d’autres, et la pertinence pèse davantage. Une page rapide qui répond à la mauvaise question ne se classera pas pour celle-ci. Les pages rapides réduisent toutefois l’abandon, ce qui est la raison d’affaires la plus fiable de les corriger.

Faut-il remplacer notre thème ThemeForest?

Pas automatiquement. Mesurez d’abord, retirez ce que vous n’utilisez pas et testez. Si le thème vous bloque encore après, une version plus légère se justifie. Remplacez sur des preuves, pas sur un score.

Let's write the next step.

AERVIO web development illustration — Montreal studio AERVIO growth illustration — the next URL after launch