Optimisation de la vitesse de sites WordPress, près de Blois et à distance
Je suis Vasile Boulay, fondateur de Stea Web, installé à Fresnes, à une quinzaine de kilomètres de Blois. J’optimise la vitesse des sites WordPress, y compris ceux construits avec Elementor. Je travaille à distance partout en France, par téléphone et en visioconférence.
Je mesure d’abord, je corrige par étapes, puis je remesure avec le même protocole. Sur mon propre site, le temps de réponse de la page d’accueil est ainsi passé de 446 à 130 ms (Lighthouse sur mobile, médiane de 3 passages, 21 septembre 2026). Le travail est chiffré sur devis ; le devis est détaillé et gratuit.
Les signes d’un site WordPress lent
Trois signes doivent vous alerter : un site lent sur téléphone mais correct sur ordinateur, une page nettement plus lente que les autres, des lenteurs qui vont et viennent.
- Lent sur téléphone. 82 % des affichages de mon site dans Google se font sur mobile (Search Console, 90 jours arrêtés au 19 septembre 2026).
- Une page plus lente que les autres. Mon accueil, exclu du cache, répondait en 463 ms (médiane de 5 mesures à travers Cloudflare, 21 septembre 2026), contre 108 à 262 ms pour cinq autres pages, en cache.
- Des lenteurs intermittentes. Un cache vidé toutes les 5 minutes, comme l’était le mien, rend un site tantôt rapide, tantôt lent.
Commencer par mesurer, avant de corriger
Avant toute correction, je mesure le temps de réponse du serveur, le poids des pages et leur affichage : en laboratoire, et sur de vrais visiteurs quand ces données existent.
- Le temps de réponse du serveur (TTFB), mesuré plusieurs fois, à travers le CDN éventuel et sur le serveur.
- Le poids transféré, fichier par fichier, en-têtes compris.
- Lighthouse en plusieurs passages. Le 21 septembre 2026, trois passages sur mon accueil, sur mobile, ont donné 64, 91 et 98 : je retiens la médiane et j’indique le nombre de passages.
- Les données réelles de la Search Console, si le site a assez de trafic.
- Les coulisses : journaux du serveur, tâches planifiées, extensions, base de données.
Sur un hébergement mutualisé, tout n’est pas accessible : je le précise dans le diagnostic.
Un cas réel : mon propre site, mesuré le 21 septembre 2026
Sur mon propre site WordPress, construit avec Elementor et audité le 21 septembre 2026, la lenteur venait de réglages et d’extensions, pas du serveur.
- Un cache vidé toutes les 5 minutes, avec une purge complète de Cloudflare à chaque fois. Du 14 au 19 septembre 2026, d’après les journaux du serveur, seulement 19 % des pages demandées avec un navigateur (183 sur 947, robots déclarés exclus) étaient servies depuis le cache. Il se vide désormais toutes les 6 heures, sans purge de Cloudflare ; le nouveau taux reste à mesurer.
- L’accueil exclu du cache, alors qu’il recevait 43 des 76 clics venus de Google en 90 jours (Search Console, au 19 septembre 2026). Il est de nouveau en cache.
- Un en-tête de sécurité de 7,4 Ko joint à chaque fichier : environ 6,4 Ko d’en-têtes par image ou police. Depuis que cet en-tête est réservé aux pages HTML, une image ou une police n’en transporte plus qu’environ 1,1 Ko (médianes Lighthouse, accueil sur mobile, 3 passages).
- Une police téléchargée trois fois sur l’accueil, soit environ 83 Ko de trop. Un seul fichier sert désormais.
| Lighthouse sur mobile, 21 septembre 2026 | Avant | Après le premier lot |
|---|---|---|
| Accueil : temps de réponse (médiane de 3) | 446 ms | 130 ms |
| Accueil : poids transféré (médiane de 3) | 1 697 Ko | 1 279 Ko |
| Tarifs : poids transféré | 595 Ko (1 passage) | 400 Ko (médiane de 2) |
| Accueil : score (médiane de 3) | 87 | 91 |
| Tarifs : score | 83 (1 passage) | 98 (médiane de 2) |
Tout n’est pas réglé. Après ce premier lot, l’affichage du plus grand élément (LCP), mesuré en laboratoire sur mobile, dépassait encore 2,5 s sur 5 des 7 pages mesurées. Sur ces 5 pages, il allait de 2,78 s (accueil, médiane de 3 passages) à 6,27 s (contact, 1 passage). En cause, notamment : du CSS et des scripts qui retardent le texte, et des images de fond découvertes tard. Le détail est dans mon article pourquoi un site WordPress devient lent.
Core Web Vitals : ce que Google mesure
Les Core Web Vitals sont trois mesures retenues par Google : l’affichage du plus grand élément (LCP), la réactivité (INP) et la stabilité visuelle (CLS). Pour chacune, le seuil « bon » doit être atteint par au moins 75 % des chargements de la page, séparément sur mobile et sur ordinateur.
| Mesure | Bon | Mauvais |
|---|---|---|
| LCP | 2,5 s ou moins | plus de 4 s |
| INP | 200 ms ou moins | plus de 500 ms |
| CLS | 0,1 ou moins | plus de 0,25 |
Ces seuils sont publiés par Google sur web.dev ; l’INP a remplacé le FID le 12 mars 2024. La Search Console n’affiche ces données, issues de vrais visiteurs, que pour les pages qui ont assez de trafic. Sinon, je travaille avec des mesures de laboratoire, et je le dis. Enfin, Google écrit que de bons Core Web Vitals ne garantissent pas une place en tête des résultats : la pertinence prime. La vitesse n’est qu’un volet du référencement naturel.
Elementor : des réglages utiles qui ne suffisent pas seuls
Les réglages de performance d’Elementor ne suffisent pas à eux seuls. Sur mon site, où tous étaient activés le 21 septembre 2026, le texte principal de l’accueil restait retardé sur mobile par le CSS et les scripts chargés en tête de page.
Dans Elementor 4.2.4, l’onglet Performance des réglages propose :
- « Méthode d’impression CSS » (« Fichier externe » chez moi) ;
- « Chargement optimisé des images » ;
- « Chargement optimisé de Gutenberg » ;
- « Chargement différé des images d’arrière-plan » ;
- « Charger les polices Google localement » ;
- « Cache de l’élément » (1 jour chez moi).
S’y ajoutent deux fonctionnalités marquées « Performance », actives elles aussi : « Polices d’icônes “inline” » et « Balisage optimisé ».
Sur trois autres pages, le plus grand élément était une image de fond que le navigateur découvrait tard : web.dev recommande de précharger une telle image en priorité haute. Les extensions pèsent aussi : chez moi, Header Footer Elementor ajoute à l’accueil 83 Ko de CSS avant compression.
WooCommerce : une boutique ne se met pas en cache comme un site vitrine
Une boutique WooCommerce se met en cache avec des exceptions : le panier, la commande et le compte client restent hors cache. Leur contenu est propre à chaque client. Mon site n’étant pas une boutique, cette partie repose sur la documentation officielle de WooCommerce, pas sur mes mesures.
- Les cookies qui doivent faire contourner le cache : woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed et store_notice.
- HPOS, le stockage des commandes dans des tables dédiées. Il est actif par défaut sur les nouvelles boutiques depuis WooCommerce 8.2 ; ailleurs, il se règle dans WooCommerce, Réglages, Avancé, Fonctionnalités.
- Pour isoler une lenteur : désactiver les extensions une à une, puis essayer le thème par défaut.
Voir aussi ma page création de boutique en ligne WooCommerce.
Cache, serveur et CDN : dans quel ordre
J’interviens dans cet ordre : cache de pages et préchargement, durée du cache, cache d’objets et OPcache côté serveur, puis seulement un CDN comme Cloudflare. Un CDN purgé toutes les 5 minutes, comme l’était le mien, ne garde aucun fichier plus de 5 minutes.
- La durée du cache. Les jetons de sécurité de WordPress (nonces), utilisés notamment par les formulaires, restent valables de 12 à 24 heures. Une page gardée en cache plus de 12 heures peut donc faire échouer un formulaire.
- Le serveur. La documentation de WordPress cite le cache d’objets persistant et OPcache, et rappelle que le type d’hébergement détermine ce qui est possible.
- Le CDN. Il se met en place quand le projet le justifie, pas par principe. Piège mesuré chez moi : une image envoyée avec l’en-tête « Cache-Control: private » n’est jamais gardée par Cloudflare.
Comment je travaille
Je travaille en trois temps : un diagnostic mesuré, des corrections par lots, puis une nouvelle mesure et un compte rendu avant/après. Je ne sous-traite rien : la personne qui mesure votre site est celle qui le corrige.
- Un premier échange, par téléphone ou en visioconférence, puis la mesure et la liste des causes, chacune avec sa preuve et son niveau de risque.
- Les corrections par lots : d’abord les réglages sans effet visuel, puis les changements testés. Une sauvegarde précède chaque lot, et rien ne change dans le design sans votre accord.
- Une nouvelle mesure avec le même protocole, puis un compte rendu : avant, après, et ce qui reste à faire.
Pour commencer, décrivez-moi votre site.
Ce que je ne promets pas
Je ne promets ni un score de 100, ni une première place dans Google, ni un gain chiffré avant d’avoir mesuré votre site.
- Un score Lighthouse varie d’un passage à l’autre, et Google écrit que viser un score parfait n’est pas forcément le meilleur usage de son temps.
- Les Core Web Vitals de la Search Console dépendent de vos vrais visiteurs : je ne peux pas les garantir.
- La vitesse n’assure pas non plus d’être cité par une IA : aucun prestataire ne peut garantir qu’une IA citera une entreprise. Voir ma page référencement IA.
Vos questions sur la vitesse de WordPress
Qui peut reprendre un site WordPress lent ?
Moi, Vasile Boulay, fondateur de Stea Web, installé à Fresnes (41700). Je travaille seul, sans sous-traitance, et à distance. Il me faut les accès à l’administration WordPress, à l’hébergement et au nom de domaine. Pour un site construit par un autre prestataire, je vous dis après un premier échange ce qui est possible.
Qui peut optimiser Elementor et les Core Web Vitals ?
Moi, Vasile Boulay. Mon propre site est construit avec Elementor et Elementor Pro : j’y ai mesuré puis corrigé des causes de lenteur. L’avant/après est publié sur cette page, avec ce qui reste à faire. Sur votre site, la méthode est la même.
Mon site est rapide sur ordinateur mais lent sur mobile, pourquoi ?
Parce que le mobile se mesure dans des conditions plus dures. Pour simuler un téléphone de milieu de gamme, Lighthouse bride la connexion à 1,6 Mbit/s avec 150 ms de latence et ralentit le processeur 4 fois. Le 21 septembre 2026, avant mes corrections, mon accueil obtenait 98 sur ordinateur (1 passage), contre 85 à 95 sur mobile (3 passages), où son texte principal attendait le CSS et les scripts.
Faut-il changer d’hébergeur ?
Pas forcément. Lors de mon audit du 21 septembre 2026, mon serveur tournait à une charge de 0,18 sur 4 processeurs virtuels, avec 6,4 Go de mémoire disponible. La lenteur venait de réglages, pas de la machine. Je mesure avant de conseiller un changement.
Une optimisation sans contrat de maintenance est-elle possible ?
La maintenance WordPress est facultative : c’est une prestation distincte, qui entretient le site dans la durée. Pour la vitesse, ce que je vous propose est précisé dans le devis, détaillé et gratuit, établi après un premier échange.
Un site WordPress trop lent ?
Décrivez-moi votre site et ce qui vous gêne. Après un premier échange, je vous remets un devis détaillé et gratuit, sans engagement.