Ver contenido
Guía de Respuesta del Servidor: Optimiza TTFB desde la Raíz
Introducción
El Time to First Byte (TTFB) es el fundamento de toda la cadena de carga: nada más puede ocurrir—ni FCP, ni LCP, ni la ejecución de JavaScript—hasta que el navegador recibe el primer byte de HTML. Esta guía cubre cómo diagnosticar y reducir el tiempo de respuesta del servidor con técnicas concretas de base de datos, caché, CDN y hardware. El UXR SEO Analyzer reporta el TTFB de cada página que analizas en su pestaña "Performance".
Como el TTFB está al inicio de la cadena de carga, también es la optimización con el radio de impacto más amplio: un arreglo del lado del servidor normalmente se aplica a todas las páginas servidas por ese backend, no solo a la que probaste. Eso lo convierte en el punto de partida correcto para cualquier esfuerzo de rendimiento, incluso antes de tocar CSS o JavaScript.
Dos Umbrales, No Uno
Es importante distinguir dos números que a veces se confunden:
- 600 ms - el umbral del audit "Reduce server response times" de Lighthouse falla cuando el navegador espera más de 600 ms por la respuesta del servidor al documento principal
- 800 ms - el umbral recomendado de TTFB como Core Web Vital (categoría "Bueno")
Lighthouse usa un límite más estricto porque su medición de "server response time" es solo una parte del TTFB completo. El TTFB de campo también puede incluir resoluciones DNS y redirecciones—por ejemplo, si se omite la barra final, el subdominio www o el protocolo https, el servidor puede redirigir a la URL correcta antes de responder con contenido. Por eso Lighthouse aplica un límite menor (600 ms) al tiempo recomendado de TTFB para Core Web Vitals (800 ms).
Causas Comunes de TTFB Lento
El servidor puede necesitar hacer mucho trabajo para devolver una página con todo el contenido que los usuarios esperan. Por ejemplo, si un usuario revisa su historial de pedidos, el servidor debe consultar cada pedido en una base de datos e insertar ese contenido en la página. Incluso cuando el servidor no necesita hacer mucho trabajo, la latencia de red entre el cliente y el servidor puede producir tiempos de respuesta lentos.
Cómo Mejorar el Tiempo de Respuesta del Servidor
El primer paso es identificar las tareas conceptuales centrales que tu servidor debe completar para devolver el contenido de la página, y medir cuánto tarda cada una. Una vez identificadas las tareas más lentas, busca formas de acelerarlas. Existen muchas causas posibles de respuestas lentas del servidor, y por lo tanto muchas formas posibles de mejorar:
1. Optimiza la Lógica de la Aplicación
Optimiza la lógica del servidor para preparar páginas más rápido. Si usas un framework de servidor, revisa sus recomendaciones específicas para reducir el tiempo de preparación de respuestas.
2. Optimiza las Consultas a Base de Datos
Optimiza cómo tu servidor consulta las bases de datos, o migra a sistemas de base de datos más rápidos. Los índices faltantes y las consultas N+1 son las causas más frecuentes de TTFB lento en aplicaciones con contenido dinámico.
3. Actualiza el Hardware del Servidor
Actualiza el hardware de tu servidor para tener más memoria o CPU disponible cuando el cuello de botella sea capacidad de cómputo, no lógica ineficiente.
4. Usa una CDN
Usa una CDN para reducir la latencia de red. Esto es particularmente efectivo si el documento puede almacenarse en caché en el nodo de borde (edge) de la CDN, evitando que cada solicitud viaje hasta el servidor de origen.
5. Implementa Caché del Lado del Servidor
Cachear respuestas completas o fragmentos de página evita recalcular el mismo contenido en cada solicitud. Para contenido que cambia con poca frecuencia, esta es la optimización con mejor relación esfuerzo-beneficio.
Ejemplo Práctico de Diagnóstico
Una página de producto reporta un TTFB de campo de 1400 ms—en la zona "Necesita Mejora". El desglose de laboratorio en Lighthouse muestra que el documento principal tarda 1100 ms en responder, muy por encima del límite de 600 ms del audit. Perfilando el backend se descubre que la ruta ejecuta cinco consultas separadas a la base de datos, tres de ellas sin índice sobre la columna de búsqueda.
Después de agregar los índices faltantes y combinar dos de las consultas en una sola con un join, el tiempo de respuesta del servidor baja a 180 ms. El TTFB de campo mejora a ~450 ms una semana después, una vez que Google actualiza los datos de CrUX—recordando que los cambios en campo tardan en reflejarse, a diferencia de las pruebas de laboratorio que muestran el efecto de inmediato.
TTFB en Producción: Monitoreo Continuo
Medir el TTFB una sola vez no es suficiente—la carga del servidor, el tráfico y los datos cambian con el tiempo. Dos enfoques complementarios:
- Monitoreo sintético: ejecuta Lighthouse o pruebas automatizadas periódicamente desde ubicaciones fijas, para detectar regresiones antes de que lleguen a producción
- Monitoreo de usuarios reales (RUM): la librería
web-vitalspuede reportar el TTFB real de cada visita a tu sistema de analítica, capturando la variabilidad real de dispositivos, redes y ubicaciones geográficas que las pruebas sintéticas no reflejan
Search Console y el reporte de Core Web Vitals de CrUX son la fuente más confiable para saber si tu TTFB cumple el umbral "Bueno" para el 75% de tus usuarios reales, que es el criterio que Google usa para el ranking.
Cómo Diagnosticar la Causa Raíz
- Mide el TTFB de campo con el reporte de Core Web Vitals de Search Console o CrUX
- Ejecuta Lighthouse para obtener el desglose de "server response time" en condiciones de laboratorio
- Si el servidor tarda, perfila las consultas de base de datos más lentas primero—suelen ser la causa dominante
- Si la lógica del servidor es rápida pero el TTFB sigue siendo alto, sospecha de latencia de red o distancia geográfica al servidor de origen
Checklist de Respuesta del Servidor
- [ ] TTFB de campo por debajo de 800 ms en el percentil 75
- [ ] Consultas de base de datos indexadas y sin patrones N+1
- [ ] Caché del lado del servidor habilitada para contenido que no cambia en cada solicitud
- [ ] CDN configurada para servir contenido estático y, cuando sea posible, HTML cacheable desde el borde
- [ ] Cadenas de redirección eliminadas o minimizadas
Preguntas Frecuentes
¿Por qué Lighthouse usa 600 ms si el umbral de Core Web Vitals es 800 ms?
Porque el audit de Lighthouse mide solo la parte de "tiempo de respuesta del servidor" del TTFB, sin incluir DNS ni redirecciones que el TTFB completo sí contempla. El límite más estricto compensa esa diferencia de alcance.
¿Una CDN reemplaza la necesidad de optimizar la base de datos?
No, son complementarias. Una CDN reduce la latencia de red y puede servir contenido cacheado sin tocar tu servidor de origen, pero cualquier solicitud que llegue a generar contenido dinámico sigue dependiendo de que tu aplicación y tu base de datos respondan rápido.
¿El TTFB afecta directamente el ranking de SEO?
TTFB no es un Core Web Vital por sí mismo, pero es la base de LCP, que sí es un factor de ranking confirmado. Un TTFB lento retrasa todo lo que viene después en la cadena de carga.
¿Las cadenas de redirección afectan mucho el TTFB?
Sí, de forma significativa. Cada redirección (por ejemplo, HTTP a HTTPS, o sin www a con www) añade una ronda de red completa antes de que el navegador reciba el primer byte de contenido real. Dos o tres redirecciones encadenadas pueden por sí solas empujar el TTFB de campo de "Bueno" a "Necesita Mejora".
Guías Relacionadas
Referencias
- Chrome Developers - Reduce server response times
- Chrome Developers - CrUX methodology: metrics
- web.dev - Core Web Vitals