En resumen: el PHP JIT (compilador Just-in-Time) traduce a código máquina, durante la ejecución, el código PHP que se ejecuta con frecuencia. Llegó con PHP 8.0, forma parte de OPcache y desde PHP 8.4 está desactivado por defecto. Las tareas que requieren mucho cálculo se aceleran de forma notable; los sitios web típicos como WordPress, apenas. La mayor ganancia la aportan OPcache, una versión actual de PHP y una gestión de procesos bien ajustada, y cada versión actual trae además las correcciones de seguridad necesarias.
¿Qué es el compilador JIT en PHP?
PHP es un lenguaje interpretado: el código fuente se traduce primero a bytecode, los llamados opcodes, y la Zend Engine los ejecuta. Un JIT va un paso más allá. Observa qué secciones de código se ejecutan a menudo y traduce justo esas a código máquina para el procesador. A partir de entonces se ejecutan sin el rodeo del intérprete.
El RFC de su introducción describe el JIT como una parte casi independiente de OPcache. El código máquina generado se guarda en una zona adicional de la memoria compartida de OPcache. Con PHP 8.4, el proyecto reconstruyó el JIT; según la página de la versión, la nueva implementación se basa en el framework IR, una representación intermedia común para la generación de código. Cómo trabaja el motor por debajo lo explica la Zend Engine.
Primero OPcache: la verdadera base del rendimiento
Sin OPcache, PHP vuelve a traducir cada archivo en cada petición. OPcache conserva el bytecode en la memoria compartida para que todos los workers lo reutilicen. Para un sitio web con sistema de gestión de contenidos es, con diferencia, la palanca más importante. Desde PHP 8.5, OPcache está compilado de forma permanente en PHP según el RFC aprobado; los ajustes ini conocidos siguen controlando si la caché está activa.
Valores por defecto importantes según el manual: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 y opcache.revalidate_freq=2. Con el último ajuste, OPcache comprueba como máximo cada dos segundos si los archivos han cambiado. Quien desactiva validate_timestamps debe vaciar la caché o reiniciar PHP tras cada despliegue. Más información en OPcache explicado.
Configurar el PHP JIT: modos y ajustes
El JIT se controla con dos directivas:
| Directiva | Valor por defecto desde 8.4 | Valor por defecto antes de 8.4 | Significado |
|---|---|---|---|
opcache.jit |
disable |
tracing |
Modo del JIT |
opcache.jit_buffer_size |
64M |
0 |
Memoria para el código máquina generado; 0 desactiva el JIT |
Para opcache.jit, el manual conoce estos valores: disable (totalmente desactivado, no se puede activar en tiempo de ejecución), off (desactivado, pero activable en tiempo de ejecución), tracing o on (recomendado para la mayoría de los usuarios) y function. Además existe una notación numérica de cuatro cifras para ajustes finos.
; Activar el JIT de forma selectiva, p. ej. para workers con mucho cálculo
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Si el JIT está funcionando lo muestra el estado de OPcache:
php -i | grep -i "opcache.jit" # ajustes de la CLI
php --ri "Zend OPcache" # configuración de la extensión OPcache
Tenga en cuenta que la línea de comandos puede usar ajustes distintos de los de PHP-FPM. Para el funcionamiento web cuenta la salida de phpinfo() en el contexto de FPM, idealmente consultada solo internamente y retirada después.
¿Qué aporta el JIT en la práctica?
Los autores del RFC midieron: el script sintético bench.php se ejecutó con JIT más de dos veces más rápido. En aplicaciones reales la ganancia fue pequeña; WordPress alcanzó 326 en lugar de 315 peticiones por segundo y el analizador de PHP fue unas 1,3 veces más rápido. El RFC dice abiertamente que el JIT no acelera de forma notable aplicaciones reales como WordPress.
El motivo está en el perfil de las aplicaciones web típicas. Pasan la mayor parte del tiempo esperando a la base de datos, al sistema de archivos o a servicios externos. Un camino más rápido en el procesador ayuda poco ahí. En cambio, pueden beneficiarse el procesamiento de imágenes en PHP, los cálculos matemáticos, los analizadores o los workers de larga duración.
Rendimiento sin JIT: las palancas más eficaces
Para sitios web corporativos y tiendas compensa este orden:
- Versión actual de PHP: las versiones nuevas traen optimizaciones y, sobre todo, correcciones de seguridad.
- Dimensionar bien OPcache: memoria suficiente y espacio para todos los archivos de la aplicación.
- Ajustar PHP-FPM con criterio: adaptar
pm.max_childrena la memoria disponible, en lugar de subirlo a ciegas. - Revisar la base de datos: encontrar las consultas lentas, crear índices.
- Caché a nivel de aplicación: caché de páginas o de objetos, donde el sistema lo admita.
- Medir en lugar de adivinar:
request_slowlog_timeouten PHP-FPM escribe un backtrace en el slowlog para las peticiones lentas.
JIT, rendimiento y seguridad
El rendimiento y la seguridad están más relacionados de lo que parece. Primero: cada componente adicional es código adicional. El RFC de su introducción menciona él mismo el riesgo de errores en el JIT, en la generación de código y en la asignación de registros, así como la mayor dificultad para depurarlos. Quien no necesita el JIT de forma medible, lo deja en el valor por defecto disable.
Segundo: OPcache y los workers mantienen código en memoria. Tras una actualización de seguridad como la de PHP2Shell, los procesos antiguos siguen ejecutándose con el código antiguo hasta que se reinician. Vaciar la caché por sí solo no sustituye a ese reinicio, porque las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están en el propio binario de PHP.
Tercero: la mejor ganancia de rendimiento, una versión actual, es a la vez la medida de protección más importante. PHP 8.2 llega el 31/12/2026 al final del soporte; quien cambia ahora a 8.4 u 8.5 gana en ambos aspectos. Cómo mantenemos los sistemas rápidos y reforzados a largo plazo lo describe el refuerzo del servidor para servidores web PHP.
¿Cómo ayuda PHP SOS en concreto?
- Análisis del estado actual: leemos los ajustes de OPcache, JIT y FPM y los comparamos con la carga y la memoria.
- Medir los cuellos de botella: con el slowlog y las métricas del servidor encontramos dónde se pierde realmente el tiempo.
- Configurar con seguridad: JIT solo donde demostrablemente ayuda; OPcache de modo que los despliegues y las actualizaciones surtan efecto correctamente.
- Planificar las actualizaciones: cambios de versión con prueba y reinicio documentado, para que la velocidad y el estado de los parches sean los correctos.
Preguntas frecuentes
¿Está activo el JIT en PHP por defecto?
Desde PHP 8.4, ya no: el valor por defecto de opcache.jit es disable. Antes estaba predefinido tracing, pero el búfer opcache.jit_buffer_size estaba en 0, por lo que el JIT tampoco funcionaba.
¿Hace el JIT que WordPress sea más rápido?
Apenas. Ya en el RFC de su introducción, los autores escriben que el JIT no acelera de forma notable aplicaciones reales como WordPress. Su valor medido subió de 315 a 326 peticiones por segundo.
¿Necesito OPcache si no uso el JIT?
Sí. OPcache guarda el bytecode traducido en la memoria compartida y ahorra recompilar en cada petición. Para casi cualquier sitio web PHP es la palanca de rendimiento más importante. Desde PHP 8.5, OPcache está integrado de forma permanente en PHP.
¿Es el JIT un riesgo de seguridad?
Más código significa más posibles fallos. El RFC de su introducción menciona él mismo el riesgo de errores en el JIT y la mayor dificultad para depurarlos. Quien no lo necesita, lo deja desactivado; quien lo usa debería aplicar las actualizaciones con especial rapidez.