# PHP-FPM ou FrankenPHP classique : lequel choisir avant le mode worker > Comparatif entre PHP-FPM éprouvé et FrankenPHP en mode classique (sans worker) sur un même WordPress, pour les équipes qui hésitent avant de franchir le pas du mode worker. - Auteur : Clément Hadrot - Publié le : 2025-01-30 - Mis à jour le : 2025-01-30 - Catégorie : Performance - URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/php-fpm-frankenphp-classique-lequel-choisir/ ## L’essentiel - FrankenPHP en mode classique redémarre PHP à chaque requête comme PHP-FPM - Le gain vient surtout de la simplification d'infrastructure, pas de la vitesse brute - Le mode worker, plus rapide, demande une compatibilité applicative non garantie FrankenPHP, le serveur d'application PHP construit sur Caddy et sorti en version stable fin 2023, propose deux modes de fonctionnement bien distincts : un mode dit « classique », qui redémarre l'environnement PHP à chaque requête comme le fait PHP-FPM traditionnel, et un mode « worker », plus rapide mais qui garde l'application chargée en mémoire entre les requêtes, avec les risques de fuite d'état que cela implique sur un code qui n'a pas été conçu pour ça. Cet article compare PHP-FPM et FrankenPHP en mode classique uniquement, pour les équipes qui veulent évaluer un changement d'infrastructure sans prendre le risque du mode worker. ## Pourquoi comparer les deux en mode classique d'abord Le mode worker de FrankenPHP promet des gains de performance significatifs en gardant WordPress chargé en mémoire, mais il expose aussi aux mêmes catégories de bugs que Node.js ou tout runtime persistant : variables globales qui fuient d'une requête à l'autre, extensions tierces qui supposent un environnement PHP entièrement neuf à chaque exécution. Beaucoup d'extensions WordPress n'ont jamais été testées dans un tel contexte. Le mode classique, lui, conserve le modèle « une requête, un environnement PHP frais », exactement comme PHP-FPM, ce qui en fait une comparaison plus juste pour évaluer FrankenPHP sur ses seuls mérites d'architecture serveur, indépendamment du gain (et du risque) du mode worker. ## Le protocole de test Le test a été mené sur une installation WordPress identique (même thème, mêmes dix-huit extensions actives, même base de données de 40 000 articles), déployée successivement derrière Nginx + PHP-FPM 8.2, puis derrière FrankenPHP 1.1 en mode classique avec Caddy intégré, sur la même machine virtuelle pour éliminer les écarts matériels. La charge a été générée avec `k6`, cent utilisateurs virtuels pendant cinq minutes, sur un mélange de pages d'accueil, de pages produit et de recherches. > L'essentiel à retenir : FrankenPHP en mode classique redémarre PHP à chaque requête comme PHP-FPM ; Le gain vient surtout de la simplification d'infrastructure, pas de la vitesse brute ; Le mode worker, plus rapide, demande une compatibilité applicative non garantie ## Résultats de performance brute | Métrique | Nginx + PHP-FPM 8.2 | FrankenPHP 1.1 (classique) | | --- | --- | --- | | Requêtes par seconde | 312 | 329 | | Latence p95 | 420 ms | 398 ms | | Taux d'erreur sous charge | 0,2 % | 0,1 % | | Mémoire au repos | 180 Mo (PHP-FPM + Nginx) | 165 Mo (FrankenPHP + Caddy intégré) | Les écarts de performance brute restent modestes, de l'ordre de 5 à 6 % en faveur de FrankenPHP, ce qui n'a rien de spectaculaire et confirme qu'en mode classique, FrankenPHP redémarre bien l'environnement PHP à chaque requête, sans bénéficier du gain principal apporté par le mode worker. ## Là où l'écart devient net : la simplicité d'infrastructure Le véritable argument en faveur de FrankenPHP dans ce comparatif n'est pas la vitesse brute, mais la réduction du nombre de composants à maintenir. La configuration Nginx + PHP-FPM classique nécessite deux processus séparés à superviser, à mettre à jour et à faire communiquer via un socket ou un port, plus souvent un conteneur dédié à chacun dans une architecture Docker. FrankenPHP intègre un serveur web complet (basé sur Caddy) directement dans le même binaire que l'interpréteur PHP, ce qui a permis, sur ce projet conteneurisé, de passer de quatre conteneurs (Nginx, PHP-FPM, un conteneur de configuration partagée, un side-car de logs) à un seul conteneur FrankenPHP. ``` # Avant : docker-compose.yml avec Nginx + PHP-FPM séparés (extrait) services: nginx: image: nginx:1.25 volumes: [...] php-fpm: image: wordpress:php8.2-fpm volumes: [...] # Après : un seul service FrankenPHP services: frankenphp: image: dunglas/frankenphp:1-php8.2 volumes: [...] environment: - SERVER_NAME=:80 ``` ## Ce qui a demandé un ajustement Deux extensions du site ont nécessité un ajustement mineur de configuration liée aux en-têtes HTTP, FrankenPHP (via Caddy) gérant certains en-têtes par défaut différemment de la configuration Nginx historique du projet, en particulier sur la compression Brotli qui a dû être explicitement activée dans le `Caddyfile`. Rien de bloquant, mais un point à vérifier systématiquement lors d'une migration. ## Le verdict Pour une équipe qui gère une infrastructure conteneurisée complexe et cherche avant tout à simplifier son empreinte de déploiement, FrankenPHP en mode classique constitue un remplacement raisonnable de PHP-FPM, avec un gain de performance brute modeste mais réel et une réduction sensible du nombre de composants à opérer. Pour une équipe qui recherche avant tout la vitesse maximale et dispose des ressources pour valider la compatibilité de son code, le mode worker reste l'option la plus prometteuse, mais elle sort du périmètre de ce comparatif et mérite ses propres tests de non-régression applicative avant tout déploiement en production. > Changer de serveur d'application pour un gain de 5 % de débit ne se justifie pas seul ; le simplifier ses conteneurs de moitié, si. ## En résumé - FrankenPHP en mode classique offre des performances proches de PHP-FPM, légèrement meilleures mais pas transformatrices. - Le vrai gain observé est la simplification de l'infrastructure de déploiement. - Le mode worker, plus rapide, demande une validation de compatibilité applicative distincte et plus exigeante.