Tu PageSpeed Insights muestra un TTFB rojo. El reflejo inmediato: “necesitas más CPU” o “necesitas un VPS”. Tres semanas después, la factura se duplicó y el retraso del servidor solo cambió en 40 ms. El escenario es banal: tratamos un síntoma sin identificar el enlace que retrasa el primer byte.
Tiempo hasta el primer byte mide el tiempo entre la solicitud HTTP y la recepción del primer byte de respuesta. Condensa DNS, TLS, enrutamiento de red, cola de servidor, ejecución de PHP, consultas SQL y, opcionalmente, llamadas API. Comprar CPU no acorta la resolución DNS lenta ni una unión SQL no indexada.
Mida correctamente, sin quedar atrapado en el caché
Un TTFB de “laboratorio” y un TTFB de “usuario real” cuentan dos historias. PageSpeed y Lighthouse a menudo miden desde los centros de datos de Google, a veces con almacenamiento en caché en caliente. WebPageTest, un curl de su máquina o informes RUM (Real User Monitoring) completan el cuadro.
Procedimiento mínimo:
- Prueba 'origen: URL directa del servidor o encabezado
Cache-Control: no-cache. - Comparar caché activado/desactivado: una página estática (
/favicon.ico) frente a una página PHP dinámica. - Repetir desde dos regiones: latencia de la red ≠ lentitud de la aplicación.
- Tenga en cuenta la hora: una piscina lenta a las 2 p. m. puede ser aceptable a las 3 a.m.
| Medición | Lo que aísla | Límite |
|---|---|---|
Página estática .html de TTFB | Red + servidor web | Ignorar PHP/SQL |
| Página dinámica TTFB | Cadena completa | Mezcla varias causas |
curl -w '%{time_starttransfer}' | Servidor sin procesar, reproducible | Sin representación del navegador |
PHP-FPM registra slowlog | Scripts > umbral (ej. 5 s) | No puedo ver MySQL solo |
Un TTFB excelente en una página CDN no demuestra que su WordPress sea rápido. Sobre todo, demuestra que el caché perimetral funciona.
La cadena de sospechosos, en orden útil
Antes de abrir un ticket de "servidor lento", revise esta lista. Cada enlace tiene señales distintas.
DNS. Un TTL mal configurado o una resolución lenta agrega entre 100 y 300 ms antes de que el servidor responda. Consulte con dig o herramientas como DNSPerf.
TLS y HTTP/2. La negociación SSL a través de un certificado mal encadenado o un cifrado obsoleto cuesta tiempo. Rara vez es el principal obstáculo, pero es mensurable.
Cola PHP-FPM. Si todos los trabajadores están ocupados, la solicitud espera: el TTFB se activa sin que el script sea lento. Síntoma: TTFB variable, picos correlacionados con el tráfico.
Script PHP lento. Complementos de WordPress, carga automática pesada, bucles innecesarios. El slowlog de FPM y Blackfire identifican la función culpable.
Base de datos. Consultas sin índices, tablas postmeta sobrecargadas, ausencia de caché de objetos (Redis). MySQL slow_query_log es tu amigo.
Llamadas externas. Las API de pago, CRM y clima sincrónico en la representación de la página bloquean todo el TTFB.
Escenarios típicos: A vs B
| Síntoma | Causa probable | Acción antes de la actualización |
|---|---|---|
| TTFB estable ~800 ms, poco tráfico | Consulta SQL o complemento | Generador de perfiles, índice, caché de objetos |
| TTFB 200 ms por la mañana, 2 s al mediodía | Trabajadores FPM saturados | Ajuste pm.max_children, no solo la CPU |
| TTFB bien en Francia, lento en EE.UU. | Geografía, no servidor | CDN o región más cercana |
TTFB 50 ms en .html, 900 ms en / | Aplicación, no alojamiento | OPcache, caché de páginas, optimizar WP |
La cumbre: la CPU rara vez es la primera palanca
Esto es lo que cubren las páginas "Oferta Premium 8 vCPU".
El anfitrión puede proporcionar un servidor rápido. No reescribe su consulta SELECT * FROM wp_postmeta. Confundir ambos retrasa la corrección real y aumenta el presupuesto sin pruebas.
Decide y avanza sin puntos ciegos
- Mida TTFB original, con y sin caché, durante 24 horas.
- Aislar el enlace (DNS → FPM → SQL → API).
- Repara la aplicación antes de comparar ofertas de hosting.
- Vuelva a realizar la prueba con el mismo escenario; sólo entonces, evalúe un plan superior o un comparador de alojamiento.
Para sitios de WordPress, haga una referencia cruzada de este diagnóstico con la guía OPcache y PHP-FPM. Para filtrar hosts según las limitaciones de su red, consulte el directorio.
Preguntas frecuentes
¿Qué TTFB es aceptable para un sitio PHP?
Por debajo de 200 ms en el lado del servidor para una página dinámica sin caché es sólido. Entre 200 y 600 ms, cavar la cadena. Más allá de eso, mida antes de comprar más recursos.
¿TTFB incluye CDN?
Sí, si la solicitud pasa por una CDN. Pruebe el origen con omisión de caché para ver el rendimiento real de PHP.
¿Cómo sé si es PHP o la base de datos?
Compare una página estática con una dinámica, active el registro de consultas lentas de MySQL y el perfil en staging con Blackfire o Xdebug.
¿El cambio de host resuelve el TTFB alto?
Rara vez sin corregir la aplicación. Un servidor sobrecargado puede añadir latencia; una consulta SQL lenta seguirá siendo lenta en todas partes.
La próxima vez que aparezca un TTFB rojo, haga una pregunta antes de comprar la CPU: ¿qué paso de la cadena tomó cuánto tiempo? La respuesta suele estar en un registro, no en una cita.