Configuration requise pour l'hébergement WordPress

WordPress lui-même demande étonnamment peu de ressources. Ce qui détermine l'offre dont vous avez réellement besoin, c'est tout ce que vous installez par-dessus, et l'écart entre ces deux réalités est l'endroit où la plupart des gens se trompent dans leur choix d'hébergement, dans un sens ou dans l'autre. Cette page distingue les deux : les exigences de la plateforme, qui sont fixes, et la question du dimensionnement, qui dépend entièrement de votre site.

Les exigences de la plateforme

Ce sont les versions publiées par WordPress.org, et c'est le minimum qu'un hébergeur doit atteindre avant que tout le reste ne compte :

Un hébergeur qui ne sait pas vous dire quelles versions de PHP et de base de données vous utilisez vous en dit déjà long. Ce sont les questions à poser avant de regarder le prix.

La limite de mémoire n'est pas celle que vous pensez

WordPress utilise deux réglages de mémoire, et les confondre est la cause de beaucoup de temps perdu en débogage. memory_limit dans PHP est le plafond strict défini par le serveur. WP_MEMORY_LIMIT dans wp-config.php est la valeur que WordPress demande à PHP, et elle ne peut pas dépasser le réglage de PHP.

Par défaut, WordPress demande 40 Mo pour les pages publiques et 256 Mo dans l'administration. C'est pourquoi un site peut sembler parfaitement sain pour les visiteurs et tomber dès que vous ouvrez l'éditeur d'extensions ou lancez un import. Si vous voyez un écran blanc ou une erreur « allowed memory size exhausted » dans l'administration mais pas sur le site, c'est la cause.

Portez WP_MEMORY_LIMIT à 256 Mo, et à 512 Mo si vous utilisez un constructeur de pages comme Elementor ou une boutique WooCommerce, qui dépassent régulièrement la valeur par défaut. Si l'augmentation ne change rien, le plafond PHP sous-jacent est inférieur à ce que vous avez demandé, et seul l'hébergeur peut le modifier.

Ce qui détermine réellement votre offre

Le cœur de WordPress est léger. Un site vitrine sur une pile bien mise en cache est vraiment peu exigeant. Trois éléments font varier les besoins, et aucun ne vient de WordPress :

• Extensions. Ce n'est pas leur nombre, c'est leur nature. Trente extensions légères peuvent coûter moins qu'un constructeur de pages, un scanner de sécurité et une extension de sauvegarde programmée. Tout ce qui s'exécute à chaque requête, ou via une tâche cron, est le type coûteux.
• Pages dynamiques. Une page en cache est servie sans solliciter PHP ni la base de données. Un panier WooCommerce, une session utilisateur connecté et une page de résultats de recherche ne peuvent pas être mis en cache : ils exécutent donc PHP et interrogent MySQL à chaque fois. Une boutique n'a rien à voir avec un blog ayant le même trafic.
• La simultanéité, pas les visites. Un mois de trafic en dit très peu. Ce qui dimensionne un serveur, c'est le nombre de requêtes non mises en cache qui arrivent dans la même seconde. C'est pourquoi un petit site qui envoie une newsletter peut tomber, alors qu'un site plus grand mais plus régulier ne tombe jamais.

Dimensionner l'offre

Chaque offre ici comprend un CPU, une RAM et un SSD dédiés, et non une part d'une machine surchargée. C'est cette différence qui se remarque réellement dans le temps d'affichage des pages. Les niveaux supérieurs ajoutent le cache objet Redis, qui compte surtout pour le travail non mis en cache décrit plus haut : c'est lui qui garde un paiement WooCommerce rapide quand la page elle-même ne peut pas être mise en cache.

Stockage : la bibliothèque de médias fait toute la différence

Une installation WordPress fait quelques dizaines de mégaoctets et la base de données d'un site classique est petite. Ce qui remplit un disque, ce sont les envois de fichiers, et plus précisément le fait que WordPress génère plusieurs copies redimensionnées de chaque image ajoutée. Un site de photographie ou une boutique avec un grand catalogue grossit bien plus vite que son nombre de pages ne le laisse penser, et les sauvegardes stockées sur le même disque doublent le total obtenu.

Les exigences que personne ne mentionne

Deux points méritent d'être mentionnés ici, même s'il ne s'agit pas de spécifications, car ils déterminent davantage les performances d'un site que toutes les versions citées plus haut.

Le premier concerne l'emplacement du serveur. La latence dépend de la distance : un site hébergé à l'autre bout d'un continent de ses lecteurs est plus lent pour chacun d'eux, quelle que soit la puissance du CPU. Choisir une région proche de votre audience ne coûte rien et surpasse souvent l'achat d'une offre plus grande.

Le second concerne ce qui se passe quand la machine tombe. En hébergement mutualisé, votre site fait partie de centaines d'autres sur un seul serveur, soit un point de défaillance unique qui porte votre nom. Sur Flux, un site est déployé sous forme d'instances redondantes réparties sur des nœuds indépendants : perdre une machine n'équivaut donc pas à perdre le site. C'est une exigence au sens le plus important : celle que l'on ne remarque que lorsqu'elle manque.

Vérifier ce que vous avez actuellement

Sur un site existant, vous n'avez pas besoin de deviner quoi que ce soit. WordPress vous l'indique : ouvrez Outils, puis Santé du site, puis l'onglet Informations. Il affiche votre version de PHP, la version de la base de données, la limite de mémoire PHP et les constantes définies dans wp-config.php. Si votre hébergeur est en retard sur PHP ou limite la mémoire en dessous de 256 Mo, cette page le signale clairement, et c'est l'audit le plus rapide dont vous disposez.

Questions fréquentes