El equipo de Swoole ha liberado TypePHP, un compilador que traduce código PHP a C++ y de ahí a código máquina nativo. Su web lo anuncia con un contundente «x150 faster computation». La cifra es real, pero mide algo muy concreto: en las pruebas generalistas del propio proyecto la mejora baja a unas 8 veces. Este artículo separa lo medido de lo titulado, explica qué hace realmente la herramienta y para qué sirve —y para qué no— hoy.
Qué es TypePHP exactamente
TypePHP es un compilador AOT (Ahead-Of-Time, «anticipado»). En lugar de interpretar tu código a base de opcodes dentro de la máquina virtual de PHP, lo traduce a C++17 y deja que GCC, Clang o MSVC lo conviertan en un binario que la CPU ejecuta directamente. No hay bytecode, no hay caché de opcodes, no hay calentamiento del JIT.
El proyecto nació como «Swoole AOT» y se renombró a TypePHP durante 2026. El repositorio se abrió el 11 de mayo de 2026 y la última versión publicada mientras escribimos esto es la v0.6.5, del 26 de agosto de 2026. Ese número de versión —0.6.5, no 1.0— es el dato más importante de todo el párrafo.
Un detalle elegante: el compilador está escrito en PHP y es autoalojado. Es decir, se compila a sí mismo para generar su propio binario tpc. Internamente se apoya en nikic/php-parser, la misma librería de análisis sintáctico que usan PHPStan o Rector.
Tres formatos de salida
Del mismo código fuente puedes obtener tres artefactos distintos, y esto es lo que da versatilidad a la herramienta:
bin— un ejecutable nativo autónomo. Requiere una funciónmain()global y arranca sin necesidad de un intérprete de PHP instalado.ext— una extensión cargable de PHP. Te permite escribir la parte crítica en «PHP compilado» y consumirla desde tu aplicación PHP de siempre.lib— una librería compartida reutilizable, con sus ficheros de definición generados.
Además compila a WebAssembly (WASI 0.2) y produce binarios para Linux x64 y ARM64, macOS ARM64 y Windows x64. Linux x64 es la plataforma principal de desarrollo.
Los números, con lupa
Aquí es donde conviene bajar el ritmo. Esta es la tabla oficial de rendimiento publicada por el proyecto, comparando PHP 8.4 sobre su máquina virtual frente al compilador con optimización -O3:
| Prueba | PHP 8.4 (ZendVM) | TypePHP (-O3) | Mejora |
|---|---|---|---|
| fib(40) — Fibonacci recursivo | 14,82 s | 0,11 s | ≈ ×135 |
| Cálculo de PI (100 M iteraciones) | 6,52 s | 0,094 s | ≈ ×69 |
| Array nativo vs array de PHP | 67,6 s | 6,4 s | ≈ ×10 |
bench.php (suite completa) | 5,034 s | 0,603 s | ≈ ×8 |
micro_bench.php (suite completa) | 13,045 s | 2,021 s | ≈ ×6,5 |
Léela de abajo arriba y la historia cambia. Las dos últimas filas son las suites de referencia estándar de PHP, con una mezcla de operaciones más parecida a código real: ahí la mejora es de 6,5 a 8 veces. Las dos primeras son microbenchmarks de aritmética entera pura en bucle cerrado, exactamente el escenario donde un compilador estático arrasa a un intérprete dinámico.
El ×150 del titular no es falso. Es el mejor caso posible, presentado como cifra de cabecera. El propio repositorio es más honesto que su página comercial y advierte que estas cifras son «instantáneas de medición del proyecto, no garantías de rendimiento».
La letra pequeña: no es «tu PHP, pero compilado»
Este es el punto que casi ninguna cobertura del lanzamiento explica bien. TypePHP no compila PHP: compila un subconjunto acotado y estático de PHP. El repositorio incluye un documento específico de incompatibilidades, y es largo. Algunas de las restricciones estructurales:
- El ámbito global no admite código ejecutable. Solo declaraciones,
use,declarey constantes. Todo lo que se ejecuta vive dentro de funciones o métodos. - No hay variables variables (
$$var), ni parámetros por referencia en closures y funciones flecha, ni retorno por referencia desde ellas. declare(strict_types=1)es obligatorio si se declara; no se admiten otras directivasdeclareniticks.- No se pueden declarar funciones ni clases con nombre dentro de otras funciones.
- Con
use native_types, los tipos se congelan. Una variable inferida como entero nativo no puede reasignarse a un tipo incompatible en el mismo ámbito. Es el precio de mapearinta unint64_tde C++ y quitarse el zval de encima. - Nombres dinámicos de clase, función, propiedad y callbacks dinámicos caen de vuelta al motor Zend en tiempo de ejecución: funcionan, pero sin optimización nativa.
- Los ficheros deben ir en UTF-8, y el modo binario exige una
main()con firma concreta que devuelvavoid.
Traducido: cuanto más se parece tu código a Java o a C++, mejor compila. Cuanto más se apoya en la naturaleza dinámica de PHP —la que hace posible el contenedor de servicios de Symfony, las fachadas de Laravel o los hooks de WordPress—, más se degrada hacia el motor de siempre. La documentación del proyecto lo formula sin rodeos: aspiran a un «subconjunto definido y verificable», no a compatibilidad total.
Pero tampoco es otro HHVM
Conviene no pasarse de escéptico. Hay una diferencia de diseño relevante frente a intentos anteriores: TypePHP conserva el motor Zend dentro como runtime. El código compilado puede hacer require o include de ficheros .php normales en tiempo de ejecución, con lo que paquetes de Composer, autoloading y extensiones siguen funcionando en esa parte. Como ha señalado Roman Pronskiy, de la comunidad PHP, no es una implementación alternativa del lenguaje al estilo de HHVM o KPHP: es un compilador que convive con el PHP de siempre.
La diferencia importa mucho históricamente. HHVM, de Facebook, acabó abandonando PHP para centrarse en su propio lenguaje, Hack. KPHP, de VK, quedó como herramienta interna de una sola empresa. PeachPie lleva PHP a .NET con adopción muy minoritaria. El repositorio de TypePHP incluye documentos de análisis de los tres, lo cual sugiere que el equipo conoce el cementerio en el que se está metiendo.
La objeción técnica de fondo, planteada en la discusión del anuncio en Hacker News, sigue en pie: alcanzar el rendimiento de Rust o Go no depende solo de tener un compilador anticipado, sino de que la semántica del lenguaje permita compilar eficientemente. Es la razón por la que los compiladores AOT para Python y Ruby nunca cumplieron su promesa. La respuesta de TypePHP a esa objeción es, precisamente, restringir la semántica: por eso la lista de incompatibilidades es tan larga.
Qué se puede hacer hoy con esto
Con los pies en el suelo, estos son los escenarios donde TypePHP tiene sentido a corto plazo:
| Escenario | ¿Encaja? | Por qué |
|---|---|---|
| Procesos de cálculo intensivo (imagen, series de datos, simulación) | Sí | Es justo el perfil de los benchmarks favorables |
| Herramientas de línea de comandos distribuibles | Sí | Un binario único, sin PHP instalado en destino |
| Cálculo financiero de precisión arbitraria | Sí | Trae bigInt, decimal y bigFloat integrados |
| Acelerar una parte crítica de una app PHP existente | Quizá | Vía modo ext, aislando esa función |
| Compilar una web Laravel, Symfony o WordPress | No | Dependen de los patrones dinámicos no soportados |
| Acelerar una web con carga normal | No | El cuello de botella es base de datos y red, no CPU |
Esa última fila merece énfasis, porque es el malentendido más caro. En una web de empresa corriente, el tiempo se va en consultas a base de datos, latencia de red, llamadas a APIs externas y peso del frontend. Multiplicar por ocho la velocidad de ejecución de PHP en un escenario así mueve una fracción pequeña del total. Si tu web va lenta, la respuesta casi nunca está en el compilador —está en las consultas, en la caché, en las imágenes y en el mantenimiento del sitio.
Para carga y concurrencia web ya existían respuestas maduras y probadas: OPcache con el JIT de PHP 8, y servidores de aplicación persistentes como FrankenPHP, RoadRunner o el propio Swoole. TypePHP no compite con ellos: ataca un problema distinto, el del cálculo puro.
Cuatro riesgos que conviene tener sobre la mesa
Si estás valorando esta tecnología para algo serio, estos son los puntos a vigilar:
- Madurez. Versión 0.6.5, repositorio abierto en mayo de 2026. Es software pre-1.0 en desarrollo activo diario. No es candidato a producción.
- Licencia. El repositorio se publica bajo GPL-3.0, con copyright de la empresa detrás de Swoole. La web comercial anuncia uso comercial libre, y la GPL efectivamente lo permite, pero es una licencia copyleft: si vas a distribuir un producto compilado con esta cadena, revísalo con asesoría legal antes de comercializarlo.
- Propiedad intelectual. El repositorio incluye borradores de memoria técnica para solicitudes de patente sobre dos de sus mecanismos centrales, entre ellos los contenedores tipados mediante plantillas de C++. Es información pública en el propio proyecto y merece atención en una evaluación de riesgo.
- Un solo proveedor. Todo el desarrollo depende de un único equipo. Es exactamente el patrón que hundió a KPHP en la irrelevancia y a HHVM fuera de PHP.
A esto se suma un requisito operativo nada trivial: necesitas PHP 8.4 u 8.5 con cabeceras de desarrollo, GCC 9+ o Clang con C++17, CMake 3.24+ y las librerías GMP y MPFR. Ya no estás desplegando por FTP: estás manteniendo una cadena de compilación de C++.
Qué significa esto para tu empresa
Si tu negocio tiene una web, una tienda online o un ERP en PHP, la respuesta práctica de hoy es corta: no cambia nada. No hay que tocar nada, no hay que migrar nada y nadie debería venderte una migración a TypePHP en 2026.
Lo que sí importa es la señal de fondo. PHP mueve una parte enorme de la web mundial y arrastra desde hace años la etiqueta de «lenguaje lento para cosas serias». Que aparezca un compilador nativo funcional —con limitaciones, con riesgos y en versión 0.6, pero funcional y con código abierto— indica que el ecosistema sigue empujando hacia arriba, no hacia el mantenimiento. Para quien tiene su operación construida sobre PHP, eso es una buena noticia a medio plazo.
Y hay una lección que sí es accionable ya, y que va mucho más allá de este proyecto: cuando una tecnología llega con un multiplicador enorme en el titular, la pregunta correcta es siempre «¿medido cómo?». Aquí la respuesta estaba publicada, en la misma tabla, dos filas más abajo. Ese reflejo —pedir el dato completo antes de tomar la decisión— es el que evita los proyectos caros.
En Netbrain desarrollamos y mantenemos aplicaciones a medida en PHP, y la mayoría de los problemas de rendimiento que nos llegan no se resuelven cambiando de tecnología, sino midiendo dónde se va realmente el tiempo. Si quieres una lectura honesta del estado de tu plataforma, hablamos: consultoría tecnológica.
Preguntas frecuentes
¿TypePHP hace que mi web en PHP vaya 150 veces más rápido?
No. El ×150 corresponde a microbenchmarks de cálculo puro, como una sucesión de Fibonacci recursiva. En las suites generalistas del propio proyecto la mejora medida es de unas 8 veces, y una web típica está limitada por base de datos y red, no por CPU.
¿Puedo compilar mi aplicación Laravel o Symfony?
Hoy no, de forma completa. TypePHP compila un subconjunto acotado y estático de PHP: no admite código ejecutable en el ámbito global, variables variables ni buena parte de los patrones dinámicos que usan los frameworks. Sí puede cargar ficheros .php normales en tiempo de ejecución, porque conserva el motor Zend dentro.
¿Es un sustituto de PHP?
No se plantea como tal. Es un lenguaje compilado con sintaxis compatible con PHP, no una implementación alternativa del lenguaje como fueron HHVM o KPHP. Está pensado para partes concretas intensivas en cálculo, binarios de línea de comandos o extensiones.
¿Se puede usar en producción hoy?
No es recomendable. La última versión publicada al escribir este artículo es la 0.6.5, del 26 de agosto de 2026, con el repositorio abierto desde mayo de 2026. Es software pre-1.0 en desarrollo activo.
¿Qué licencia tiene?
El repositorio se publica bajo GPL-3.0, con copyright de la empresa detrás de Swoole. La web del proyecto anuncia uso comercial libre, pero cualquier producto que se distribuya compilado con esta cadena debería revisarse con asesoría legal antes de comercializarse.
Fuentes
- Página oficial del proyecto: swoole.com/aot/en (tabla de rendimiento y características).
- Repositorio y documentación: github.com/swoole/typephp (README, lista de incompatibilidades, licencia, versiones).
- Cobertura del lanzamiento: Laravel News.
- Discusión técnica y objeciones: Hacker News.
Datos verificados el 27 de agosto de 2026 sobre la versión v0.6.5 del proyecto.