Avis WP Rocket 2026 : mes réglages sur 450 articles

Vous avez installé une extension de cache, coché les options les plus alléchantes, et votre site s’est cassé. Le menu ne s’ouvre plus, le bandeau cookies a disparu, le formulaire de contact ne part plus. Vous avez tout décoché, et vous êtes revenu à la case départ.

Ce scénario n’a rien d’exceptionnel : c’est le parcours normal de quiconque active le délai d’exécution du JavaScript sans savoir quoi en exclure. Le problème n’est pas l’extension. Le problème, c’est que personne ne publie sa liste d’exclusions.

Alors je publie la mienne. Intégralement. Elle tourne sur un site de 450 articles avec une boîte à outils chargée : bandeau de consentement, suivi statistique, comparateur maison, tableaux d’affiliation. Si elle tient là-dessus, elle tiendra chez vous.

Mes scores réels, mesurés

Commençons par les chiffres, relevés via Rocket Insights, l’outil de mesure intégré à l’extension et adossé à GTmetrix.

Trois observations valent d’être soulignées.

Ce dernier point mérite qu’on s’y arrête, parce qu’il délimite honnêtement ce qu’une extension de cache peut faire. Le temps de réponse du serveur dépend de votre hébergement, pas de vos réglages. Aucune extension au monde ne compensera un serveur lent.

Mes exclusions de délai JavaScript, la liste complète

Voici le cœur de cet avis WP Rocket, et la raison pour laquelle je l’ai écrit. L’option « retarder l’exécution du JavaScript » est la plus efficace de l’extension et la plus destructrice si on l’active nue.

Le principe : aucun script ne s’exécute tant que le visiteur n’a pas bougé sa souris, touché l’écran ou fait défiler. Le gain sur le temps de blocage est spectaculaire. Le problème, c’est que certains scripts doivent partir immédiatement, sans quoi ils ne partent jamais.

Cette liste n’a pas été écrite d’un trait. Chaque ligne correspond à quelque chose qui a cassé, que j’ai constaté, puis corrigé. C’est exactement ce travail que vous éviterez en la recopiant.

La règle qui évite 90 % des problèmes

Retenez ce principe et vous n’aurez presque jamais besoin de déboguer : tout ce qui doit s’exécuter avant que le visiteur n’agisse doit être exclu du délai.

Un bandeau de consentement s’affiche avant l’interaction. Un compteur de statistiques démarre avant l’interaction. Un tableau d’affiliation se construit avant l’interaction. En revanche, un carrousel en bas de page, un widget de partage social ou une carte interactive peuvent parfaitement attendre.

Le CSS inutilisé, l’option qui fait peur

L’option de suppression du CSS inutilisé analyse chaque page et ne conserve que les règles réellement employées. Le gain est important, et le risque aussi : si une règle est retirée à tort, un élément perd son style.

D’où la liste blanche, ma seconde liste, qui compte 31 entrées. En voici la logique :

Le motif est toujours le même : tout ce qui est généré dynamiquement doit être protégé. L’outil analyse le HTML présent au chargement ; il ne peut pas deviner qu’un bandeau va apparaître trois secondes plus tard, ni qu’un tableau va se construire en JavaScript. Ces règles-là seraient supprimées à tort.

Le réglage à deux lignes qui sauve votre LCP

Celui-ci mérite sa propre section, parce qu’il est mal connu et qu’il agit directement sur la métrique que Google surveille le plus.

Le chargement différé des images est excellent : les visuels du bas de page ne se chargent qu’à l’approche. Mais appliqué aveuglément, il diffère aussi l’image la plus visible de votre page, celle qui détermine votre Largest Contentful Paint. Vous dégradez alors la métrique que vous cherchiez à améliorer.

Ajoutez-y l’image mise en avant de vos articles si elle apparaît en haut de page. La règle générale tient en une phrase : ce qui est visible sans faire défiler ne doit jamais être différé.

Les options que j’active, et celles que je laisse

Le contrôle du Heartbeat, l’option qu’on oublie

WordPress envoie une requête au serveur toutes les quinze secondes pour vérifier si quelque chose a changé. Sur un site à fort trafic ou un hébergement mutualisé, c’est une charge permanente pour rien.

Je le désactive complètement côté administration et côté site public, et je me contente de le réduire dans l’éditeur, où il assure la sauvegarde automatique. C’est une économie invisible en vitesse de page, mais très réelle en consommation serveur.

Le préchargement DNS

J’ai listé dix domaines externes : polices Google, Tag Manager, Analytics, Clarity, Metricool, régie Amazon. Le navigateur résout leur adresse pendant qu’il charge le reste, au lieu d’attendre d’en avoir besoin.

Le gain se compte en dizaines de millisecondes par domaine. Ce n’est pas spectaculaire pris isolément, mais dix domaines finissent par peser. Listez ceux que votre site appelle vraiment, pas plus : chaque entrée inutile est une résolution DNS pour rien.

Comment vérifier que ça marche vraiment

Activer des options ne sert à rien si vous ne mesurez pas. Et mesurer mal est pire que ne pas mesurer, parce que vous prenez des décisions sur des chiffres faux. Voici le protocole que je suis, celui qui a produit les relevés de cet article.

Mesurez trois pages, pas une

L’erreur la plus courante consiste à ne tester que l’accueil. Or c’est presque toujours la page la plus optimisée du site, celle qu’on soigne et qu’on allège. Mes propres chiffres le montrent : 85 sur 100 en accueil, mais 78 sur les articles. Sept points d’écart, sur la même installation.

Prenez donc trois pages représentatives : l’accueil, un article court, un article long et illustré. C’est cette dernière qui révélera vos vrais problèmes, et c’est aussi celle où arrivent la plupart de vos visiteurs depuis Google.

Videz le cache avant chaque test

Un test lancé sur une page déjà en cache donne un résultat flatteur et faux. Videz le cache, chargez la page une fois pour la reconstruire, puis lancez la mesure. Vous obtiendrez le chiffre que voit un visiteur ordinaire, pas celui d’un cache parfaitement chaud.

Inversement, ne mesurez pas juste après une purge complète : la première visite reconstruit tout et vous donnerait un chiffre inutilement pessimiste. La bonne fenêtre se situe entre les deux.

Les trois chiffres qui comptent

Ignorez le score global sur cent, du moins au début. Il agrège des dizaines de critères dont certains ne vous concernent pas, et il vous fera courir après des points sans effet réel sur l’expérience de vos lecteurs. Les trois métriques ci-dessus, elles, se traduisent directement en ressenti.

Testez après chaque changement, pas tous en bloc

Dernière règle, et la plus importante : activez une option, mesurez, passez à la suivante. Si vous cochez huit cases d’un coup et que le site casse, vous ne saurez jamais laquelle est responsable, et vous finirez par tout désactiver.

C’est plus lent, mais c’est ainsi que se construisent les listes d’exclusions que je vous ai livrées plus haut. Chacune de leurs lignes correspond à un test, une casse, un diagnostic. En les recopiant, vous gagnez ce temps-là.

Les tarifs, relevés le 25 août 2026

Regardez la colonne du coût par site : c’est elle qui raconte l’histoire. La formule Multi revient à moins de 5 € par site, dix fois moins que la Single. Si vous gérez ne serait-ce que six sites, elle est déjà rentable.

Il n’existe pas de version gratuite, et c’est le principal reproche qu’on adresse à l’extension. La garantie de 14 jours en tient lieu : vous payez, vous testez sur votre vrai site, et vous vous faites rembourser si le résultat vous déçoit.

Faut-il payer alors que LiteSpeed Cache est gratuit ?

La question est légitime, et la réponse tient en une phrase : cela dépend entièrement de votre hébergeur.

Pour être transparent sur mon propre cas : j’utilise WP Rocket sur mon site de 450 articles et LiteSpeed Cache sur celui-ci, parce qu’il est hébergé sur un serveur LiteSpeed. Ce n’est pas une contradiction, c’est le bon outil selon le terrain.

Ce qui m’a déçu

Aucune version d’essai. Il faut payer pour voir. La garantie de 14 jours règle le problème sur le fond, mais elle suppose d’avancer l’argent et de demander un remboursement, ce que beaucoup n’oseront pas faire.

Les options dangereuses ne sont pas signalées comme telles. Le délai d’exécution du JavaScript et la suppression du CSS inutilisé peuvent casser un site en profondeur, et rien dans l’interface ne prévient qu’il faut construire une liste d’exclusions. C’est précisément le vide que cet article comble.

Le TTFB reste hors de portée. Mes relevés le montrent : de 596 à 1 249 ms selon les pages, sur la même installation et avec les mêmes réglages. Cette variation vient du serveur, et aucune extension n’y peut quoi que ce soit. Si votre TTFB dépasse la seconde, changez d’hébergeur avant d’acheter quoi que ce soit.

Mon verdict sur WP Rocket

WP Rocket tient ses promesses, à condition d’accepter qu’il ne fait pas de miracle. Il ne rendra pas rapide un site hébergé sur un serveur lent, et il ne devinera pas quels scripts votre site ne peut pas se permettre de retarder.

Ce qu’il fait, il le fait bien : sur 450 articles avec une boîte à outils chargée, mes trois pages mesurées tiennent entre 78 et 85 sur 100, avec un CLS parfait. Le prix par site en formule Multi rend la question du budget presque théorique dès qu’on gère plusieurs projets.

Mon conseil final tient en deux temps. Vérifiez d’abord si votre hébergeur tourne sous LiteSpeed : si oui, essayez l’extension gratuite avant de payer. Sinon, prenez WP Rocket, activez les options dans l’ordre de cet article, et recopiez mes listes d’exclusions. Vous vous épargnerez les semaines de débogage qu’elles représentent.

Un dernier mot sur l’ordre des choses. WP Rocket agit sur la livraison des pages, mais il ne réduit pas le poids de vos images : c’est le travail d’Imagify, que j’ai mesuré à 57 % de gain sur ma propre médiathèque. Et aucun des deux ne remplace une structure SEO propre, que je confie à Rank Math. Optimisez dans cet ordre : contenu, images, puis cache.

Questions fréquentes sur WP Rocket

Scores relevés via Rocket Insights le 25 août 2026 sur un site de 450 articles publiés. Tarifs vérifiés le même jour sur la page officielle de l’éditeur. Si vous constatez un écart, signalez-le-moi et je corrige la page. Ma méthode de test détaille la façon dont ces chiffres sont obtenus.