Mis à jour le 12 octobre 2026
L’optimisation Avada PageSpeed se joue sur le Total Blocking Time, pas sur le LCP : sur mon site, LiteSpeed Cache en mode JS « Delayed », avec des exclusions ciblées pour jQuery, Fusion et Avada, a fait passer le score mobile de 82 à 99 en environ deux heures, sans casser le thème. Voici la configuration exacte et les pièges que j’ai évités.
Le contexte : en mai 2026, le score PageSpeed Insights de wordpress-freelance.com était de 82 sur mobile et 100 sur desktop. Les Core Web Vitals étaient au vert (LCP 1,4 s, CLS 0,004), mais un Total Blocking Time de 450 ms plombait la note mobile. Lighthouse pointait un seul fautif, jQuery, en requête de blocage du rendu, avec 110 ms d’économie estimée. Un site Avada déjà bien optimisé, hébergé sur Hostinger (serveur LiteSpeed), avec un seul levier visible.
Les conseils génériques des tutos peuvent casser ton site avant de gagner le moindre point, parce qu’Avada charge beaucoup de JavaScript et de CSS. Cet article s’adresse aux freelances WordPress et aux agences qui cherchent les derniers points sur un thème Avada/Fusion Builder.
Optimisation Avada PageSpeed : faut-il vraiment viser 100 sur mobile ?
Non. Avada charge du JavaScript et du CSS pour Fusion Builder, ses sliders, ses méga-menus et ses animations. On peut monter jusqu’à 99, mais le 100 mobile demande souvent de casser quelque chose ou de désactiver des fonctionnalités que le client voulait.
L’objectif réel pour le SEO, ce n’est pas le score Lighthouse, ce sont les Core Web Vitals au vert. Google fixe les seuils « bon » à LCP de 2,5 s maximum, INP de 200 ms maximum et CLS de 0,1 maximum, mesurés au 75e percentile des chargements de pages. Au-dessus de 90 de score, l’écart SEO entre un 92 et un 99 est négligeable : ce qui compte, c’est l’expérience réelle mesurée sur le terrain (CrUX, 28 jours glissants).
Viser 100 mobile en sacrifiant le méga-menu ou les sliders n’a aucun intérêt. Viser 95+ avec des Core Web Vitals verts, oui.
Pourquoi le TBT et pas le LCP freinait mon score ?
Parce que mon LCP était déjà à 1,4 s, donc largement sous le seuil. Le coupable du 82 était le Total Blocking Time à 450 ms. Selon la documentation de web.dev, le TBT additionne le temps de blocage de toutes les tâches longues (plus de 50 ms) après le premier affichage, et la cible est de moins de 200 ms sur mobile moyen.
Quand Lighthouse affiche « Eliminate render-blocking resources » et pointe jQuery, cela veut dire que jQuery est chargé de façon synchrone dans le <head>. Tant qu’il n’est pas téléchargé et exécuté, le navigateur attend. Sur mobile avec une 4G simulée, ce blocage pèse lourd sur le TBT, et c’est là que l’optimisation Avada PageSpeed devient rentable.
Quel réglage LiteSpeed Cache change la donne sur Avada ?
Le réglage « Load JS Deferred » en option « Delayed » du plugin gratuit LiteSpeed Cache. Il repousse l’exécution du JavaScript non critique jusqu’à la première interaction du visiteur, ce qui fait s’effondrer le TBT mesuré par Lighthouse.
Mon site est hébergé sur Hostinger, qui tourne sous LiteSpeed Web Server, donc le plugin LiteSpeed Cache s’intègre directement. Mes images sont toutes en webp, ce qui permet une accélération de chargement supplémentaire.
La différence entre les deux modes est fondamentale :
- Deferred : ajoute l’attribut
defer, les scripts s’exécutent une fois le DOM parsé. - Delayed : retient le JS jusqu’à la première interaction (scroll, clic, mouvement de souris). Lighthouse simule une page qui ne bouge pas, donc rien de non critique ne s’exécute.
Sur mon site, le TBT est passé de 450 ms à 40 ms, soit un gain d’un facteur 11.
Quelles exclusions JS configurer pour qu’Avada ne casse pas ?
Il faut exclure jQuery, Fusion et Avada du delay, sinon le thème explose : méga-menu cassé, sticky header muet, sliders Fusion qui ne se chargent jamais. C’est la partie que la plupart des tutos oublient, et le cœur d’une optimisation Avada PageSpeed qui tient en production.
Voici ce que j’ai mis dans LiteSpeed Cache :
| Champ LiteSpeed Cache | Valeurs que j’ai saisies | Effet |
|---|---|---|
| JS Excludes | jquery, jquery-migrate, avada, fusion |
Empêche le minify et le combine de ces scripts |
| JS Delayed Includes | jquery, jquery-migrate, jquery-core, fusion, avada, wp-includes, gtm.js |
Empêche le delay de ces scripts |
La logique : je retire du delay tout ce qui est nécessaire à l’affichage initial et au fonctionnement du thème. jQuery et jQuery Migrate doivent charger tout de suite, sinon Avada n’a pas son framework. Les scripts Fusion gèrent le builder côté front et doivent être prêts dès le DOM ready. wp-includes contient les scripts du cœur de WordPress. Quant à gtm.js, le tag Google Tag Manager, je le sors du delay pour ne pas perdre des sessions analytics dès la première seconde.
Après chaque modification, je teste le méga-menu, le sticky header et les sliders en navigation réelle (mobile et desktop), puis je purge le cache avant de relancer PageSpeed Insights.
Pourquoi je n’active presque jamais JS Combine sur Avada ?
Parce que Fusion Builder dépend de l’ordre de chargement de ses scripts, et que la combinaison peut le dérégler de façon imprévisible. Le site marche en préproduction, puis plante en production après une mise à jour mineure d’Avada.
Le mythe : « combiner les JS réduit le nombre de requêtes, donc améliore la performance ». Avec HTTP/2, les petites requêtes multiples coûtent peu, et le gain perçu de la combinaison ne compense pas le risque de casser le builder. Je laisse JS Combine désactivé sur mes sites Avada.
Côté versions, rien ne dit que ce réglage soit devenu inutile : Avada évolue vite (la version 7.16 d’août 2026 a notamment remplacé les derniers scripts Bootstrap, et la 7.16.2 est sortie le 30 septembre 2026). Je reteste donc mes exclusions après chaque mise à jour majeure du thème.
Comment corriger le contraste des boutons Avada (WCAG) ?
En recalculant le ratio de contraste de chaque couleur de bouton et en visant au minimum 4,5:1 pour du texte normal, seuil du niveau AA des WCAG. Pendant que j’y étais, j’ai corrigé le score d’accessibilité qui plafonnait à 96.
Lighthouse signalait un contraste insuffisant sur les boutons en mode « Flat ». Le gradient initial allait de #7c5cbf à #7c5cbf avec un texte #f0ede8, soit un ratio d’environ 4,3:1, sous les 4,5:1. Le hover passait à #9b8ec4 sur le même texte, environ 2,55:1 : illisible pour beaucoup de monde, et pénalisant pour une personne avec un trouble visuel. À noter que l’European Accessibility Act, applicable depuis le 28 juin 2025, vise notamment les services de e-commerce, ce qui rend le sujet concret pour les sites de vente.
J’ai recalibré dans Avada, Theme Options, Buttons :
- Gradient passé à #5E3FA8 : environ 6,5:1 avec le texte clair, AA confortable.
- Hover à #7C5CBF avec texte hover forcé en #FFFFFF : environ 5,1:1, AA.
Pour vérifier, j’utilise le contrast checker de WebAIM : tu saisis deux couleurs, il donne le ratio et le verdict AA/AAA. Quinze secondes par couleur. Mon conseil : valide les ratios avant de figer une charte graphique avec ton client, plutôt que de la refaire parce que le bouton principal n’est pas accessible.
Quels résultats mesurés après l’optimisation Avada PageSpeed ?
Mobile : Performance 82 → 99, Accessibilité 96 → 100, Bonnes pratiques 100, SEO 100. Desktop : 100/100/100/100. TBT mobile 450 ms → 40 ms. CLS mobile 0,004 → 0,002. LCP mobile inchangé à 1,4 s. Deux heures de configuration pour 17 points de Performance et 4 points d’Accessibilité.
Checklist et erreurs fréquentes sur Avada
- Relever le TBT et le LCP avant de toucher à quoi que ce soit : le levier dépend du métrique qui coince.
- Activer JS « Delayed » seulement avec les exclusions jQuery, Fusion et Avada déjà saisies.
- Laisser JS Combine désactivé, sauf test complet du builder.
- Tester méga-menu, sticky header et sliders après chaque réglage, puis purger le cache.
- Contrôler les contrastes des boutons avant de valider la charte.
L’erreur la plus fréquente : appliquer un préréglage de tuto sans exclusions et découvrir le site cassé en production.
Besoin d’aide sur ton site Avada ?
Si tu coinces sur les Core Web Vitals, le score PageSpeed ou l’optimisation Avada PageSpeed en général, je propose des audits performance et SEO en freelance. Diagnostic clair, plan d’action chiffré, et exécution si tu veux qu’on s’en charge.
Questions fréquentes
Pourquoi un site Avada est-il lent sur PageSpeed ?
Avada charge beaucoup de JavaScript et de CSS pour Fusion Builder, ses sliders et ses menus. Le problème principal n’est souvent pas le LCP mais le TBT (Total Blocking Time) : trop de scripts bloquent le thread principal au chargement.
Comment améliorer le PageSpeed d’un site Avada ?
Traiter le TBT avec LiteSpeed Cache en mode JS Delayed, exclure jQuery, Fusion et Avada du delay, et éviter JS Combine qui casse souvent le thème. Chez moi, ces trois réglages ont suffi pour passer de 82 à 99 sur mobile.
Faut-il activer JS Combine sur Avada ?
Rarement. Fusion Builder dépend de l’ordre de chargement de ses scripts et la combinaison peut le dérégler. Le mode Delayed de LiteSpeed donne de meilleurs résultats sans ces effets de bord.
Quels seuils Core Web Vitals viser avec Avada ?
Les seuils « bon » de Google sont un LCP de 2,5 s maximum, un INP de 200 ms maximum et un CLS de 0,1 maximum, au 75e percentile (source web.dev). Un score Lighthouse au-dessus de 90 avec ces trois métriques au vert suffit.
Peut-on atteindre 100 sur mobile avec Avada ?
On peut s’en approcher : mon score mobile est passé de 82 à 99 en traitant le TBT et en configurant LiteSpeed correctement. Le 100 parfait est rare avec un thème aussi riche, mais 95+ est atteignable.