La aparición de TypePHP plantea una pregunta interesante para WordPress: ¿sería posible compilar el CMS, o al menos algunas de sus partes más costosas, a código máquina y reducir así parte del trabajo que realiza PHP en cada petición? La idea tiene atractivo técnico, pero hoy existe un obstáculo importante: TypePHP todavía no es compatible con todo el lenguaje PHP que utiliza WordPress, y no hay por ahora una prueba pública documentada que demuestre que WordPress completo pueda compilarse y ejecutarse con este nuevo compilador AOT.
Las claves de TypePHP y WordPress en 30 segundos
La posibilidad merece ser estudiada porque WordPress continúa dependiendo de PHP para una enorme cantidad de operaciones. WordPress.org recomienda actualmente PHP 8.3 o superior, junto con MariaDB 10.11 o MySQL 8.0 como base moderna para nuevas instalaciones.
TypePHP parte precisamente del otro lado de esa ecuación. En lugar de esperar a que Zend Engine procese los opcodes de PHP durante la ejecución, el compilador de Swoole transforma previamente determinado código PHP en C++17 y posteriormente en instrucciones nativas.
El proyecto puede producir ejecutables, bibliotecas compartidas y, probablemente lo más interesante para WordPress, extensiones PHP .so o .dll que pueden cargarse desde PHP-FPM.
La cuestión es determinar hasta dónde podría aprovecharse esta arquitectura en un CMS diseñado desde hace más de dos décadas alrededor de la flexibilidad dinámica de PHP.
La primera tentación sería descargar WordPress, apuntar TypePHP hacia el código fuente y generar un único binario.
Con el estado actual de TypePHP, esa aproximación probablemente encontraría problemas muy pronto.
Uno de ellos está en el propio arranque de WordPress. wp-settings.php, uno de los archivos centrales del proceso de bootstrap, ejecuta directamente numerosas instrucciones en el ámbito global: define constantes, incluye archivos, inicializa servicios, ejecuta funciones y decide qué componentes cargar dependiendo de la configuración.
TypePHP mantiene actualmente una restricción bastante clara: el ámbito global debe contener declaraciones y no código ejecutable. El código que vaya a ejecutarse debe encontrarse dentro de funciones o métodos. En modo binario también exige una función global main().
Eso choca directamente con la arquitectura tradicional de WordPress.
El ejemplo más sencillo puede verse incluso en wp-config.php, cuyo flujo normal termina ejecutando:
require_once ABSPATH . 'wp-settings.php';Lenguaje del código: PHP (php)WordPress utiliza además de forma intensiva require, variables globales y carga condicional de componentes durante el bootstrap.
No significa que sea técnicamente imposible adaptar WordPress. Significa que no parece posible tomar hoy una instalación estándar y convertirla en un binario TypePHP sin modificaciones relevantes.
A esto hay que añadir uno de los elementos que hacen WordPress tan extensible: su sistema de hooks.
Funciones como:
add_action()
add_filter()
apply_filters()
do_action()permiten que plugins y temas registren callbacks que WordPress desconoce cuando se escribió el núcleo.
El propio WP_Hook termina ejecutando callbacks almacenados dinámicamente mediante funciones como call_user_func() y call_user_func_array().
TypePHP puede mantener determinadas llamadas dinámicas mediante su capa PHPX y el runtime Zend, pero su documentación deja claro que las llamadas dinámicas no están garantizadas como rutas nativamente optimizadas. También existen restricciones alrededor de closures, referencias y otras operaciones que dificultan la compilación estática de aplicaciones altamente dinámicas.
Esto es importante porque WordPress depende precisamente de ese dinamismo para que un plugin instalado mañana pueda modificar el comportamiento del CMS sin recompilar todo el sistema.
WordPress está diseñado para descubrir buena parte de su comportamiento durante la ejecución.
TypePHP puede obtener sus mayores ventajas cuando conoce durante la compilación:
WordPress, en cambio, permite que plugins, temas, drop-ins y configuraciones alteren ese flujo.
Esa diferencia no invalida TypePHP para WordPress, pero probablemente desplaza la pregunta.
En vez de plantear:
¿Puede compilarse todo WordPress?
quizá resulte más productivo preguntar:
¿Qué partes de una instalación WordPress podrían compilarse sin romper su modelo dinámico?
Ahí la propuesta empieza a resultar más interesante.
TypePHP puede generar una extensión PHP:
bin/tpc.php extension/ -m ext -o my_extensionEsa extensión puede cargarse posteriormente dentro del PHP utilizado por PHP-FPM. La documentación del proyecto presenta precisamente este modo como una forma de integrar código compilado con aplicaciones PHP existentes.
Esto abre una vía que, para WordPress, parece mucho más razonable que intentar compilar todo wp-admin, wp-includes, plugins y temas.
Un plugin podría mantener su integración habitual con WordPress en PHP:
add_filter( 'the_content', 'mi_funcion' );Lenguaje del código: JavaScript (javascript)mientras delega una operación pesada a una función compilada.
Conceptualmente:
| Parte | Ejecución posible |
|---|---|
| Bootstrap de WordPress | PHP convencional |
| Hooks y plugins | Zend PHP |
| Consultas MySQL | MySQL/MariaDB |
| Caché de objetos | Redis/Memcached u otro backend |
| Código intensivo de CPU | TypePHP AOT |
| Algoritmos numéricos | TypePHP AOT |
| Procesamiento masivo | TypePHP AOT |
| Extensión especializada | Binario nativo cargado por PHP |
Este modelo conservaría la compatibilidad de WordPress allí donde el dinamismo es necesario y reservaría la compilación para aquello que realmente puede beneficiarse de ella.
Hay algunos ejemplos potenciales claros.
Un plugin que procese grandes catálogos de WooCommerce podría tener rutinas de cálculo intensivas.
Un sistema de importación puede transformar cientos de miles de registros.
Un plugin de analítica puede agregar grandes cantidades de datos.
Una aplicación sobre WordPress puede generar imágenes, procesar documentos, realizar cálculos de precios, clasificar información o transformar grandes estructuras en memoria.
Un proceso WP-CLI puede recorrer millones de registros.
En estas situaciones el cuello de botella sí podría encontrarse en CPU y estructuras PHP.
Ahí TypePHP tiene argumentos más interesantes.
El proyecto publica un benchmark en el que su std::array tipado tarda 6,4 segundos frente a 67,6 segundos de un array PHP con JIT en una carga específica de actualizaciones masivas. También publica resultados de aproximadamente 8 veces y 6,5 veces de mejora en bench.php y micro_bench.php, respectivamente. Son mediciones del propio proyecto y no deben extrapolarse directamente a WordPress.
Este es probablemente el matiz más importante.
Aunque TypePHP pueda acelerar diez veces un bucle determinado, eso no significa que una página de WordPress vaya a responder diez veces más rápido.
El tiempo de generación de una página puede repartirse entre numerosos componentes:
| Operación | ¿TypePHP podría ayudar directamente? |
|---|---|
| Consultas MySQL | Poco |
| Espera de APIs externas | No |
| Acceso a almacenamiento | Poco |
| Consultas DNS/red | No |
| Redis u object cache | Poco |
| Ejecución de PHP | Sí |
| Bucles intensivos | Sí |
| Cálculos numéricos | Sí |
| Manipulación masiva de datos | Potencialmente sí |
| Código dinámico de plugins | Depende |
Si una petición tarda 500 milisegundos y únicamente 50 se consumen realizando trabajo computacional PHP, multiplicar por diez el rendimiento de esos 50 milisegundos nunca convertirá el total en 50 milisegundos.
Por eso cualquier prueba seria tendría que empezar con profiling.
Herramientas como Xdebug, Blackfire, Tideways o perfiles de PHP pueden localizar dónde consume realmente CPU una instalación antes de decidir qué merece ser compilado.
La prueba más interesante no sería intentar inmediatamente compilar todo WordPress.
Tendría más valor seleccionar una carga WordPress reproducible y separar distintas fases.
Por ejemplo, podría utilizarse una instalación actual con:
Después podrían compararse tres escenarios:
| Escenario | Configuración |
|---|---|
| A | PHP + OPcache |
| B | PHP + OPcache + JIT |
| C | PHP + OPcache + función crítica compilada con TypePHP |
Las métricas deberían incluir al menos tiempo de CPU, tiempo total de respuesta, requests por segundo, consumo de memoria, p95/p99 y utilización del procesador.
Y habría que realizar otra prueba completamente distinta con una página WordPress típica.
Es posible que allí la diferencia fuera mucho menor.
Eso sería tan interesante como encontrar una gran mejora, porque permitiría conocer dónde termina siendo útil la compilación AOT dentro de WordPress.
En la revisión realizada para este artículo no se ha localizado un proyecto público documentado que haya conseguido compilar y ejecutar WordPress completo mediante TypePHP.
Tampoco aparece WordPress como ejemplo oficial del proyecto.
La documentación sí incluye ejemplos de generación de ejecutables y extensiones y menciona otras aplicaciones PHP como ejemplos de los distintos modos de compilación, pero no demuestra compatibilidad completa con WordPress.
Esto deja la cuestión abierta.
Y probablemente sea todavía pronto para sacar conclusiones. TypePHP se encuentra bajo desarrollo activo y su propio equipo advierte de que soporta deliberadamente un subconjunto definido de PHP, en lugar de prometer compatibilidad inmediata con cualquier aplicación PHP existente.
La situación podría cambiar si el compilador amplía su compatibilidad.
También podría aparecer un enfoque híbrido específicamente diseñado para WordPress: mantener el bootstrap y el sistema de plugins sobre Zend y compilar determinadas funciones de core o componentes seleccionados como una extensión.
Eso evitaría uno de los mayores problemas de un WordPress completamente compilado: qué hacer cada vez que se instala o actualiza un plugin.
Si todo estuviera incorporado en un único binario AOT, cada modificación podría obligar a recompilar. Esa idea casa mal con un CMS en el que plugins y temas pueden instalarse desde el panel y empezar a ejecutarse inmediatamente.
Una extensión para acelerar funciones concretas tendría un modelo operativo bastante más compatible con la forma en que WordPress funciona hoy.
TypePHP tampoco debería verse únicamente como sustituto del JIT.
En WordPress, OPcache continúa siendo una de las mejoras básicas de rendimiento de PHP, mientras que el JIT no siempre aporta grandes beneficios en aplicaciones web dominadas por I/O y consultas de base de datos. TypePHP podría encontrar su espacio precisamente donde el JIT tampoco resuelve completamente el problema: código conocido de antemano, intensivo en CPU y suficientemente estable para justificar una compilación previa.
Hay por tanto una prueba que todavía merece hacerse.
No necesariamente «compilar WordPress».
Más bien tomar una instalación real, perfilarla, localizar una función costosa, compilar esa parte con TypePHP y medir qué cambia de verdad.
Si el experimento muestra mejoras importantes, podría aparecer una vía nueva para acelerar determinados plugins y aplicaciones construidas sobre WordPress sin abandonar PHP.
Si apenas cambia el rendimiento, también quedaría demostrado algo útil: que el principal límite de esa carga WordPress estaba en la base de datos, la caché, la red o cualquier otra parte de la arquitectura.
No hay actualmente una implementación pública documentada que demuestre que WordPress completo funciona compilado mediante TypePHP. Además, varias características actuales de WordPress chocan con las restricciones que mantiene el compilador AOT.
Potencialmente sí en código intensivo de CPU. Las mejoras serían previsiblemente mucho menores cuando el tiempo de respuesta esté dominado por MySQL, APIs externas, almacenamiento o red.
Es una de las posibilidades más interesantes. TypePHP puede generar extensiones PHP, de forma que un plugin podría conservar su integración habitual con WordPress y delegar determinadas operaciones pesadas en funciones compiladas.
No necesariamente. OPcache acelera el modelo PHP convencional almacenando bytecode ya compilado, mientras que TypePHP realiza compilación AOT a código nativo. Para WordPress podrían llegar a utilizarse en áreas diferentes de una misma instalación.
Fuentes:
wp-settings.php, sistema de bootstrap de WordPress.WP_Hook y sistema de callbacks de filtros y acciones.
