Cómo reducir el TTFB de WordPress: PHP, base de datos o hosting

El TTFB mide el tiempo desde que comienza una navegación hasta que llega el primer byte de la respuesta. Incluye DNS, conexión, TLS, red y espera del servidor; por eso un valor alto no demuestra por sí solo que WordPress o la base de datos sean la causa. El diagnóstico necesita comparar escenarios antes de cambiar plugins o plan de hosting.

TTFB no es lo mismo que cargar la página completa

El navegador todavía debe descargar y renderizar CSS, JavaScript, fuentes e imágenes después de recibir el HTML. Un TTFB bajo puede convivir con un LCP lento, y un frontend ligero puede sentirse limitado por una respuesta inicial tardía. Separar ambas fases evita optimizar imágenes cuando el cuello está antes del HTML o ampliar servidor cuando el problema está en recursos del navegador.

1. Medir rutas comparables y repetir

Compara portada, entrada, página dinámica, administración y, si existe, carrito o checkout. Repite con y sin sesión y distingue una primera visita de una respuesta cacheada. Una sola medición puede coincidir con una tarea, un despliegue o una variación de red; interesa el patrón y no únicamente el mejor o peor número.

2. Comprobar si la caché de página puede responder

En contenido público, una caché bien configurada puede servir HTML sin ejecutar todo WordPress. Si la respuesta cacheada es rápida y la no cacheada no, la investigación se concentra en PHP, plugins, tema, consultas o llamadas externas. Cuenta, carrito y checkout requieren exclusiones: cachearlos como una página pública puede mostrar contenido incorrecto.

3. Observar PHP y la capacidad disponible

CPU, memoria y workers PHP deben observarse durante el escenario lento. Pocos workers ocupados pueden crear cola aunque cada petición termine; un proceso con consumo anómalo puede saturar incluso un servidor amplio. También se revisan versión, límites, errores y reinicios. Cambiar de hosting tiene sentido cuando la carga legítima supera una restricción demostrada, no solo porque el plan tenga otro nombre.

4. Localizar consultas y opciones autoload

El tiempo de base de datos se investiga con consultas concretas: duración, frecuencia, índices y filas examinadas. Tablas grandes u opciones autoload merecen revisión, pero borrar datos por volumen sin identificar al consumidor puede romper funciones. En WooCommerce también conviene observar sesiones, pedidos y tareas programadas.

5. Revisar cron y llamadas externas

Plugins y temas pueden consultar licencias, fuentes, APIs, ERP o servicios de marketing durante una petición. Un tercero lento eleva la espera aunque el servidor local tenga recursos. WP-Cron y Action Scheduler también pueden coincidir con tráfico; hay que relacionar la hora y el proceso antes de mover tareas o desactivarlas.

6. Valorar caché de objetos sin tratarla como requisito

Una caché persistente de objetos puede reducir consultas repetidas en determinados sitios. También añade memoria, red, invalidación y otra dependencia operativa. Debe medirse con el recorrido real; en una web pequeña o con consultas poco repetibles puede no ser la primera mejora.

7. Comparar el mismo escenario después del cambio

Los cambios deben aplicarse en grupos pequeños y probar la misma URL, estado de sesión y condición de caché. Además del tiempo, se comprueban edición, formularios, login, pedidos y tareas. Una mejora que solo funciona al desconectar una operación necesaria no resuelve el rendimiento del negocio.

Cuándo escalar o migrar el hosting

Más capacidad puede ser adecuada cuando el tráfico y trabajo son legítimos, el software ya está razonablemente ajustado y las métricas muestran saturación o colas. Si la causa es una consulta, llamada o tarea descontrolada, migrar puede ocultarla temporalmente. El objetivo es elegir infraestructura después de entender la carga que debe sostener.