WordPress servido sin PHP
Cada visita a una página de WordPress despierta un worker de PHP. Ese worker carga el núcleo de WordPress, el tema y todos los plugins activos, abre una conexión con un servidor MySQL, ejecuta el bucle y lo desmonta casi todo otra vez. Y lo hace en cada petición.
Su sitio son tres cosas: el contenido, el tema que lo pinta y el wp-admin con el que lo edita. BookPress conserva las tres y cambia lo que corre por debajo.
El camino de servicio está reescrito en C++ desde cero. El enrutador, el renderizador de temas de bloques, la capa de consultas y wp-admin son código nativo, no PHP. PHP solo corre para sus temas y plugins, sobre el motor PHP propio de BookPress. Un sitio sin plugins hace todo su trabajo sin ejecutar ni una línea de PHP.
Puede probar uno. La demo en vivo es el
tema Kadence con WooCommerce, Elementor, Yoast SEO, Contact Form 7, Yoast Duplicate Post y Hello Dolly, todos activos, servido por este
motor en una e2-micro de Google Cloud sin caché de página delante.
Su acceso aparece al arrancar su sandbox. Escriba una entrada. El sandbox
se borra a los 15 minutos de arrancarlo, así que no meta en él nada
personal.
El motor
- Compilado a código nativo. C++ construido para servidores Linux Intel y ARM actuales, con el análisis de peticiones y la generación de HTML optimizados a mano. El núcleo de WordPress corre como código nativo y los plugins corren como PHP sobre nuestro propio motor. Todo el servidor es un binario de 1,8 MB.
- Almacenamiento SQLite embebido. La base de datos es SQLite, dentro del mismo proceso y sobre el mismo esquema de WordPress. Las consultas de contenido vuelven en microsegundos, y no hay servidor de base de datos en el camino de la petición.
- Workers a la medida de la máquina. Al arrancar, BookPress fija cuántos workers lanza a partir de los procesadores y la memoria de la máquina. Si usted fija un número, manda el suyo. Las cifras de esta página las medimos con cuatro workers.
- PHP compilado al arrancar. BookPress compila los archivos PHP de un sitio al arrancar y cada vez que un archivo cambia. El primer visitante no espera por la compilación.
Renderizado real de temas
BookPress renderiza los temas de bloques de WordPress de forma nativa. Lee
los mismos archivos de plantilla, el mismo marcado de bloques y el mismo
theme.json, y produce el HTML y el CSS que produce WordPress:
estilos globales, clases de maquetación, presets de fuentes, tipografía fluida. Twenty
Twenty-Five, el tema por defecto de WordPress, se renderiza hoy casi píxel a píxel desde sus
archivos de tema sin tocar, fuentes web incluidas.
El wp-admin sigue el mismo enfoque. /wp-login.php comprueba los hashes de
contraseña de su WordPress actual. /wp-admin le da el
escritorio, las listas de entradas y el editor, servidos por el mismo motor a la misma
velocidad.
Qué comparamos: una prueba dura para BookPress
Tomamos un sitio real: el tema Kadence con WooCommerce, una página de muestra hecha con Elementor, Yoast SEO y Contact Form 7. Migramos el contenido, idéntico, a los dos motores, con el mismo número de filas en las dos bases de datos. Antes de medir, optimizamos el lado WordPress como lo haría un hosting que sabe lo que hace: PHP 8.3.35 con OPcache y JIT activados, caché de objetos Redis por socket, MariaDB y PHP-FPM detrás de nginx, con el almacenamiento de pedidos más reciente de WooCommerce (HPOS) activado. Solo medimos una página después de comprobar que WordPress y BookPress muestran lo mismo: el mismo marcado de Elementor, la misma página de producto, el mismo catálogo de la tienda.
WordPress se mide sin caché de página, y comprobamos que está apagada antes de medir, porque una página que puede servir una caché la sirve la caché en cualquiera de los dos montajes, y eso no mide al motor. Cada número de abajo es WordPress ejecutando PHP, que es el caso con el que se encuentran siempre un carrito, una búsqueda o una sesión iniciada.
Los servidores
Usamos dos servidores de Google Cloud que cualquiera puede alquilar y comprobar. El servidor
Intel es una c2-standard-4 de 4 vCPU (Intel Xeon a 3,10 GHz,
2 núcleos físicos con dos hilos cada uno, 16 GB de RAM). El
servidor ARM es una c4a-standard-4 de 4 vCPU (Google Axion,
4 núcleos físicos, 16 GB de RAM). Los dos corren Debian 12, y
BookPress está compilado de la misma manera en ambos.
Fíjese en los dos recuentos de núcleos antes que en cualquier número. «4 vCPU» es una cantidad distinta de hardware en cada familia, así que un número ARM solo lo comparamos con un WordPress que corre en ese mismo servidor.
El resultado: más peticiones por segundo, en los dos servidores
Llevamos cada motor al máximo de peticiones por segundo que sirve con el 99 % de ellas por debajo de un segundo y ninguna fallida. En páginas reales de tienda, BookPress sirve unas 4,5 veces las peticiones por segundo del WordPress optimizado en el servidor Intel y más de 5 veces en el servidor ARM. Cada cifra de abajo es BookPress frente a WordPress en el mismo servidor.
| Página | Servidor | Peticiones / segundo | Tiempo de respuesta p50 | Tiempo de respuesta p99 |
|---|---|---|---|---|
| Página de Elementor | Intel | 4,53×162 frente a 36 pet./s | 3,80× | 1,93× |
| Tienda WooCommerce | Intel | 4,85×134 frente a 28 pet./s | 4,75× | 2,79× |
| Página de Elementor | ARM | 5,30×376 frente a 71 pet./s | 5,30× | 3,70× |
| Tienda WooCommerce | ARM | 5,19×297 frente a 57 pet./s | 5,20× | 2,50× |
Medido en Google Cloud c2-standard-4 (Intel) y c4a-standard-4 (Arm), páginas dinámicas sin caché, BookPress 0.2.64 (la versión empaquetada, la misma que instala usted) contra WordPress 7.1.3 / PHP 8.3.35 con nginx, PHP-FPM, caché de objetos Redis, OPcache con JIT y MariaDB.
Las peticiones por segundo son las de cada motor en su punto de saturación; p50 y p99 son los múltiplos del tiempo de respuesta mediano y del percentil 99 en el escalón de saturación de WordPress, con la misma concurrencia para los dos. WordPress se mide sin caché de página.
Las páginas de tienda son, sobre todo, el PHP del propio plugin, así que son el caso más difícil. A diferencia de una página sin plugins, no se pueden responder sin ejecutar ese PHP. BookPress lo ejecuta sobre su propio motor PHP, que en estas páginas sigue el ritmo de PHP 8.3.35 con JIT, o lo supera. Estas páginas eran antes el punto débil, y hoy BookPress va por delante también en ellas.
Un sitio sin plugins no ejecuta ningún intérprete de PHP. Ahí BookPress sirve 112,9 veces las peticiones por segundo de WordPress en el servidor Intel (5 234 frente a 46) y 125 veces en el ARM (11 436 frente a 91), sin ningún plugin instalado.
La caché de página es otra capa
Una caché de página sirve HTML ya guardado sin renderizar nada, en WordPress igual que en BookPress. Un acierto de caché, por tanto, no mide a ninguno de los dos motores. Cada cifra de este sitio es un renderizado dinámico sin caché en los dos stacks.
Algunos temas PHP clásicos. Las plantillas clásicas de WordPress pesan menos que sus temas de bloques. El renderizado de temas clásicos de BookPress es más reciente que su camino de bloques, y unos pocos de las dos docenas de temas clásicos incluidos todavía dan error hoy. La corrección está en nuestra hoja de ruta. Las páginas de tienda de arriba usan temas de bloques.
Memoria
La memoria es una medición aparte y anterior, tomada con BookPress 0.2.57. La medimos en los dos servidores tras una prueba a plena carga, en el mismo sitio con todos los plugins activos, contando una sola vez la memoria compartida entre procesos.
Bajo carga, cuatro workers de BookPress usaron unos 0,6 GB. Es más o menos lo mismo que un WordPress bien dimensionado (8 hijos PHP, 0,55 GB), que sirve menos páginas, y un tercio de un pool optimizado de 64 hijos (1,8 GB). Treinta segundos después de parar la carga, BookPress bajó a unos 0,3 GB. WordPress se quedó en 0,43 GB (8 hijos) o 1,8 GB (64 hijos).
Los workers cargan el código del motor y el bytecode de los plugins una vez y lo comparten. Cada worker adicional suma su propio conjunto de trabajo bajo carga y devuelve casi todo en reposo. Un worker que lleva 30 segundos sin peticiones devuelve memoria al sistema, y por eso la cifra en reposo baja. Un pool de WordPress se queda con lo que preforkeó, esté ocupado o en reposo. Las cifras de memoria se tomaron con BookPress 0.2.57, 13 de octubre de 2026; la prueba de rendimiento de arriba es una medición posterior y aparte.
Sin caché de objetos, sin servidor de base de datos, sin caché de página
Los hostings de WordPress montan estas capas para que PHP no haga el trabajo dos veces. Cada lectura de la caché de objetos es un viaje de ida y vuelta a Redis y una decodificación en PHP. Un servidor de base de datos es otro viaje de ida y vuelta. Una caché de página guarda una copia ya renderizada para que nginx responda sin entrar en el stack.
BookPress no tiene ninguna de las tres. El almacenamiento es embebido y vive en el mismo proceso, así que no hay viaje de ida y vuelta que ahorrar. No hay copia renderizada que guardar, porque renderizar la página desde cero es el camino rápido. Un CDN sigue mereciendo la pena por los motivos de siempre: la distancia a sus visitantes y los recursos estáticos.
Cada una de esas capas puede configurarse mal, quedarse sin memoria, servir contenido viejo o pedir un purgado tras un despliegue. BookPress no tiene ninguna de esas piezas móviles. Y eso cuenta primero para la operación y después para la velocidad.
Un resultado va en nuestra contra. Si un hosting ya tiene una caché de objetos Redis, la dejamos instalada. Desactivarla para mejorar nuestros números sería hacer trampa. Nuestro motor de plugins activa el plugin y el sitio sirve, pero el plugin no puede hacer su trabajo: el motor PHP de BookPress no ofrece el cliente Redis ni las llamadas de red de bajo nivel que necesita. El plugin recurre a la caché por petición de WordPress y no guarda nada entre peticiones. Activar cualquier plugin significa que el sitio ejecuta PHP en cada petición, así que una caché de objetos activa hace mucho más lenta una página sin plugins y no da nada a cambio. BookPress no puede ejecutar la función de este plugin. Eso no es lo mismo que no necesitarlo. No instale una caché de objetos en BookPress: le cuesta y no le da nada.
Qué hace una caché de página, y qué no puede hacer
Con una caché de página delante, WordPress sirvió decenas de miles de peticiones por segundo en este benchmark, muchas más que BookPress. El número es real. También es nginx devolviendo un archivo desde el disco, sin que PHP corra.
Una caché de página se para donde se para su permiso. No sirve un carrito, un pago, una página de cuenta, nada que lleve una cookie de sesión, nada con cadena de consulta, ni nada para un visitante con sesión iniciada. Esas páginas son las que deciden la capacidad de una tienda. En ellas la caché se aparta y la petición llega al PHP que tenía delante. Cada cifra de esta página mide ese caso.
El WordPress con el que comparamos, al completo
Es WordPress 7.1.3 sobre PHP 8.3.35-FPM, optimizado como lo haría un hosting que sabe lo que hace: OPcache dimensionado para que nada se expulse, con JIT activado, caché de objetos Redis caliente por socket, MariaDB con un buffer pool holgado y WooCommerce sobre su almacenamiento de pedidos más reciente (HPOS). Lo ejecutamos con dos pools para que el tamaño del pool no sesgue la comparación: un pool optimizado estático de 64 hijos y un pool bien dimensionado dinámico de 8 hijos.
Configuración exacta
- OPcache con JIT activado. 512 MB de código compilado, un buffer de cadenas internadas de 64 MB, un límite de 100 000 archivos, validación de marcas de tiempo apagada y un buffer JIT de 256 MB.
- Caché de objetos Redis (Redis 7) por socket UNIX, con el drop-in de caché de objetos instalado y la caché caliente.
- MariaDB 11 con un buffer pool InnoDB de 4 GB.
- PHP-FPM detrás de nginx 1.27. Un pool estático de 64 hijos y un pool bien dimensionado dinámico de 8 hijos, los dos medidos.
- WooCommerce sobre HPOS, su almacenamiento de pedidos más reciente.
Los plugins son las versiones de la propia demo: WooCommerce 11.0.1, Elementor 4.2.3, Yoast SEO 28.3 y Contact Form 7 6.1.7, sobre el tema Kadence 1.5.2. Solo medimos una página después de comprobar que WordPress y BookPress muestran lo mismo: la muestra de Elementor, la página de producto y el catálogo de la tienda, comprobados en los dos servidores.
La configuración de BookPress, con el mismo rigor
bookpress --root /srv/sites/<site> --db /srv/sites/<site>/data/site.db \
--port <port> --workers 4BookPress corre sin php.ini, sin pool de PHP-FPM, sin caché de objetos, sin caché de opcodes, sin caché de página y sin proxy inverso. Cada número de BookPress en esta página es una página renderizada desde cero.
Qué servidor alquilar
Alquile el servidor Arm: cuatro núcleos reales donde el Intel tiene dos, alrededor de un 14 por ciento menos de precio de lista, y de unas 2,2 a 2,3 veces las peticiones por segundo de Elementor y WooCommerce con BookPress 0.2.64.
Precio de lista, Google Cloud us-central1 bajo demanda:
c4a-standard-4 131,11 $ al mes frente a
c2-standard-4 152,43 $.
La economía del hosting
Un hosting dimensiona cada servidor por memoria. A plena carga, el mismo sitio ocupó unos 0,6 GB en cuatro workers de BookPress (medido con 0.2.57), frente a 0,55 GB de un WordPress bien dimensionado y 1,8 GB de un pool optimizado de 64 hijos. En reposo, BookPress devuelve memoria y los pools de WordPress no. Estamos midiendo cuántos sitios aguanta una máquina.
El precio lo calculamos a partir de la infraestructura que un hosting deja de pagar, que es lo que miden los números de esta página. Va desde 1,00 $0,85 € por sitio y mes en Starter hasta 0,45 $0,38 € en Agency, y por vCPU licenciada a partir de 500 sitios. La página de precios recoge los planes y muestra cómo sale la cifra para su propia flota.