Aller au contenu
Voir les offres

Performance 12 min de lecture

Accélérer un site WordPress : 15 actions concrètes

Accélérez votre site WordPress avec 15 actions concrètes : cache serveur, PHP, images, CSS/JS, polices, scripts tiers, base de données, Core Web Vitals.

Pour accélérer un site WordPress, agissez d’abord sur le serveur (hébergement rapide, cache de page, PHP récent), puis sur ce que le navigateur télécharge (images, CSS, JavaScript, polices, scripts tiers), et enfin sur l’entretien (extensions, base de données, tâches planifiées). Mesurez avant et après chaque changement : c’est la seule façon de savoir ce qui a vraiment fonctionné.

Guide à jour au 8 octobre 2026. Les seuils cités sont ceux publiés par Google sur web.dev.

En bref

  • Mesurez d’abord avec PageSpeed Insights : un site « rapide » au sens de Google a un LCP ≤ 2,5 s, un INP ≤ 200 ms et un CLS ≤ 0,1 pour 75 % des visites.
  • Le trio le plus rentable : cache de page côté serveur, images optimisées, extensions triées.
  • Ne chargez jamais en différé l’image principale du haut de page : c’est souvent elle qui détermine le LCP.
  • Les scripts tiers (chat, pixels publicitaires, vidéos intégrées) pèsent souvent plus lourd que WordPress lui-même.
  • Une action à la fois, un test après chaque action : certaines optimisations cassent l’affichage.

Comment mesurer la vitesse d’un site WordPress ?

Utilisez PageSpeed Insights sur vos pages les plus visitées : il affiche les données de terrain des vrais visiteurs (Chrome UX Report) et un diagnostic de laboratoire. Les trois indicateurs Core Web Vitals sont le LCP (affichage du contenu principal), l’INP (réactivité aux interactions) et le CLS (stabilité de la mise en page).

Google considère une page comme bonne lorsque, pour 75 % des visites, ces seuils sont respectés :

IndicateurCe qu’il mesureBonÀ améliorerMauvais
LCPTemps d’affichage du plus grand élément visible≤ 2,5 s2,5 à 4 s> 4 s
INPDélai de réaction aux clics et saisies≤ 200 ms200 à 500 ms> 500 ms
CLSDécalages inattendus de la mise en page≤ 0,10,1 à 0,25> 0,25
TTFB (repère)Temps de réponse du serveur≤ 0,8 s0,8 à 1,8 s> 1,8 s
Seuils publiés par Google sur web.dev, au 8 octobre 2026. Le TTFB n’est pas un Core Web Vital mais conditionne le LCP.

Notez vos valeurs de départ, page d’accueil et une page type (article, fiche produit), sur mobile. Les données de terrain mettent environ quatre semaines à refléter un changement, car elles portent sur une période glissante de 28 jours ; pour juger tout de suite, comparez les mesures de laboratoire.

Côté serveur : quelles actions accélèrent le plus WordPress ?

Les gains les plus importants viennent presque toujours du serveur : un cache de page évite à WordPress de reconstruire chaque page, une version récente de PHP exécute le code plus vite, et un cache d’objet soulage la base de données. Ces trois actions réduisent le TTFB, qui conditionne tout le reste.

1. Choisir un hébergement adapté à WordPress

Un hébergement surchargé ou mal configuré plafonne toutes vos optimisations. Vérifiez le serveur web (LiteSpeed, Nginx ou Apache avec un cache efficace), la version de PHP disponible, les ressources allouées à votre compte et la présence de HTTP/2 ou HTTP/3. Mesurez votre TTFB : au-delà de 0,8 seconde sur une page en cache, le problème vient probablement du serveur. Notre comparatif honnête des hébergeurs WordPress détaille ces critères.

2. Activer un cache de page

Sans cache, chaque visite exécute PHP et des dizaines de requêtes SQL. Avec un cache de page, le serveur renvoie une copie HTML prête à l’emploi. Sur un serveur LiteSpeed, l’extension gratuite LiteSpeed Cache pilote le cache intégré au serveur : suivez notre guide pour configurer LiteSpeed Cache pas à pas. Sur un autre serveur, utilisez une extension de cache reconnue, une seule à la fois.

3. Passer à une version récente de PHP

Chaque version majeure de PHP apporte des améliorations de performance, et les anciennes ne reçoivent plus de correctifs de sécurité (voir le calendrier officiel des versions de PHP). WordPress recommande PHP 8.3 ou plus. Testez d’abord sur une copie du site : de vieilles extensions peuvent être incompatibles. La version active est indiquée dans Outils > Santé du site > Infos > Serveur.

4. Ajouter un cache d’objet pour les sites dynamiques

Les boutiques WooCommerce, les sites de membres et les administrations chargées font beaucoup de requêtes que le cache de page ne couvre pas. Un cache d’objet persistant (Redis ou Memcached), quand votre hébergeur le propose, garde en mémoire le résultat de ces requêtes. Pour un site vitrine entièrement mis en cache, le gain est faible : ce n’est pas une priorité. Chez Hosterwise, Redis est disponible sur toutes les offres : activez-le dans LiteSpeed Cache > Cache > Objet, comme l’explique notre guide LiteSpeed Cache.

Comment optimiser les images d’un site WordPress ?

Compressez vos images, servez-les en WebP ou AVIF, à la bonne taille et avec leurs dimensions déclarées, et chargez en différé uniquement celles qui sont sous la ligne de flottaison. Les images sont souvent l’élément le plus lourd d’une page et déterminent fréquemment le LCP.

5. Compresser et convertir les images

Redimensionnez vos photos avant l’envoi (une image de 4 000 pixels de large n’a pas sa place dans un article) et convertissez-les en WebP, voire en AVIF. WordPress génère automatiquement plusieurs tailles et un attribut srcset pour que le navigateur choisisse la plus adaptée. Une extension d’optimisation, comme le module images de LiteSpeed Cache, automatise la compression et la conversion.

6. Prioriser l’image principale au lieu de la charger en différé

Le chargement différé (lazy loading) est utile pour les images situées plus bas dans la page, mais contre-productif pour l’image LCP. Depuis WordPress 6.3, le cœur ajoute automatiquement l’attribut fetchpriority="high" à l’image qu’il juge la plus probable pour le LCP, comme l’explique l’annonce officielle. Vérifiez que votre thème ou votre extension de cache ne vient pas l’annuler en ajoutant loading="lazy" sur cette image :

<!-- Image principale du haut de page : pas de lazy loading, priorité haute -->
<img src="hero-1200.webp" width="1200" height="630" fetchpriority="high" alt="…">

<!-- Images plus bas dans la page : chargement différé -->
<img src="photo-800.webp" width="800" height="533" loading="lazy" alt="…">

7. Réserver la place des images et des blocs

Le CLS mesure les éléments qui « sautent » pendant le chargement. Les causes les plus fréquentes : images sans attributs width et height, bannières de cookies ou publicités insérées au-dessus du contenu, polices qui changent la taille du texte. Déclarez toujours les dimensions des images et des iframes, et réservez la hauteur des emplacements publicitaires en CSS. Le guide Optimize CLS détaille chaque cas.

Thème, extensions, CSS et JavaScript : comment alléger le code ?

Un thème léger, un nombre raisonnable d’extensions et des fichiers CSS et JavaScript minifiés et chargés sans bloquer l’affichage améliorent à la fois le LCP et l’INP. L’objectif n’est pas d’avoir zéro extension, mais de n’exécuter que le code réellement utile à chaque page.

8. Choisir un thème léger

Certains thèmes « tout-en-un » chargent sur chaque page des sliders, des icônes et des animations que vous n’utilisez pas. Un thème basé sur l’éditeur de blocs ou un thème réputé pour sa légèreté réduit la quantité de CSS et de JavaScript dès le départ. Si vous utilisez un constructeur de pages, désactivez les modules inutilisés dans ses réglages.

9. Faire le tri dans les extensions

Le nombre d’extensions compte moins que ce qu’elles font. Une seule extension mal codée peut ralentir tout le site. Installez temporairement Query Monitor pour repérer les requêtes lentes et les extensions qui chargent des fichiers sur toutes les pages. Supprimez (et pas seulement désactivez) celles que vous n’utilisez plus, et remplacez celles qui font doublon.

10. Minifier et différer le CSS et le JavaScript

La minification retire espaces et commentaires ; le chargement différé (defer) empêche les scripts de bloquer l’affichage. Avec LiteSpeed Cache, activez « Minifier CSS », « Minifier JS » et « Charger le JS en différé » ; laissez la combinaison des fichiers désactivée, peu utile en HTTP/2 et HTTP/3. Les options plus agressives (suppression du CSS inutilisé, JS reporté jusqu’à l’interaction) donnent de bons scores mais doivent être testées page par page.

11. Héberger les polices localement

Chaque police chargée depuis un service externe ajoute une connexion supplémentaire. Hébergez vos polices sur votre serveur au format WOFF2, limitez le nombre de graisses et utilisez font-display: swap pour afficher le texte immédiatement. Préchargez la police principale si elle sert au titre visible au chargement (bonnes pratiques sur web.dev) :

<link rel="preload" href="/wp-content/themes/mon-theme/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url("/wp-content/themes/mon-theme/fonts/inter.woff2") format("woff2");
  font-weight: 100 900;
  font-display: swap;
}
</style>

12. Limiter les scripts tiers

Outils de chat, pixels publicitaires, cartes, vidéos intégrées, widgets de réseaux sociaux : ces scripts viennent d’autres serveurs, échappent à votre cache et pèsent souvent sur l’INP. Faites l’inventaire, supprimez ceux qui ne servent plus, chargez les autres après le consentement ou après une interaction, et remplacez les vidéos intégrées par une simple image cliquable qui charge le lecteur à la demande. Voir le guide web.dev sur l’impact du JavaScript tiers.

Base de données et tâches planifiées : comment entretenir WordPress ?

Nettoyez régulièrement la base de données, limitez les révisions, surveillez les options chargées automatiquement et confiez les tâches planifiées à une vraie tâche cron du serveur plutôt qu’aux visites. Ces actions réduisent la charge du serveur et stabilisent les temps de réponse, surtout dans l’administration.

13. Nettoyer la base de données

Révisions d’articles, brouillons automatiques, commentaires indésirables et transients expirés s’accumulent avec le temps. Faites une sauvegarde, puis nettoyez-les avec l’outil de base de données de votre extension de performance (LiteSpeed Cache en propose un). Limitez ensuite le nombre de révisions conservées dans wp-config.php. Surveillez aussi l’outil Santé du site, qui signale un volume excessif d’options chargées automatiquement à chaque page.

// wp-config.php : au-dessus de la ligne « That's all, stop editing! »
define( 'WP_POST_REVISIONS', 10 );

14. Remplacer WP-Cron par une vraie tâche cron

Par défaut, WordPress déclenche ses tâches planifiées (publications programmées, e-mails, sauvegardes) lors des visites. Sur un site très fréquenté, cela ajoute des requêtes inutiles ; sur un site peu visité, les tâches partent en retard. La solution, décrite dans la documentation des développeurs WordPress : désactiver le déclenchement par les visites et appeler wp-cron.php à intervalle régulier depuis le planificateur du serveur (chez Hosterwise, la rubrique Cron Jobs de CyberPanel).

// wp-config.php
define( 'DISABLE_WP_CRON', true );
# Tâche cron du serveur (panneau de contrôle) : toutes les 5 minutes
*/5 * * * * wget -q -O - "https://www.example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

15. Profiter de HTTP/3, de la compression et, si besoin, d’un CDN

HTTP/2 et HTTP/3 chargent plusieurs fichiers en parallèle sur une seule connexion ; HTTP/3, basé sur QUIC, résiste mieux aux réseaux mobiles instables. Vérifiez aussi que le serveur compresse les fichiers texte (Brotli ou gzip). Enfin, si une part importante de vos visiteurs est loin de votre serveur, un CDN rapproche les fichiers statiques de ces visiteurs. Pour une audience essentiellement française servie depuis l’Europe, c’est rarement la priorité.

# Vérifier la compression et le protocole annoncés
curl -sI -H "Accept-Encoding: br, gzip" https://www.example.com/ | grep -i -E "content-encoding|alt-svc"

Par quoi commencer ? Les 15 actions classées

Commencez par ce qui a le plus d’effet pour le moins d’effort : cache de page, images, extensions. Gardez les réglages fins (CSS critique, JavaScript reporté) pour la fin, quand les bases sont en place et mesurées.

N°ActionIndicateur surtout amélioréEffort
1Hébergement adapté à WordPressTTFB, LCPChangement d’hébergeur
2Cache de pageTTFB, LCPFaible
3PHP récentTTFBFaible (tester avant)
4Cache d’objetTTFB (pages dynamiques)Faible si fourni
5Images compressées en WebP/AVIFLCPFaible
6Image LCP prioritaire, pas de lazy loadingLCPFaible
7Dimensions des images et emplacements réservésCLSFaible à moyen
8Thème légerLCP, INPÉlevé (refonte)
9Tri des extensionsTTFB, INPMoyen
10CSS/JS minifiés et différésLCP, INPFaible à moyen
11Polices locales, font-display: swapLCP, CLSMoyen
12Scripts tiers limitésINP, LCPMoyen
13Base de données nettoyéeTTFB (administration)Faible
14Vraie tâche cronCharge serveurFaible
15HTTP/3, compression, CDN si besoinLCPFaible à moyen
Les 15 actions et leur effet principal. L’ampleur du gain dépend de votre site : mesurez avant et après.

Comment savoir si vos optimisations ont fonctionné ?

Refaites les mêmes mesures qu’au départ, sur les mêmes pages et dans les mêmes conditions (mobile, navigation privée, cache chaud), et comparez. Pour les données de terrain, attendez quatre semaines et suivez le rapport Core Web Vitals de la Search Console, qui regroupe vos URL par état.

Gardez une trace de chaque changement et de sa date : si un indicateur se dégrade, vous saurez quoi annuler. Pour aller plus loin, la documentation officielle de WordPress sur l’optimisation des performances et le rapport Chrome UX Report expliquent d’où viennent les chiffres.

Un hébergement pensé pour la vitesse de WordPress

Les actions 1 à 4 et 15 dépendent largement de votre hébergeur. Chez Hosterwise, toutes les offres tournent sur des serveurs LiteSpeed Enterprise avec le cache LSCache, un cache d’objet Redis, HTTP/3 et des certificats SSL gratuits, ce qui couvre l’essentiel du travail côté serveur. Les offres Premium et Boost ajoutent des processeurs et de la mémoire pour les sites dynamiques comme WooCommerce : comparez-les sur la page tarifs ou découvrez notre hébergement WordPress LiteSpeed.

Votre site est ailleurs ? Nous le transférons pour vous avec la migration gratuite, selon la méthode décrite dans notre guide pour migrer un site WordPress sans coupure.

Questions fréquentes sur la vitesse de WordPress

Pourquoi mon site WordPress est-il lent ?

Les causes les plus fréquentes sont un hébergement surchargé ou sans cache, des images trop lourdes, un thème ou des extensions qui chargent beaucoup de code, et des scripts tiers. Commencez par mesurer le TTFB : s’il dépasse 0,8 seconde, cherchez du côté du serveur et du cache ; sinon, du côté des fichiers téléchargés.

Quelle extension utiliser pour accélérer WordPress ?

Sur un serveur LiteSpeed, LiteSpeed Cache est le choix logique, car il pilote le cache du serveur lui-même et regroupe la plupart des optimisations. Sur Apache ou Nginx, choisissez une extension de cache reconnue. N’en utilisez qu’une : deux extensions de cache actives en même temps se gênent.

Un bon score PageSpeed suffit-il ?

Non. Le score de laboratoire est un diagnostic ponctuel ; Google utilise surtout les données de terrain (Core Web Vitals des vrais visiteurs). Un score de 100 obtenu en retardant tout le JavaScript peut s’accompagner d’une mauvaise réactivité réelle. Visez de bons Core Web Vitals plutôt qu’un chiffre.

Le nombre d’extensions ralentit-il WordPress ?

Pas directement : quelques extensions mal conçues pèsent plus que beaucoup d’extensions légères. Ce qui compte, c’est le code chargé sur chaque page et les requêtes exécutées. Query Monitor permet de repérer les extensions coûteuses avant de décider lesquelles garder.

Faut-il un CDN pour un site WordPress français ?

Pas forcément. Si vos visiteurs sont surtout en France et votre serveur en Europe, un bon cache serveur et des images optimisées apportent plus qu’un CDN. Le CDN devient utile pour une audience internationale ou pour absorber de forts pics de trafic.

Changer d’hébergeur peut-il vraiment accélérer un site ?

Oui, quand le serveur est le goulot d’étranglement : TTFB élevé même sur une page en cache, PHP ancien, absence de cache serveur. Si le TTFB est déjà bon, le gain viendra plutôt des images, du thème et des scripts. Mesurez avant de décider.

À propos de l’auteur

L’équipe Hosterwise

Équipe technique et support de Hosterwise

Articles rédigés et relus par l’équipe technique de Hosterwise, qui administre au quotidien des serveurs LiteSpeed sous CyberPanel et accompagne les clients dans la migration, la sécurité et l’optimisation de leurs sites WordPress.

Voir les offres Mon compte