php -v annonce PHP 8.3.0 depuis quelques jours à peine. Sur un site WordPress qui tourne avec quarante extensions actives — plugin de caisse, moteur de recherche facetté, connecteur CRM, générateur de PDF, suite SEO complète — la question n’est pas academique : est-ce que le JIT de PHP, disponible depuis la 8.0 mais resté largement sous-exploité en environnement WordPress, apporte enfin quelque chose de mesurable ?
La réponse tient en une phrase qui va décevoir les amateurs de gains spectaculaires : oui, mais modestement, et à condition d’avoir déjà réglé OPcache correctement en amont. Ce billet détaille la méthode de mesure et les chiffres obtenus sur ce site en particulier, pas une promesse universelle.
Pourquoi le JIT profite peu à un site WordPress classique
Le JIT (Just-In-Time compilation) transforme certains chemins de code PHP en code machine natif à l’exécution, ce qui accélère les calculs intensifs : boucles numériques, traitement d’images en pur PHP, sérialisation massive. Or l’essentiel du temps de réponse d’une page WordPress ne se passe pas dans du calcul CPU pur : il se passe dans des appels à la base de données (wpdb), des lectures de cache, des appels réseau vers des API tierces. Ces opérations restent limitées par les I/O, un domaine où le JIT n’a strictement rien à apporter.
C’est la raison pour laquelle la documentation officielle de PHP reste prudente sur les gains attendus en environnement web classique, à la différence des scripts de calcul scientifique où les écarts peuvent dépasser 50 %.
Le protocole de mesure retenu
Pour éviter de mesurer du bruit, le protocole a comparé quatre configurations sur le même serveur, la même base de données, le même jeu de quarante extensions actives, avec dix mille requêtes générées par k6 sur un panier de dix URL représentatives (accueil, fiche produit, panier, recherche, page CPT lourde en métadonnées) :
- PHP 8.1 sans JIT (référence de départ, version précédemment en production) ;
- PHP 8.3 sans JIT (
opcache.jit = disable) ; - PHP 8.3 avec JIT en mode tracing (
opcache.jit = tracing, réglage recommandé pour un usage web) ; - PHP 8.3 avec JIT et un
opcache.jit_buffer_sizeaugmenté à 256M contre les 64M utilisés par défaut dans le test précédent.
; php.ini de test
opcache.enable=1
opcache.jit_buffer_size=256M
opcache.jit=tracing
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
Les chiffres obtenus
| Configuration | Temps de réponse moyen | P95 |
|---|---|---|
| PHP 8.1, sans JIT | 318 ms | 612 ms |
| PHP 8.3, sans JIT | 287 ms | 540 ms |
| PHP 8.3, JIT tracing, buffer 64M | 274 ms | 519 ms |
| PHP 8.3, JIT tracing, buffer 256M | 270 ms | 498 ms |
Le passage de PHP 8.1 à PHP 8.3, JIT non activé, apporte à lui seul près de 10 % de gain — un effet des optimisations internes successives du moteur Zend, indépendant du JIT. Activer le JIT ensuite ramène un gain supplémentaire d’environ 6 % sur le temps moyen, et davantage sur le P95, ce qui suggère que le JIT aide surtout à absorber les pages les plus lourdes en calcul (agrégations de métadonnées, génération de miniatures à la volée).
Le piège du buffer sous-dimensionné
Avec un opcache.jit_buffer_size laissé à sa valeur par défaut, le JIT sature rapidement son espace de compilation sur un site à quarante extensions : chaque extension apporte son lot de fonctions candidates à la compilation, et un buffer trop petit force PHP à revenir régulièrement à l’interprétation classique en cours de route. Passer le buffer à 256M a permis de stabiliser le gain plutôt que de le voir fluctuer d’une exécution à l’autre.
Ce qui compte plus que le JIT lui-même
Le tableau ci-dessus cache une évidence : le saut le plus net vient du passage de version PHP et d’OPcache bien configuré, pas du JIT. Sur ce site, désactiver purement et simplement opcache.validate_timestamps en production (avec un rechargement explicite via opcache_reset() au déploiement) a eu plus d’impact cumulé sur la durée qu’activer le JIT.
Le JIT est un bonus qui se prend après avoir fait ses devoirs sur OPcache, pas un raccourci pour éviter de les faire.
Verdict pour ce site
Le JIT a été conservé en production, en mode tracing avec un buffer de 256 Mo, parce que le gain, bien que modeste, ne coûte rien en stabilité une fois le buffer correctement dimensionné. Aucune extension parmi la quarantaine testée n’a présenté d’incompatibilité ou de comportement erratique avec le JIT activé, ce qui n’était pas garanti à l’avance vu l’hétérogénéité du parc.
Pour un site à dominante I/O — beaucoup d’appels à des API externes, peu de calcul PHP pur — le gain resterait probablement dans la même fourchette basse. Le JIT mérite un test chiffré propre à chaque site, pas une adoption sur la seule foi du changelog.
