# Optimisation Avada PageSpeed : de 82 à 99 sur mobile **Auteur:** Webstrategy **Publié:** 2026-05-03T23:18:55+02:00 **URL:** https://wordpress-freelance.com/articles/optimisation-avada-pagespeed/ **Catégories:** Performance WordPress --- **L’optimisation Avada PageSpeed** est un terrain piégé : le thème injecte tellement de JavaScript et de CSS que les conseils génériques de tutos te font [casser ton site](/articles/erreurs-wordpress-3-erreurs-critiques-a-eviter-pour-90/ "casser ton site") avant de gagner le moindre point. Mai 2026, score PageSpeed Insights de wordpress-freelance.com : 82 mobile, 100 desktop. Core Web Vitals au vert (LCP 1,4s, CLS 0,004), mais un Total Blocking Time de 450 ms qui 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. Voici ce que j’ai fait, ce qui a marché, et surtout les pièges que j’ai évités au passage. Article qui devrait servir aux freelances WordPress et aux agences qui galèrent à grappiller les derniers points sur un thème Avada/Fusion Builder. ## Optimisation Avada PageSpeed : pourquoi viser 100 sur mobile est un piège Soyons clairs tout de suite. Avada injecte un volume important de [JavaScript et CSS](/articles/gestion-dactifs-wordpress-guide-ultime-en-5-etapes-essentiel/ "JavaScript et CSS") pour faire fonctionner Fusion Builder, ses sliders, ses méga-menus, ses animations. Tu peux gratter jusqu’à 99, mais le 100 mobile demande souvent de casser quelque chose ou de désactiver des fonctionnalités que ton client voulait spécifiquement. L’objectif réel pour le SEO, ce n’est pas le score Lighthouse. Ce sont les Core Web Vitals au vert (LCP inférieur à 2,5s, CLS inférieur à 0,1, INP inférieur à 200 ms) plus un score raisonnable au-dessus de 90. À partir de là, le différentiel SEO entre un 92 et un 99 est négligeable. Ce qui compte, c’est l’expérience utilisateur réelle, mesurée par CrUX sur 28 jours glissants. Viser 100 mobile en sacrifiant le mega-menu ou les sliders ? Aucun intérêt. Viser 95+ avec CWV verts ? Là on parle. ## Le diagnostic : pourquoi le TBT, pas le LCP Sur ce site, LCP était déjà à 1,4s. Rien à faire. Le coupable du score 82, c’était le Total Blocking Time à 450 ms. Le TBT mesure le temps pendant lequel le main thread du navigateur est bloqué par du JavaScript long à exécuter, ce qui empêche l’utilisateur d’interagir avec la page. Quand Lighthouse te dit « Eliminate render-blocking resources » et pointe jQuery, ça veut dire que jQuery est chargé dans le `` de manière synchrone, et tant qu’il n’est pas téléchargé et exécuté, le navigateur attend. Sur mobile, avec une connexion 4G simulée, ça coûte cheril est donc temps d’effectuer une optimisation Avada PageSpeed. ## La solution : LiteSpeed Cache en mode Delayed Le site est hébergé sur Hostinger, qui tourne sous LiteSpeed Web Server. Le plugin LiteSpeed Cache est gratuit et il a une fonctionnalité qui change la donne pour l’optimisation Avada PageSpeed : Load JS Deferred avec l’option « Delayed » (à différencier du mode « Deferred » classique). Les images sont toutes optimisées au format webp, permettant une [accélération de chargement](/articles/wordpress-image-optimizer-plugins-7-outils-essentiels/) de ces dernières. La différence est fondamentale. Le mode « Deferred » ajoute simplement l’attribut `defer` aux scripts, ils s’exécutent une fois le DOM parsé. Le mode « Delayed » pousse le chargement du JS jusqu’à la première interaction utilisateur (scroll, clic, mouvement de souris). Tant que le visiteur n’a pas bougé, aucun JS non-critique n’est exécuté. Lighthouse simule une page qui ne bouge pas, donc le TBT s’effondre. Sur ce site, le TBT est passé de 450 ms à 40 ms. Gain ×11. ## Les exclusions JS critiques sur Avada Et là, attention. Si tu actives Delayed sans configurer les exclusions, Avada explose en vol. Méga-menu cassé, sticky header qui ne fonctionne plus, sliders Fusion qui ne se chargent jamais. C’est la partie où la majorité des tutos te lâchent dans la nature, et c’est aussi le cœur d’une optimisation Avada PageSpeed qui tient en production. Voici les exclusions que j’ai mises en place dans LiteSpeed Cache. Pour le JS Excludes (qui empêche le minify et le combine) : `jquery`, `jquery-migrate`, `avada`, `fusion`. Pour le JS Delayed Includes (qui empêche le delay) : `jquery`, `jquery-migrate`, `jquery-core`, `fusion`, `avada`, `wp-includes`, `gtm.js`. ![Optimisation Avada PageSpeed : Liste des exclusions JS LiteSpeed Cache pour préserver Avada](/wp-content/uploads/2026/05/avadajsexclu.webp "Optimisation Avada PageSpeed : de 82 à 99 sur mobile 1") *Liste des exclusions JS pour préserver le fonctionnement d’Avada (JS Excludes et Delayed Includes).* L’idée : tu retires du delay tout ce qui est nécessaire à l’affichage initial et au fonctionnement du thème. jQuery et jQuery Migrate doivent charger immédiatement, sinon Avada n’a pas son framework. Les scripts Fusion gèrent le builder côté front, ils doivent être disponibles dès le DOM ready. wp-includes contient les scripts core de WordPress. Et 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. ## Pourquoi je n’active que rarement JS Combine sur Avada Le mythe : « combiner les JS réduit le nombre de requêtes, donc améliore la perf ». La réalité sur Avada : ça casse 9 sites sur 10. Fusion Builder a des dépendances d’ordre de chargement précises entre ses scripts, et la combinaison foire ces ordres dans des cas non-déterministes. Tu peux avoir un site qui marche en preprod et qui plante en prod après une mise à jour mineure d’Avada. Pas la peine. Avec HTTP/2 (que tous les hébergeurs sérieux servent depuis 2020), les multiples petites requêtes coûtent peanuts. Le gain perçu de la combinaison est largement compensé par le risque de casser le builder. Je laisse JS Combine désactivé sur 100% de mes sites Avada. ## Le bonus accessibilité : ratio de contraste 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. Calcul du ratio : 4,38:1. Sous le seuil AA (4,5:1) qui est la norme légale dans l’UE depuis l’European Accessibility Act de 2025. Pire : le hover passait à #9b8ec4 sur le même texte, soit un ratio de 2,55:1. Illisible pour à peu près tout le monde, et catastrophique pour qui a un trouble visuel. J’ai recalibré dans Avada → Theme Options → Buttons. Gradient passé à #5E3FA8 (ratio 6,56:1, niveau AAA). Hover à #7C5CBF avec texte hover forcé en #FFFFFF (ratio 5,11:1, AA confortable). L’outil que j’utilise pour vérifier : [webaim.org/resources/contrastchecker](https://webaim.org/resources/contrastchecker/). Tu colles tes deux couleurs, il te sort le ratio et te dit si tu passes AA et AAA. Quinze secondes de validation par couleur. Le truc à retenir : valide tes ratios AVANT de figer une charte graphique avec ton client. Refaire la charte parce que le bouton principal n’est pas accessible, c’est de la dette technique évitable. ## Résultats mesurés 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,4s. Une optimisation Avada PageSpeed bien menée, c’est ce ratio temps investi sur gain mesurable : deux heures de configuration pour 17 points de Performance et 4 points d’Accessibilité. ![Optimisation Avada PageSpeed : Après PageSpeed Insights mobile site Avada optimisé](https://wordpress-freelance.com/wp-content/uploads/2026/05/google-page-speed.webp "Optimisation Avada PageSpeed : de 82 à 99 sur mobile 2") *Score sur PageSpeed Insights mobile, le 11 mai 2026.* ## 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.