Héberger WordPress pour des performances fluides, ce n'est pas cocher « serveur optimisé WordPress » chez un revendeur. C'est PHP récent, assez de CPU au pic, une base qui n'est pas sur un disque saturé, un cache de page, des images tenues, et une TMA qui ne laisse pas 40 plugins tout recalculer. Cet article sépare l'hébergement (ce que le serveur doit fournir) du site (ce que le thème et les extensions font). Les deux se tiennent. L'un ne rattrape pas l'autre.
🔎 Mesurer avant de changer d'hébergeur
TTFB de la home, LCP mobile, une page intérieure, une page produit si Woo. Si le TTFB est déjà à 2 secondes hors cache, l'hébergement ou le bootstrap PHP est en cause. Si le TTFB est bon et le LCP mauvais, ce sont les images, le JS, le thème. Changer d'hébergeur dans le second cas ne change rien. Dans le premier, alléger le site ne suffira pas non plus.
On mesure hors VPN exotique, en mobile, deux fois. On note si un cache de page est déjà là. Beaucoup de « WordPress lent » ont un cache éteint, ou un cache qui ignore les pages parce qu'un plugin met un cookie à tout le monde.
🛠️ PHP, workers, mémoire : le plancher
PHP 8.3 ou 8.4 (8.5 si vos extensions la supportent), OPcache, assez de workers pour le pic (pas seulement la moyenne). memory_limit réaliste. Un mutualisé à 1 € qui swap, aucun thème ne le sauve. Un VPS trop petit pour Woo plus un builder, non plus. L'hébergement WordPress fluide commence ici, pas sur la slide « SSD NVMe ».
La version PHP se tient avec les plugins. On ne passe pas à une version que Woo ou un module de paiement ignore. On le teste en préprod. Voir l'article local / préprod.
✅ Cache de page et object cache
Le cache de page (Nginx, plugin sérieux, Varnish selon l'infra) est le levier n°1 des vitrines. Les pages anonymes doivent sortir sans bootstrap WordPress complet. Les exceptions : tunnel, compte, panier. Mal configuré, on cache le panier d'un client chez un autre. Bien configuré, la home vole.
L'object cache (Redis, Memcached) aide l'admin et les pages dynamiques. Il ne remplace pas le cache de page. Les deux se cumulent. Un plugin de cache plus un second plugin de cache, ça se combat. Un seul, compris, documenté.
⚠️ Base de données et disque
Autoload wp_options gonflé, révisions infinies, transients morts : la base devient le TTFB. L'hébergement peut être bon. La base est sale. On la soigne en TMA (et dans l'article alléger WordPress). Inversement, une base propre sur un disque saturé de backups locaux reste lente.
Les backups ne doivent pas vivre sur le même disque que la prod, plein à 95 %. C'est un sujet d'hébergement et de sauvegardes qui restaurent. Les deux articles se répondent.
📌 HTTPS, HTTP/2, CDN, images
HTTPS correct, HTTP/2 ou 3, compression. Un CDN aide les fichiers statiques (images, CSS) surtout loin du serveur. Il n'accélère pas un TTFB PHP de 3 secondes. Les images : tailles réelles, formats modernes, pas 4000 px dans un hero. L'hébergement peut offrir un resize. Le rédacteur peut quand même envoyer un RAW. La TMA pose des garde-fous.
Les fonts : trop de familles, trop de poids. Ce n'est pas l'hébergeur. C'est le thème. On le dit, parce que beaucoup de devis « on change d'hébergeur » évitent de fâcher le thème premium.
🧭 Cron, mails, files : la perf invisible
wp-cron lancé par les visiteurs ralentit les pages. Un cron système, des files, un mailer qui n'ouvre pas une connexion SMTP à chaque hit : ça fait partie d'héberger WordPress pour la perf. Surtout WooCommerce, surtout les sites membres.
Les plugins de stats qui écrivent en base à chaque page vue tuent plus de sites que le choix entre deux datacenters. On les remplace par une sonde externe. L'hébergement respire.
💡 Mutualisé, VPS, managé : grille
Vitrine calme, thème mince : un bon mutualisé ou un petit managé suffit. Boutique, membres, pics : VPS ou managé WordPress avec workers connus, Redis, SSH. « Illimité » sur un mutualisé n'est pas un plan de perf. C'est un slogan.
Le managé coûte plus cher et enlève des libertés (parfois PHP, parfois cron). Il apporte des sauvegardes et un support. Lisez ce qui est inclus. Comparez à une TMA plus un VPS tenu. Les deux modèles marchent. Le modèle « pas cher, personne, 40 plugins » ne marche pas.
- PHP à jour, OPcache, workers dimensionnés au pic
- Un cache de page, un object cache, pas trois plugins
- Backups hors disque de prod
- Cron système, mails envoyés hors de la requête
🧪 Hébergement et site : la même TMA
Je n'optimise pas un thème sur un serveur à genoux. Je ne migre pas d'hébergeur un monstre Elementor en promettant le miracle. L'ordre : mesurer, corriger le plus gros (souvent cache + images + 10 plugins), puis l'infra si le TTFB reste mauvais.
Héberger WordPress pour des performances fluides est un couple site + serveur. Si vous voulez que je m'en charge, j'ai besoin des deux accès, pas seulement d'un FTP « pour le thème ».
🔎 Migrer d'hébergeur : quand ça vaut le dérangement
Quand le TTFB reste haut après cache et allègement, quand le support ne donne pas les workers, quand PHP est bloqué trop vieux, quand les backups ne se restaurent pas. Pas quand un commercial a promis « 400 % plus rapide ». On mesure avant, on clone, on bascule DNS, on garde l'ancien une semaine.
Héberger WordPress pour des performances fluides peut vouloir dire rester et soigner, ou partir. Les deux commencent par un chiffre, pas par une marque d'hébergeur à la mode.
🛠️ WooCommerce : le même sujet, en plus exigeant
Sessions, panier, admin sous charge, webhooks. Un hébergement « vitrine » lâche aux premières soldes. Workers, Redis, cron, mails : on les exige. L'audit avant campagne le vérifie. Un forfait TMA Woo sans regarder l'infra est un forfait incomplet.
La page produit a ses CWV (article dédié). L'hébergement lui donne le TTFB. Les deux se parlent. Ni l'un ni l'autre ne suffit.
Un hébergement « illimité » à 3 € n'est pas un socle. C'est un goulot.
