TypePHP compila PHP a binarios nativos: qué cambia de verdad y qué no

Un vistazo en 30 segundos

• TypePHP es un compilador ahead-of-time: convierte PHP en C++17 y de ahí en código máquina. Lo desarrolla el equipo de Swoole, es GPL-3.0 y está publicado desde enero de 2026.
• Puede producir ejecutable, extensión de PHP, biblioteca compartida o componente WASI. En modo binario, la aplicación arranca sola, sin invocar php.
• El compilador está escrito en PHP y se compila a sí mismo. Es un hito de arquitectura real, no una anécdota: exige que el subconjunto soportado dé para escribir algo tan complejo como un compilador.
• Las cifras que publica el proyecto: ~8× en bench.php y ~6,5× en micro_bench.php, y hasta 10× frente a un array de PHP con JIT en una prueba de actualización masiva de elementos. Un medio alemán midió un Fibonacci recursivo 135 veces más rápido.
• Todas esas pruebas tienen algo en común: son aritmética pura. Si tu aplicación se pasa el día esperando a MySQL, a Redis o a una API ajena, ahí no hay 8× que ganar.
• No compila cualquier PHP. Es un subconjunto declarado: el ámbito global es solo declarativo, el modo binario exige una función main(), y buena parte de lo dinámico —reflexión, ciertos usos de closures y referencias— queda fuera.
• Esto ya se intentó: HipHop for PHP, de Facebook, compilaba PHP a C++ en 2010 y acabó sustituido por una máquina virtual con JIT. Conviene saber por qué antes de repetir la historia.
• Y para quien opera: desplegar deja de ser «PHP y la aplicación» para ser binario más PHPX más libphp más bibliotecas nativas, con sus problemas de ABI y su parcheo por recompilación.

---

Hay una frase que se repite desde hace veinte años en cualquier conversación sobre PHP: es cómodo de escribir y caro de ejecutar. La respuesta habitual ha sido mejorar el motor —OPcache, la reescritura de PHP 7, el JIT de PHP 8— y, cuando eso no llegaba, reescribir la parte lenta en otro lenguaje.

TypePHP, del equipo de Swoole, propone otra cosa: compilar el PHP antes de ejecutarlo, bajarlo a C++17 y de ahí a instrucciones que la CPU entiende directamente. El código sigue siendo PHP; lo que cambia es cuándo y en qué se convierte.

La idea es buena, los números que enseña son llamativos y la ejecución técnica tiene mérito. También tiene una lista de condiciones que conviene leer entera antes de emocionarse.

Dónde encaja esto: no es OPcache ni es el JIT

Lo primero es situarlo, porque se confunde muy rápido con lo que ya hay.

PHP convierte el código fuente en opcodes que ejecuta la máquina virtual Zend. OPcache evita repetir esa traducción guardando el bytecode ya compilado. El JIT de PHP 8 va un paso más allá y convierte ciertos caminos calientes en código máquina, pero lo hace durante la ejecución y dentro del motor.

TypePHP hace ese trabajo antes de que la aplicación se ejecute, y el resultado no vuelve a pasar por los opcodes de Zend:

PHP  →  análisis y validación  →  C++17  →  compilador nativo  →  código máquina

Ese «parcialmente» es importante y el proyecto no lo esconde. Lo dinámico de PHP —funciones internas, reflexión, ciertos objetos— sigue interoperando con Zend a través de PHPX, la capa puente del proyecto, que es también lo que permite seguir usando paquetes de Composer y extensiones nativas. Lo que deja de ocurrir es que tus funciones compiladas se ejecuten como una secuencia de opcodes.

Los cuatro modos de salida

El modo bin es el que mejor explica el cambio conceptual: la aplicación arranca como un ejecutable, sin lanzar php por delante. El modo ext es, probablemente, el más práctico a corto plazo: en lugar de escribir una extensión entera en C para acelerar una parte concreta, se escribe en PHP y se compila.

composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml

Un programa mínimo en modo binario tiene que declarar main(), porque el ámbito global es solo de declaración:

<?php

function main(): void
{
    echo "Hola mundo\n";
}

bin/tpc.php hola.php
./hola

De dónde sale la velocidad: los tipos

La compilación anticipada por sí sola no explica las cifras. La otra mitad es el modelo de tipos.

PHP mantiene mucha flexibilidad en tiempo de ejecución, y eso se paga cuando hay millones de operaciones aritméticas o de acceso a estructuras. TypePHP permite activar tipos nativos:

<?php
use native_types;

function fib(int $n): int
{
    if ($n == 1 || $n == 2) {
        return 1;
    }

    return fib($n - 1) + fib($n - 2);
}

Con use native_types, un int pasa a ser un int64_t, un float un double y un bool un bool de C++, en lugar de las estructuras dinámicas habituales. Para precisión alta hay tipos propios —bigInt, decimal, bigFloat— apoyados en GMP, libmpdec y MPFR, que son también las dependencias que hay que instalar para compilar.

Y hay contenedores tipados, que es donde el proyecto enseña sus mejores números: std::array, std::vector, std::map y std::ordered_map.

<?php
use native_types;

function main(): void
{
    $vector = std::vector(Type::Int);

    $vector[] = 10;
    $vector[] = 20;
    $vector[] = 30;

    $sum = 0;

    foreach ($vector as $value) {
        $sum += $value;
    }

    echo $sum . "\n";
}

Los números, y cómo hay que leerlos

Ese último par de filas es el dato interesante de verdad: 6,4 segundos frente a los 6,2 del C++ equivalente. Cuando el código se reduce a recorrer un vector de enteros, el resultado se acerca al del lenguaje al que se está compilando, que es exactamente lo que cabía esperar y lo que valida la idea.

A eso se suma la cifra que publicó heise en agosto de 2026 con un Fibonacci recursivo: 0,11 segundos frente a casi 15 con PHP 8.4, unas 135 veces más rápido.

Ahora, el aviso, que es la mitad del artículo: todas esas pruebas son aritmética y estructuras de datos en memoria. Son el mejor caso posible para un compilador estático y un modelo de tipos rígido, y por eso salen esos números. El propio medio que publicó el Fibonacci advierte de que en una aplicación web típica la ganancia sería mucho más modesta.

Traducido a una aplicación real: si tu petición se va en una consulta SQL de 180 ms, en dos llamadas a una API externa y en esperar a Redis, acelerar la aritmética entre medias no cambia el resultado. Es el mismo razonamiento que aplicamos al elegir procesador para una carga de IA: antes de comprar velocidad, hay que medir dónde se va el tiempo. Casi nunca está donde uno cree.

Donde sí tiene sentido mirarlo es en cargas donde la CPU manda de verdad: procesamiento masivo de datos, cálculo numérico, procesos por lotes, analizadores sintácticos, generación de informes o servicios de larga duración que trituran datos en memoria.

Esto ya se intentó, y conviene saber cómo acabó

Aquí es donde la historia aporta más que cualquier benchmark.

En 2010, Facebook publicó HipHop for PHP: un compilador que traducía PHP a C++ y lo compilaba a binario para reducir la factura de CPU de su propia web. La idea era exactamente esta. Y acabó retirado: la empresa lo sustituyó por HHVM, una máquina virtual con compilación JIT, porque la ruta estática se hacía inmanejable —tiempos de compilación enormes sobre una base de código gigante, y una fricción constante con todo lo dinámico que hace PHP.

Que aquello fracasara no significa que esto vaya a fracasar. El contexto es distinto: hoy PHP tiene tipos declarados de serie, el proyecto no pretende compilar el mundo entero sino un subconjunto definido, y existe una capa de interoperabilidad —PHPX— que en 2010 no había. Pero explica muy bien cuál es la pregunta que decide el futuro de TypePHP, y no es cuántas veces más rápido va: es cuánto PHP real puede compilar sin que el equipo tenga que reescribir su código.

La otra cara: no es todo PHP

El proyecto es explícito, y eso le honra: implementa un subconjunto definido y probado del lenguaje, no PHP entero.

Algunas restricciones son consecuencia inevitable de compilar de forma anticipada:

• El ámbito global es solo declarativo: el código ejecutable va dentro de funciones o métodos.
• El modo binario exige una función main().
• Construcciones muy dinámicas con referencias, reflexión, closures o declaraciones generadas en tiempo de ejecución pueden no estar soportadas.

De ahí se deduce lo que casi nadie quiere oír: no des por hecho que puedes compilar tu WordPress, tu Magento, tu Drupal, tu Laravel o tu Symfony. Esos ecosistemas viven de comportamiento dinámico, clases generadas, contenedores de inyección de dependencias y extensiones; la compatibilidad hay que evaluarla caso por caso y proyecto por proyecto.

Donde encaja hoy es en código nuevo o en módulos concretos con mucho cálculo, no como sustituto directo de una aplicación grande que ya funciona.

Conviene mirar también el estado del proyecto antes de hacer planes. Está en versión 0.6.6, publicada el 27 de agosto de 2026, con unas 970 estrellas en GitHub y del orden de un par de centenares de instalaciones registradas en Packagist. Requiere PHP 8.4 u 8.5, GCC 9 o superior con C++17, CMake 3.24 y las bibliotecas de precisión. Es un proyecto joven, en desarrollo activo y con una comunidad todavía pequeña: perfecto para probar en un módulo aislado, prematuro para el servicio que factura.

Infografía del proyecto TypePHP, traducción de programacion.net.

Lo que cambia para quien despliega

Esta es la parte que no suele aparecer en los artículos sobre el tema y es justo la que nos toca.

El artefacto deja de ser un directorio de ficheros. Con PHP de toda la vida, desplegar es copiar código y recargar el servicio. Con un binario, hay una fase de compilación en medio: el entorno de construcción necesita el compilador de C++, CMake, las cabeceras de PHP y las bibliotecas de precisión. Ese entorno hay que tenerlo, versionarlo y mantenerlo, normalmente en un contenedor de build o en el CI, no en el servidor de producción.

El despliegue pasa de «PHP + aplicación» a «binario + PHPX + libphp + bibliotecas nativas». Y ahí aparece el clásico de siempre: compatibilidad de ABI. Mezclar componentes construidos contra versiones de PHP distintas, o contra una compilación ZTS cuando el sistema es NTS, da errores que no se parecen en nada a un error de PHP. La propia documentación del proyecto lo advierte. Al inventario de la máquina hay que añadir la versión de PHP, la salida de php-config, si es ZTS o NTS, y las extensiones instaladas.

El parcheo cambia de sitio. Un binario lleva dentro lo que se compiló con él, así que una vulnerabilidad en una dependencia no se arregla con apt upgrade: hay que recompilar y volver a desplegar. Es exactamente la misma factura que ya se paga con Go, y conviene tenerla contabilizada antes, no el día del CVE.

Y la comodidad de siempre desaparece. Editar un fichero en el servidor para salir de un apuro —con todo lo malo que tiene esa costumbre— deja de ser posible. Para bien, casi siempre: obliga a un proceso de despliegue de verdad. Pero es un cambio cultural, no solo técnico.

Hay un efecto secundario que a algunos les interesará: distribuir un binario en lugar de ficheros .php dificulta bastante recuperar el código original. Ojo con el matiz: dificulta, no impide. Un binario nativo se puede examinar con herramientas de ingeniería inversa; lo que desaparece es la posibilidad de abrir un fichero y leerlo. Como medida comercial puede valer; como medida de seguridad, nunca debe ser la única.

Cuándo mirarlo y cuándo no

Esa última fila es, para nosotros, la consecuencia más relevante. Hasta ahora, cuando una parte en PHP se quedaba corta de CPU, la salida era reescribirla en otro lenguaje, con el coste de tener dos tecnologías en casa y un equipo que sepa mantener ambas. Que exista una vía intermedia —seguir en PHP y compilar solo lo que lo necesita— cambia esa decisión, aunque hoy sea todavía una opción para explorar y no para apostar.

Lo que nos llevamos

TypePHP es un proyecto serio y con una ejecución técnica notable: un compilador escrito en PHP, capaz de compilarse a sí mismo, que baja a C++17 y se acerca al rendimiento de C++ en las pruebas donde eso es posible.

Al mismo tiempo, es una versión 0.6 con meses de vida, que soporta un subconjunto del lenguaje, que introduce una fase de compilación en el despliegue y que cambia lo que hay que mantener en el servidor. Y sus cifras miden lo que un compilador estático hace mejor: aritmética. Casi ninguna aplicación web pasa su vida ahí.

La forma sensata de acercarse es la de siempre: medir dónde se va el tiempo de verdad, y solo si la respuesta es CPU, probarlo en un módulo aislado antes de dejarlo cerca de nada que facture. Si estás dimensionando infraestructura para cargas PHP pesadas —procesos por lotes, informes, colas que no terminan— y quieres saber si el problema es el lenguaje, la máquina o la consulta, cuéntanos qué tienes y lo miramos contigo. Casi siempre es la consulta.

Preguntas frecuentes

¿Qué es TypePHP?

Un compilador ahead-of-time desarrollado por el equipo de Swoole que traduce código PHP a C++17 y de ahí a código máquina nativo. Puede generar ejecutables, extensiones de PHP, bibliotecas compartidas y componentes WebAssembly, y está publicado bajo licencia GPL-3.0.

¿Sustituye a OPcache o al JIT de PHP?

No. OPcache y el JIT trabajan dentro del modelo de ejecución habitual de PHP —guardando opcodes o compilando rutas calientes en caliente—, mientras que TypePHP compila antes de ejecutar. Son enfoques distintos para problemas distintos y pueden convivir.

¿Puedo compilar mi aplicación de Laravel o mi WordPress?

No lo des por hecho. TypePHP soporta un subconjunto definido de PHP y mantiene una lista de características no compatibles. Los frameworks y CMS que se apoyan mucho en comportamiento dinámico, reflexión y clases generadas requieren una evaluación caso por caso.

¿Es diez veces más rápido que PHP?

En sus benchmarks, sí, y en un Fibonacci recursivo mucho más. Pero esas pruebas son aritmética y estructuras en memoria, que es el mejor caso para un compilador estático. En una aplicación que espera a la base de datos o a una API externa, la mejora real puede ser mínima.

¿Qué cambia al desplegar una aplicación compilada?

Aparece una fase de compilación —con compilador de C++, CMake y cabeceras de PHP— y el artefacto pasa a ser un binario que puede depender de PHPX, de libphp y de bibliotecas nativas. Hay que vigilar la compatibilidad de ABI entre versiones de PHP y configuraciones ZTS o NTS, y asumir que parchear una dependencia significa recompilar.

¿Compilar el código lo protege?

Dificulta leerlo, no lo protege. Un binario nativo se puede analizar con desensambladores y decompiladores; lo que se pierde es la posibilidad de abrir un .php y leer el original. Como protección de propiedad intelectual puede tener sentido; como medida de seguridad, nunca debe ser la única.

Fuentes

• Swoole, documentación oficial de TypePHP AOT — modos de compilación, tipos nativos, contenedores, PHPX y benchmarks del proyecto.
• Repositorio swoole/typephp en GitHub — licencia GPL-3.0, compilador autoalojado, requisitos de compilación, plataformas soportadas y subconjunto del lenguaje.
• swoole/typephp en Packagist — versión 0.6.6 del 27 de agosto de 2026, requisito de PHP 8.4 a 8.5 e instalaciones registradas.
• heise online, TypePHP accelerates PHP: open-source compiler generates native binaries (27 de agosto de 2026) — la medición del Fibonacci recursivo, el papel de PHPX y el precedente de HipHop for PHP.
• Administración de Sistemas, TypePHP compila PHP a binarios nativos y promete acelerar las cargas más pesadas.
• Programación.net, TypePHP compila PHP a binarios nativos y promete acelerar las cargas más pesadas — origen de la infografía traducida que ilustra este artículo.