# FrankenPHP en mode worker pour WordPress : le test en conditions réelles

> Garder l'application WordPress chargée en mémoire entre les requêtes plutôt que de la redémarrer à chaque fois : le pari du mode worker de FrankenPHP, testé face à PHP-FPM classique.

- Auteur : Clément Hadrot
- Publié le : 2026-03-31
- Mis à jour le : 2026-03-31
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/frankenphp-mode-worker-wordpress-test-reel/

## L’essentiel

- Le mode worker élimine le coût de bootstrap de WordPress à chaque requête
- Certaines extensions gardent un état en mémoire entre les requêtes, avec des effets de bord réels
- La compatibilité des extensions reste plus incertaine qu'avec PHP-FPM, éprouvé depuis quinze ans

FrankenPHP est un serveur d'application PHP moderne, construit sur le serveur web Caddy, qui propose un mode dit « worker » : au lieu de démarrer un nouveau processus PHP à chaque requête comme le fait PHP-FPM classique, un script d'amorçage reste chargé en mémoire et traite plusieurs requêtes successives, à la manière d'un serveur Node.js ou d'une application Java de longue durée. L'argument de performance est net : éliminer le coût de démarrage (bootstrap) de WordPress à chaque requête, potentiellement le poste le plus coûteux sur une page simple.

## Comparatif face à PHP-FPM

| Critère | PHP-FPM classique | FrankenPHP mode worker |
| --- | --- | --- |
| Cycle de requête | nouveau bootstrap WordPress à chaque requête | application chargée une fois, réutilisée entre requêtes |
| Maturité | éprouvé depuis plus de quinze ans | récent, en évolution rapide |
| Compatibilité extensions | quasi universelle | à vérifier au cas par cas, état partagé possible |
| Complexité de déploiement | bien connue, largement documentée | plus simple sur le papier, moins de retours d'expérience |

## Protocole du benchmark

> L'essentiel à retenir : Le mode worker élimine le coût de bootstrap de WordPress à chaque requête ; Certaines extensions gardent un état en mémoire entre les requêtes, avec des effets de bord réels ; La compatibilité des extensions reste plus incertaine qu'avec PHP-FPM, éprouvé depuis quinze ans

Le test a porté sur un site vitrine avec blog, thème classique léger, sans WooCommerce ni extension complexe, pour isoler l'effet du serveur d'application plutôt que la charge propre à un site e-commerce. Chaque configuration a reçu 500 requêtes séquentielles sur trois types de page (accueil, article, page de contact avec formulaire), cache de page désactivé pour mesurer le temps de traitement PHP réel.

| Page | PHP-FPM | FrankenPHP worker | Gain |
| --- | --- | --- | --- |
| Accueil | 187 ms | 124 ms | 34 % |
| Article | 172 ms | 115 ms | 33 % |
| Contact (formulaire) | 198 ms | 141 ms | 29 % |

Le gain observé, autour de 30 à 34 % selon la page, correspond globalement au temps de bootstrap de WordPress mesuré isolément sur cette configuration (environ 55 ms), ce qui confirme que le mode worker élimine bien l'essentiel de ce coût fixe répété à chaque requête en mode classique.

## Le piège de l'état partagé

Le principal point de vigilance découvert pendant le test concerne les variables globales et les singletons qui, en PHP-FPM classique, sont naturellement réinitialisés à chaque nouvelle requête puisque le processus repart de zéro. En mode worker, l'application reste chargée en mémoire, donc toute variable globale non explicitement réinitialisée entre deux requêtes peut fuiter d'un visiteur à l'autre.

Sur le site de test, une extension de formulaire de contact stockait temporairement les données soumises dans une variable statique de classe, sans jamais la vider après traitement, provoquant dans de rares cas l'affichage des données du formulaire d'un visiteur précédent à un autre visiteur arrivé peu après sur la même page. Ce bug n'existe simplement pas sous PHP-FPM classique, chaque requête démarrant sur un état complètement vierge.

> Avant tout déploiement en mode worker, nous auditons désormais systématiquement le code des extensions actives à la recherche de variables statiques ou globales non réinitialisées. C'est le principal risque de compatibilité, invisible en test rapide mais bien réel en charge.

## Extensions et compatibilité

- Les extensions qui suivent les bonnes pratiques de WordPress, sans état persistant en dehors du cache d'objets officiel, fonctionnent généralement sans adaptation.
- Les extensions plus anciennes ou moins rigoureuses, utilisant des variables globales à la légère, demandent un audit avant migration.
- WooCommerce a montré, au moment du test, un fonctionnement globalement correct sur des scénarios simples, mais un audit approfondi reste recommandé avant un déploiement en production sur une boutique à fort trafic.

## Notre verdict

FrankenPHP en mode worker tient sa promesse de performance sur le cas testé, avec un gain proche du tiers du temps de réponse, cohérent avec l'élimination du bootstrap répété de WordPress. La compatibilité reste cependant le point qui appelle le plus de prudence : contrairement à PHP-FPM, éprouvé depuis quinze ans sur des millions de sites, le mode worker expose des classes de bugs nouvelles liées à l'état partagé, qui demandent un audit de code sérieux avant tout déploiement en production sur un site avec des extensions non maîtrisées.