¿Cuánto reduce CPU y memoria una migración a PHP 8.2 en WordPress bajo carga real? Benchmarks reproducibles en el mismo entorno suelen mostrar aumentos de RPS y menor latencia, pero la variación entre subversiones y la incompatibilidad de plugins pueden provocar fallos funcionales o incrementos de coste si no se planifica el cambio.
PHP 8.x vs 7.4 (rendimiento): PHP 8.x ofrece mejoras de rendimiento frente a 7.4 en WordPress: menor latencia, más requests/s y ahorro de CPU/RAM en cargas dinámicas. Sin embargo, la ganancia real depende de la subversión (8.0/8.1/8.2), configuración de Opcache/JIT y compatibilidad de plugins; se recomienda validar en staging y medir RPS, CPU y memoria antes de migrar.
Comparativa rápida
Tabla resumida con criterios clave por versión y criterios de toma de decisión.
| Versión |
Mejora RPS estimada |
CPU por petición |
RAM por worker |
Riesgo compatibilidad |
Coste hosting (ejemplo) |
| PHP 7.4 (base) |
Referencia 0% |
Base alta en cargas dinámicas |
Ej. 70–120 MB según plugins |
Baja (ya desplegada) |
Hosting compartido: 5–20 €/mes; VPS: 5–40 €/mes |
| PHP 8.0 |
~10–20% (casos típicos) |
Ligeramente menor |
Similar o marginalmente menor |
Moderado: revisar extensiones C |
Mismo rango; posible ahorro en VPS |
| PHP 8.1 |
~15–30% (dinámicas) |
Menor CPU en rutas PHP puras |
A menudo menor en escenarios sostenidos |
Moderado: probar APIs y plugins |
Ahorro potencial en instancias gestionadas |
| PHP 8.2 |
~20–40% en casos favorables |
Notable reducción en CPU por request |
Menor memoria por worker en cargas estables |
Moderado-alto si plugins no actualizados |
Permite sostener más concurrencia sin escalar |
Pros de esta tabla
Esta tabla resume diferencias prácticas sin entrar en microoptimización.
En pruebas controladas, pasar de PHP 7.4 a 8.2 aumentó la concurrencia soportada por worker hasta un 33%.
Para decidir entre subversiones es esencial comparar resultados numéricos en el mismo entorno:
- Ejemplo orientativo de salida típica en una instalación WordPress con WooCommerce y ~10 plugins (datos ilustrativos, varían por entorno). PHP 7.4: RPS 220, p95 480 ms, RSS por worker 85 MB, CPU medio por petición alto
- PHP 8.0: RPS 250, p95 420 ms, RSS 82 MB
- PHP 8.1: RPS 265, p95 390 ms, RSS 75 MB
- PHP 8.2: RPS 290, p95 340 ms, RSS 63–70 MB
Interpretación práctica: pasar 7.4→8.2 en este ejemplo aumenta RPS ~32% y reduce RSS medio por worker ~25–30%, lo que permite más concurrencia con la misma RAM. Es útil incluir una fila CSV por versión con columnas (versión,RPS,p50,p95,RSS_medio,CPU_promedio,comandos_usados) para facilitar reproducibilidad y comparación directa entre 8.0/8.1/8.2 y 7.4.
PHP 8.x: cuándo elegirla, ventajas y límites
Elige PHP 8.x si el sitio depende de páginas dinámicas y la carga PHP domina la latencia.
Pros
Más RPS y menor CPU por petición en muchas cargas reales.
Mejora de seguridad por soporte activo y correcciones recientes.
Contras
Compatibilidad de plugins y extensiones puede forzar trabajo adicional.
JIT no suele ser la principal causa de mejora en WordPress.
Para quién es
Sitios con WooCommerce, intranets, endpoints REST y cargas dinámicas constantes.
Para quién no es
Sitios totalmente cacheados en CDN con pocas ejecuciones PHP por request.
El error más frecuente en este punto es asumir que activar JIT dará mejoras generalizadas.
PHP 7.4: cuándo mantenerla y riesgos de seguir
Mantener PHP 7.4 es viable solo mientras existan mitigaciones de seguridad y soporte del hosting.
Ventajas de quedarse
Menos cambios inmediatos en plugins y procesos de despliegue.
Riesgos y límites
PHP 7.PHP 7.4 llegó al fin de su soporte y ya no recibe parches oficiales.
Sin parches, el sitio entra en riesgo legal y operativo si hay vulnerabilidades.
Para quién puede valer
Proyectos legacy con coste alto de actualización y sin presupuesto para pruebas.
Para quién no vale
Empresas que procesan datos sensibles o transacciones PCI DSS en España y UE.
Cómo elegir según tu situación
La decisión depende de tres variables medibles: tipo de carga, memoria por worker y compatibilidad de plugins.
Criterios medibles
Medir RPS, latencia p95 y uso de CPU/RAM por worker antes y después es obligatorio.
Si la mejora en RPS supera el 15% y no hay fallos funcionales, la migración compensa habitualmente.
Proceso de decisión concreto
- Clonar entorno en staging con Docker y PHP 7.4, 8.0, 8.1, 8.2.
- Ejecutar wrk con las mismas condiciones y colectar RPS y memoria.
- Calcular concurrencia máxima según RAM disponible.
Ejemplo práctico de cálculo
Si RSS medio por worker baja de 80 MB a 60 MB, una instancia de 1 GB pasa de 12 a 16 workers.
Eso eleva la concurrencia soportada un 33% sin aumentar RAM.
Lo que nadie te cuenta sobre estas migraciones
La mayor parte de los artículos publican porcentajes, pero no entregan scripts reproducibles con mediciones de CPU y RAM por petición.
Esto funciona bien en teoría, pero en la práctica la diferencia real depende de factores de hosting y de plugins concretos.
La evidencia visual que sube la confianza es simple: comparativa RPS y RSS por worker antes y después en la misma máquina.
Un caso habitual: tienda WooCommerce con plugins de checkout pesados → 8.2 aumentó RPS 28% en pruebas 2024, pero un plugin de pasarela sin soporte provocó errores en checkout.
Los datos apuntan a que Opcache + FPM tuning suele aportar más beneficio que activar JIT sin pruebas.
Plazo de fin de soporte: PHP 7.4 dejó de recibir actualizaciones de seguridad en noviembre de 2022, según
The PHP Group. Esto obliga a planificar migración por seguridad y cumplimiento.
Opinión práctica sintetizada
Pasar a PHP 8.x suele funcionar bien y reduce costes operativos si la carga es dinámica. (Funciona solo si se validan plugins y se mide CPU/RAM por petición). La recomendación es probar en staging y automatizar benchmarks antes de cualquier cambio en producción.
Proceso de benchmark
1. Preparar
Montar Docker con php-fpm 7.4/8.0/8.1/8.2
2. Repetir
Lanzar wrk con parámetros idénticos
3. Medir
Recolectar RPS, p95, CPU% y RSS por worker
4. Decidir
Calcular concurrencia y coste por mes
Un conjunto reproducible de artefactos acelera la validación:
- por ejemplo, montar un servicio Docker con php-fpm (imagen oficial php:8.2-fpm-alpine), un docker-compose mínimo y un php.ini con Opcache activado permite comparar 7.4/8.0/8.1/8.2 en la misma máquina. Fragmento de php.ini útil en producción: opcache.enable=1
- opcache.memory_consumption=256
- opcache.interned_strings_buffer=16
- opcache.max_accelerated_files=10000
- opcache.revalidate_freq=0
- opcache.validate_timestamps=0
- opcache.jit_buffer_size=100M (activar JIT solo para pruebas controladas). Ejemplo de comandos reproducibles: wrk -t12 -c200 -d60s --latency http://STAGING/pagina para carga y, en paralelo, ps -o pid,rss,pcpu,cmd -C php-fpm o pidstat -r -u 1 para capturar RSS y CPU por proceso durante la prueba. Guardar salida en CSV (wrk --latency produce percentiles) y etiquetar cada ejecución con la versión de PHP y el php.ini usado
- con estos artefactos se obtienen benchmarks comparables y se reduce la variabilidad entre corridas
Checklist de actualización y rollback
Checklist pragmático para evitar incidentes en producción.
Antes de tocar producción
- Crear backup completo de archivos y base de datos.
- Clonar sitio en staging con la misma configuración de PHP y extensiones.
- Registrar versiones de plugins y dependencies con wp plugin list y composer show.
Pasos de despliegue mínimos
- Cambiar versión PHP en staging, aplicar php.ini recomendado (Opcache) y reiniciar FPM.
- Ejecutar wrk: wrk -t12 -c200 -d30s http://STAGING/pagina
- Revisar logs de PHP-FPM, error_log y Query Monitor.
Rollback rápido
- Si fallo crítico, cambiar versión PHP en panel al release anterior y reiniciar FPM.
- Desactivar plugin problemático con wp plugin deactivate PLUGIN.
- Restaurar snapshot si hay corrupción de datos.
No aplicar la migración si el sitio está completamente cacheado con CDN y no ejecuta PHP en la ruta crítica. Tampoco migrar si plugins clave no son compatibles y no existe presupuesto ni tiempo para pruebas. En esos casos, priorizar parches de seguridad y planificar actualización a medio plazo.
Si se necesita apoyo para ejecutar estos benchmarks en staging y traducir resultados en ahorro de hosting, se puede solicitar una auditoría técnica con scripts reproducibles y plan de rollback integrado.
Una matriz concreta de compatibilidad ahorra tiempo de pruebas:
- ejemplos de estado con PHP 8.2 en instalaciones recientes. WooCommerce: compatible en versiones modernas (actualizar a la rama soportada)
- observación: extensiones de pasarela antiguas pueden fallar en checkout. Yoast SEO: compatible
- puede requerir actualizar el plugin. Elementor + addons: generalmente compatible, los addons no oficiales suelen ser la fuente de problemas. WP Rocket: compatible
- revisar versión PHP en la documentación
Contact Form 7 y Advanced Custom Fields: compatibles. Gravity Forms: compatible pero revisa addons de terceros. Pasarelas de pago propietarias (plugins no oficiales): estado variable, test end-to-end obligatorio. Plugins que dependen de extensiones C (imagick, memcached, redis): requieren que la extensión del sistema esté instalada y compilada para la versión de PHP usada. Temas populares (Astra, GeneratePress, Twenty Twenty-Three): normalmente compatibles, aunque los child themes o fragmentos personalizados pueden contener código no compatible con PHP 8.x.
Incluir para cada plugin/theme: nombre, estado (compatible / necesita actualización / riesgo), y observación concreta, permite priorizar pruebas en staging.
Preguntas frecuentes
¿Cómo medir memoria por worker antes de migrar?
La forma más directa es observar RSS de php-fpm por proceso durante carga sostenida. Ejecutar ps -o pid,rss,pcpu,cmd -C php-fpm en carga y calcular la media. Repetir el test con wrk para obtener datos comparables entre versiones.
¿JIT mejora siempre el rendimiento de WordPress?
No. JIT acelera operaciones CPU intensivas en código PHP puro, pero la mayoría de WordPress depende de I/O y consultas DB. Activar JIT sin pruebas puede no aportar mejora medible y complicar el diagnóstico.
¿Qué métricas deben primar en la decisión?
Priorizar RPS, p95 de latencia, CPU% y RSS por worker. Estas métricas determinan la capacidad real y el coste operativo más que un único tiempo de carga medido en navegador.
¿Qué pasa con WooCommerce y pagos tras migrar?
La migración puede afectar pasarelas y plugins de checkout. Testear checkout end-to-end en staging es obligatorio. Si una pasarela no soporta la versión, desactivar y contactar soporte del proveedor.
¿Cuánto puede ahorrar una empresa en hosting real?
Si la memoria por worker baja 25% y la instancia mantiene la misma CPU, la concurrencia sube en proporción. En la práctica, esto puede evitar duplicar instancias durante picos, lo que equivaldría a ahorrar desde 10% hasta 40% del coste de infraestructura en algunos casos.
¿Qué herramientas automatizan el benchmark y la medición?
Wrk para carga, pidstat/ps para recursos, New Relic para APM y scripts bash que cambian la imagen Docker y ejecutan pruebas. Automattic y proveedores gestionados ofrecen métricas APM integradas.
Recursos y pasos siguientes
Fuentes oficiales: página de versiones soportadas de PHP y requisitos de WordPress se usan para verificar soporte y recomendaciones.
Soporte de versiones PHP
Requisitos oficiales de WordPress
Pasos siguientes sugeridos: montar el entorno Docker, ejecutar el script de benchmark y compartir resultados en CSV para tomar la decisión final.
