Quand on parle d’hébergement, on compare souvent la RAM, le nombre de vCPU ou le prix. Le serveur web, lui, passe sous le radar. Pourtant, c’est le premier logiciel qui reçoit chaque visite de votre site.
Sur un mutualisé, vous ne le choisissez pas. Mais dès que vous passez sur un VPS ou un serveur dédié, la question se pose : Apache, Nginx, Caddy, LiteSpeed ? Voici comment je les compare dans la pratique, sans faire de l’un ou l’autre une religion.
À quoi sert un serveur web, concrètement
Le serveur web reçoit la requête HTTP du navigateur, gère le HTTPS, puis fait l’une de ces deux choses :
- servir directement un fichier : une image, une feuille CSS, une page HTML statique ;
- passer la main à un programme qui génère la page : PHP pour WordPress ou PrestaShop, Node pour une application JavaScript, etc.
Un point souvent mal compris : sur une installation moderne, PHP ne tourne pas « dans » le serveur web. Il tourne à côté, dans un service séparé appelé PHP-FPM, et le serveur web lui transmet les requêtes. Une bonne partie des performances d’un site WordPress se joue donc dans le réglage de PHP-FPM, du cache et de la base de données, pas uniquement dans le choix du serveur web.
Gardez ça en tête pour la suite : le serveur web compte, mais il est rarement le goulot d’étranglement principal.
Apache : l’historique, toujours partout
Apache existe depuis le milieu des années 90 et reste extrêmement répandu, notamment chez les hébergeurs mutualisés.
Son grand atout : le fichier .htaccess. Chaque dossier du site peut contenir un petit fichier de configuration, modifiable sans accès root et sans redémarrer quoi que ce soit. C’est ce qui permet à WordPress d’écrire lui-même ses règles de permaliens, ou à une extension de sécurité d’ajouter des restrictions.
Voici le .htaccess standard de WordPress :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Le revers : quand les .htaccess sont autorisés, Apache doit chercher et relire ces fichiers dans chaque dossier du chemin, à chaque requête. Sur un petit site, c’est négligeable. Sur un site chargé, c’est du travail inutile.
Apache fonctionne aussi avec différents modes de traitement des connexions (les MPM : prefork, worker, event). Le mode prefork, encore croisé sur de vieilles installations avec mod_php, consomme beaucoup de mémoire dès que le trafic monte. Un Apache moderne en event avec PHP-FPM se comporte nettement mieux.
En résumé : compatible avec tout, très documenté, souple. Moins économe que Nginx en mémoire, surtout mal configuré.
Nginx : le standard des serveurs bien tenus
Nginx a été conçu pour encaisser beaucoup de connexions simultanées avec peu de ressources. Son architecture événementielle lui permet de gérer des milliers de connexions avec une consommation mémoire faible et stable.
C’est aujourd’hui mon choix par défaut sur un VPS, pour plusieurs raisons :
- il sert les fichiers statiques très efficacement ;
- il fait un excellent reverse proxy devant une application Node, Python ou un autre serveur ;
- son cache FastCGI permet de servir des pages WordPress déjà générées sans même solliciter PHP ;
- sa configuration est centralisée, lisible et versionnable.
Sa contrainte principale : pas de .htaccess. Toute la configuration se fait côté serveur, avec un accès root et un rechargement du service. Les règles fournies par WordPress, PrestaShop ou certaines extensions doivent donc être traduites à la main.
Le même WordPress, côté Nginx :
server {
listen 443 ssl;
http2 on;
server_name exemple.fr;
root /var/www/exemple;
index index.php;
# ssl_certificate / ssl_certificate_key : omis pour la lisibilité
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
}
Le fichier snippets/fastcgi-php.conf est fourni par les paquets Debian et Ubuntu ; sur d’autres distributions, les paramètres FastCGI s’écrivent directement dans le bloc.
C’est plus verbeux qu’un .htaccess, mais tout est au même endroit. Pour un serveur administré, c’est un avantage : personne ne peut modifier le comportement du serveur en déposant un fichier dans un dossier.
En résumé : performant, sobre, très répandu en production. Demande un minimum de compétences pour être configuré proprement.
Caddy : le HTTPS sans y penser
Caddy est plus récent et mise sur la simplicité. Sa fonctionnalité phare : le HTTPS automatique. Vous déclarez un nom de domaine, Caddy obtient le certificat, le renouvelle et redirige le HTTP vers le HTTPS. Sans Certbot, sans tâche cron, sans configuration supplémentaire.
Un site statique, par exemple un site Astro, tient en quelques lignes :
exemple.fr {
root * /var/www/exemple/dist
encode zstd gzip
file_server
}
Et un WordPress n’est pas beaucoup plus long :
exemple.fr {
root * /var/www/exemple
php_fastcgi unix//run/php/php8.3-fpm.sock
file_server
}
La directive php_fastcgi gère déjà la réécriture vers index.php attendue par WordPress.
Ses limites : l’écosystème est plus jeune. On trouve moins de retours d’expérience, moins de configurations toutes faites pour des applications PHP complexes, et certains réglages fins demandent de bien lire la documentation. Ce n’est pas un défaut rédhibitoire, mais c’est à prendre en compte sur un site critique.
En résumé : idéal pour un VPS simple, un site statique ou un reverse proxy rapide à mettre en place. Moins éprouvé sur les grosses applications PHP.
LiteSpeed : la performance compatible Apache
LiteSpeed est un serveur commercial pensé comme un remplaçant direct d’Apache : il lit les fichiers .htaccess et reprend une grande partie de sa configuration. C’est ce qui le rend populaire auprès des hébergeurs mutualisés, qui peuvent changer de moteur sans casser les sites de leurs clients.
Son vrai point fort, c’est LSCache, un cache intégré au serveur, couplé à des extensions dédiées pour WordPress, PrestaShop ou d’autres CMS. Bien configuré, il donne d’excellents résultats sur WordPress, sans empiler d’extensions de cache.
Deux nuances :
- LiteSpeed Enterprise est payant, avec une licence dont le prix dépend du nombre de domaines et de la mémoire du serveur ;
- OpenLiteSpeed, la version gratuite, ne lit dans les
.htaccessque les règles de réécriture, et seulement au redémarrage du service. Le reste de la configuration se fait via son interface d’administration.
En résumé : très bon choix chez un hébergeur qui le propose, surtout pour WordPress. Plus rarement pertinent à installer soi-même sur un VPS.
Le comparatif
| Critère | Apache | Nginx | Caddy | LiteSpeed |
|---|---|---|---|---|
| Fichiers statiques | Bon | Très bon | Très bon | Très bon |
| Consommation mémoire | Moyenne à élevée | Faible | Faible | Faible |
Support .htaccess |
Oui | Non | Non | Oui (Enterprise) |
| HTTPS automatique | Non | Non | Oui | Selon l’hébergeur |
| Cache intégré | Basique | FastCGI cache | Via modules | LSCache |
| Facilité de configuration | Moyenne | Moyenne | Très bonne | Bonne (interface) |
| Licence | Libre | Libre | Libre | Payante / libre (OpenLiteSpeed) |
Et le combo Nginx devant Apache ?
On croise encore souvent cette architecture : Nginx en façade, qui sert les fichiers statiques et gère le HTTPS, et Apache derrière, qui traite le PHP en conservant la compatibilité .htaccess.
Elle avait beaucoup de sens à l’époque où Apache tournait en prefork avec mod_php. Aujourd’hui, avec PHP-FPM, elle se justifie surtout dans deux cas :
- un hébergement mutualisé qui doit garder la compatibilité
.htaccesspour des centaines de clients ; - une migration progressive d’une ancienne configuration Apache complexe.
Sur un VPS dédié à un ou quelques sites, c’est généralement une couche de complexité en plus pour un gain faible. Deux serveurs à configurer, deux jeux de logs, deux sources de problèmes.
Ce que je choisis selon le projet
Site statique (Astro, HTML) : Caddy ou Nginx. Caddy si je veux une configuration minimale avec HTTPS automatique, Nginx si le serveur héberge déjà d’autres services configurés avec.
WordPress sur VPS : Nginx avec PHP-FPM et le cache FastCGI, ou un cache applicatif bien réglé. C’est la combinaison la plus éprouvée, la mieux documentée, et la plus économe.
PrestaShop sur VPS : Nginx également, avec les règles de réécriture adaptées. PrestaShop génère beaucoup de règles dans son .htaccess, il faut les traduire soigneusement et tester les URL de produits, de catégories et des modules.
Hébergement mutualisé : la question ne se pose pas, vous utilisez ce que l’hébergeur fournit. Si c’est du LiteSpeed, profitez de LSCache plutôt que d’ajouter une extension de cache concurrente.
Application Node ou Python : Nginx ou Caddy en reverse proxy devant l’application, qui ne doit jamais être exposée directement.
Le serveur web n’est pas le plus important
Changer d’Apache à Nginx ne transformera pas un site lent en site rapide. Les vrais gains viennent généralement d’ailleurs :
- un cache de pages correctement configuré ;
- PHP-FPM dimensionné selon la mémoire disponible ;
- une base de données saine, avec les bons index et sans tables qui débordent ;
- des images au bon format et à la bonne taille ;
- moins d’extensions inutiles.
C’est le même constat que dans mon article sur les Core Web Vitals : il vaut mieux corriger ce qui pèse vraiment que de chercher l’outil miracle.
Le bon serveur web, c’est surtout celui qui est bien configuré, maintenu à jour et surveillé. Un Apache propre vaut mieux qu’un Nginx copié-collé depuis un tutoriel de 2017.
En résumé
- Apache : universel et souple grâce au
.htaccess, plus gourmand. - Nginx : performant, sobre, le standard pour un VPS bien administré.
- Caddy : le plus simple à mettre en place, HTTPS automatique, idéal pour les sites statiques.
- LiteSpeed : excellent avec son cache intégré, surtout chez un hébergeur qui le propose.
Si vous avez un VPS et que vous ne savez pas exactement ce qui tourne dessus, ni comment il est configuré, c’est précisément le type de situation que je prends en charge dans mon offre d’infogérance serveur. Et si vous préférez ne pas gérer de serveur du tout, mon hébergement managé s’occupe de cette couche à votre place.