Velocidad de servidor y TTFB: qué controla realmente el hosting

TTFB (Time to First Byte) es el tiempo que transcurre entre el momento en que un navegador o un rastreador envía una petición HTTP y el momento en que recibe el primer byte de la respuesta. No mide cuánto tarda la página en terminar de cargar por completo, eso lo cubren otras métricas, sino específicamente cuánto tarda el servidor en empezar a responder, lo que la convierte en la métrica más directamente controlada por las decisiones de hosting, y la menos influida por lo que ocurre después en el navegador.

Las fases reales entre la petición y el primer byte

Lo que parece una única espera es en realidad una secuencia de fases independientes, cada una con su propio margen de optimización:

Resolución DNS         0–120 ms  (0 ms si ya está en caché del resolutor)
Establecimiento TCP     ~1 RTT   (ida y vuelta física hasta el servidor)
Negociación TLS        ~1–2 RTT  (menos con TLS 1.3 y reanudación de sesión)
Procesamiento servidor  variable (routing, consultas a BD, generación de HTML)
Primer byte recibido   = suma de todo lo anterior

La resolución DNS solo añade tiempo real si el resolutor del cliente no tiene ya la respuesta en caché, un factor gestionado por el TTL del registro, como se explica en la guía de DNS y SEO técnico. El establecimiento de la conexión TCP y la negociación TLS dependen sobre todo de la distancia física entre el cliente y el servidor, medida en tiempos de ida y vuelta (RTT); TLS 1.3 con reanudación de sesión puede reducir esa negociación a una sola ida y vuelta frente a las dos que requerían versiones anteriores. La única fase que el servidor controla de principio a fin es el procesamiento: el tiempo real que tarda la aplicación en decidir qué responder.

Qué controla el hosting en cada fase

El tipo de hosting determina directamente cuánta contención de recursos sufre el procesamiento del lado del servidor: en hosting compartido, decenas o cientos de cuentas compiten por el mismo CPU y la misma memoria, así que un pico de tráfico en un vecino de servidor puede degradar el TTFB de un sitio que no ha cambiado nada por su parte; un VPS o un servidor dedicado aíslan esos recursos, con un TTFB mucho más predecible bajo carga.

La ubicación física del servidor respecto a la audiencia objetivo afecta directamente al RTT de las fases de conexión: la latencia de red es, en última instancia, física, limitada por la velocidad a la que viaja la señal, así que un servidor en Europa sirviendo a una audiencia mayoritaria en Australia añade una latencia fija que ninguna optimización de código puede eliminar, solo mitigar con un CDN o con servidores adicionales más cerca de esa audiencia.

La versión de PHP y el uso de OPcache afectan directamente al tiempo de procesamiento: OPcache guarda el bytecode ya compilado de los scripts PHP en memoria, evitando volver a analizar y compilar el mismo archivo en cada petición; sin OPcache activo, cada petición paga ese coste de compilación de nuevo. Al margen de la caché, cada versión mayor de PHP ha traído mejoras de rendimiento sustanciales por sí sola: el salto de PHP 7 a PHP 8, por ejemplo, se tradujo en benchmarks públicos en mejoras de varias veces en tiempo de ejecución para cargas de trabajo típicas, con independencia de cualquier otro ajuste.

Las consultas a la base de datos son, en aplicaciones con contenido dinámico, la causa más habitual de un procesamiento lento: índices ausentes en columnas que se filtran u ordenan con frecuencia, o patrones de consulta N+1 (donde una lista dispara una consulta adicional por cada elemento en vez de una sola consulta agregada) que multiplican el tiempo de respuesta sin que el volumen de datos real lo justifique.

Benchmarks concretos: qué es bueno, aceptable y deficiente

Como referencia práctica, un TTFB por debajo de 200 milisegundos se considera bueno (la propia documentación de Google ha usado históricamente esa cifra como objetivo de tiempo de respuesta de servidor); entre 200 y 600 milisegundos se considera aceptable pero mejorable; por encima de 600 milisegundos, PageSpeed Insights marca explícitamente el tiempo de respuesta del servidor como un problema a resolver. El Informe de Experiencia de Usuario de Chrome (CrUX) recoge además el TTFB como una métrica de diagnóstico independiente, no como uno de los tres Core Web Vitals en sí, pero sí como una señal que Google reporta y que ayuda a diagnosticar por qué falla el LCP.

Cómo se relaciona el TTFB con Core Web Vitals sin repetir esa guía

El TTFB no es en sí mismo un Core Web Vital, pero actúa como su suelo: ningún elemento de contenido puede empezar a pintarse antes de que el HTML que lo contiene haya empezado a llegar, así que un TTFB de 1,5 segundos deja, como máximo, un segundo de margen para cumplir el umbral "bueno" del LCP explicado en la guía de Core Web Vitals, por rápido que sea el resto del renderizado. Es la razón por la que un problema de servidor lento no se arregla optimizando imágenes o JavaScript: esas optimizaciones actúan después de que el primer byte ya ha llegado, nunca antes.

Qué puede hacerse a nivel de hosting sin tocar el código de la página

Habilitar y afinar correctamente OPcache (ajustando su asignación de memoria y la frecuencia con la que revalida los archivos modificados) suele ser la mejora más barata disponible. Una capa de caché de objetos o de consultas (Redis, Memcached) evita repetir la misma consulta pesada en cada petición cuando el resultado apenas cambia entre visitas. Mantener conexiones vivas (keep-alive) evita repetir el handshake TCP y TLS en peticiones consecutivas del mismo cliente. Un CDN con caché de contenido en el borde de la red, como se explica en la guía de caché HTTP y CDN, puede servir directamente páginas cacheables sin que la petición llegue nunca al servidor de origen. Y elegir un centro de datos cercano a la audiencia principal, o apoyarse en un CDN con enrutamiento anycast como se explica en la guía de DNS y SEO técnico, reduce en la práctica la distancia percibida sin necesidad de mover el servidor de origen.

Preguntas frecuentes