La optimización de TTFB consiste en reducir el tiempo que pasa entre que el navegador pide una página y llega el primer byte de la respuesta. Google considera bueno un Time to First Byte por debajo de 800 milisegundos y malo por encima de 1.800, medido sobre usuarios reales en el percentil 75. Como ese tiempo se consume antes de que el navegador pueda pintar nada, marca el suelo de tu Largest Contentful Paint: nunca vas a ser más rápido que tu servidor.
Casi todo el trabajo de rendimiento empieza en el sitio equivocado. Se dedica un sprint a comprimir imágenes y diferir scripts mientras el origen tarda 1,4 segundos en contestar. Nada de lo que hagas en el front recupera ese tiempo. La optimización de TTFB no luce — vive en la configuración del hosting, en las reglas de caché y en las consultas a base de datos, no en el bundle — y por eso sigue rota en tantos sitios por lo demás bien construidos.
Qué mide realmente el TTFB
El Time to First Byte es el intervalo entre el inicio de la petición de navegación y el momento en que el primer byte del HTML llega al navegador. Según la documentación de web.dev de Google, es la suma de varias fases, no un número único:
- Tiempo de redirección — cada salto antes de que responda la URL final.
- Arranque del service worker — si hay uno registrado y tiene que iniciarse.
- Resolución DNS — traducir el hostname a una dirección.
- Conexión y negociación TLS — el coste del handshake.
- Petición y respuesta — todo lo que hace el origen antes de soltar el primer byte.
Esa última fase es donde mira casi todo el mundo, y con frecuencia no es donde está el problema. He perdido la cuenta de las auditorías en las que el origen contestaba en 180 milisegundos y el TTFB medido superaba el segundo por culpa de una cadena de redirecciones y un resolver lento por delante.
Conviene ser preciso en una cosa: el TTFB es una métrica de diagnóstico, no un Core Web Vital. No aparece en el informe de Core Web Vitals de Search Console y no lleva ningún umbral de ranking asociado. Esa distinción es real, y es también la razón por la que tantos equipos lo despriorizan. La lectura correcta es que el TTFB no se puntúa directamente: lo consume una métrica que sí se puntúa.
Por qué la optimización de TTFB es un problema de SEO
El Largest Contentful Paint tiene que ocurrir dentro de 2,5 segundos en el percentil 75 del tráfico real para aprobar. La guía de optimización de LCP de Google desglosa ese presupuesto en cuatro subfases y recomienda que el TTFB no ocupe más de un 40% aproximado — unos 800 milisegundos. El 60% restante cubre el retardo de carga del recurso, su duración de descarga y el retardo de renderizado del elemento.
Haz la cuenta. Si tu TTFB es de 1,2 segundos, has gastado casi la mitad del presupuesto de LCP antes de que se haya parseado un solo byte de HTML. Ahora te toca descubrir, descargar y pintar una imagen hero en 1,3 segundos, en un móvil de gama media y con red móvil. Rara vez sale.
Por eso la optimización de TTFB suele ser el arreglo con más palanca de una página que no aprueba. Medio segundo menos en el servidor se traslada íntegro al Largest Contentful Paint de todos los usuarios, en todas las plantillas, sin tocar el front. Muy pocas cosas en rendimiento tienen ese radio de impacto por hora invertida.
La segunda razón es el rastreo. La documentación de crawl budget de Google dice sin rodeos que Googlebot ajusta su ritmo de rastreo según cómo responda el servidor: si el sitio se ralentiza o empieza a devolver errores 5xx, el límite de rastreo baja. En un catálogo de ecommerce grande o en un proyecto de SEO programático, el tiempo de respuesta del servidor deja de ser un detalle de UX y se convierte en el regulador de cuánto de tu sitio se descubre y se actualiza.
Las dos vías son indirectas. Ninguna es teórica. Un origen lento te cuesta los empates de ranking vía Core Web Vitals y te cuesta cobertura de índice vía ritmo de rastreo, y hace las dos cosas en silencio.
Cómo medir el TTFB antes de tocar nada
Datos de campo primero, siempre. Las herramientas de laboratorio miden la fibra de tu oficina, no a tus usuarios.
- Chrome UX Report vía PageSpeed Insights te da el TTFB real en percentil 75 para una URL o para todo el origen, en ventana móvil de 28 días. Este es el número que cuenta.
- El informe de Core Web Vitals de Search Console no muestra TTFB, pero un fallo generalizado de LCP sin causa evidente de bloqueo de renderizado es casi siempre un problema de servidor.
- La Navigation Timing API en campo —
performance.getEntriesByType('navigation')[0].responseStart— recogida con tu herramienta de RUM y segmentada por plantilla y por país. curl -wdesde varias regiones para una lectura limpia y sin caché del origen por su cuenta.
El paso de segmentación es el que todo el mundo se salta y el que encuentra el fallo. Auditando sitios de tamaño medio, la media de TTFB a nivel de origen casi siempre esconde la historia real: la home está cacheada y va rápida, y una sola plantilla sin caché — el buscador interno, una categoría filtrada, el área de cliente — se lleva ella sola el percentil 75 por encima del umbral.
Así que mide por plantilla y separa cacheado de no cacheado. Una página que se sirve en 40 milisegundos desde el edge y en 1,6 segundos cuando falla la caché no tiene un problema de velocidad de servidor: tiene un problema de cache hit ratio, y el arreglo es completamente distinto.
La auditoría de TTFB en siete etapas
Trabájalas en orden. Cada etapa está por delante de la siguiente, así que arreglar la sexta con la segunda rota no cambia nada de lo que percibe un usuario real.
1. Redirecciones. Cuenta los saltos en tus URLs de entrada canónicas. http:// → https:// → www. → URL final son tres viajes de ida y vuelta antes de que el servidor haya hecho nada, y cada uno cuesta un ciclo completo de resolución, conexión y petición en conexión fría. Colápsalas a una sola redirección en el edge. Son los 200–400 milisegundos más baratos que vas a encontrar.
2. DNS. Mide el tiempo de resolución desde los mercados que realmente atiendes. Los nameservers de un registrador barato sin anycast pueden añadir 100 milisegundos a un usuario lejos del servidor autoritativo. Es un caso típico en proyectos españoles que venden también a México, Colombia o Chile. Pásate a un proveedor con DNS anycast global y ajusta los TTL.
3. Establecimiento de conexión. Confirma que se negocia HTTP/2 o HTTP/3, que usas TLS 1.3 y que la reanudación de sesión está activa. Comprueba el OCSP stapling: un navegador bloqueado esperando la validación del certificado es un impuesto real e invisible sobre el tiempo de respuesta del servidor.
4. Caché en el edge. ¿Qué porcentaje de peticiones de HTML se sirve desde el CDN y no desde el origen? Si cacheas los estáticos y dejas pasar todo el HTML, la mayor ganancia sigue sin tocar. Cachea el documento con un TTL corto y stale-while-revalidate, y purga al publicar.
5. Caché en origen. Por detrás del CDN, ¿hay caché de página completa, caché de objetos o nada? Las plantillas sin caché son donde muere el TTFB. En WordPress y en la mayoría de CMS con hosting compartido esta etapa suele explicar el problema entero. Lístalas por nombre y decide para cada una: cacheable, cacheable en parte con ESI, o realmente dinámica.
6. Trabajo de aplicación. Para las plantillas que de verdad no se pueden cachear, perfila la petición. Los sospechosos habituales son consultas N+1, búsquedas sin índice sobre tablas grandes, llamadas síncronas a APIs de terceros dentro del ciclo de petición y gestión de sesión que golpea la base de datos en cada carga. Saca del ciclo todo lo que no haga falta para renderizar la respuesta.
7. Infraestructura. Solo ahora tiene sentido preguntarse si el servidor se queda corto, si la base de datos está en otra región que la aplicación o si el plan de hosting es el límite. Ampliar hardware antes de trabajar las etapas uno a seis es comprar velocidad al peor precio por milisegundo posible.
Los arreglos que de verdad mueven el número
Algunas intervenciones rinden siempre y otras son teatro. Ordenadas más o menos por retorno:
Cachear el HTML en el edge. Para cualquier sitio cuyas páginas no cambien por usuario, esto es el partido entero. Un documento cacheado servido desde un nodo cercano convierte un TTFB de 900 milisegundos en uno de 80. Todo lo demás de esta lista es más pequeño.
Matar la cadena de redirecciones. Gratis, rápido y permanente. Resuelve la canonicalización de protocolo y host en una única regla en el edge, no en una escalera de rewrites a nivel de servidor.
Arreglar la consulta más lenta, no todas. Perfila la plantilla sin caché y normalmente encontrarás una sola consulta que se lleva la mayor parte del tiempo. Arreglarla es una tarde. Reescribir la capa de datos es un trimestre.
Acercar el renderizado al usuario. Si renderizas en servidor desde una región y un tercio del tráfico está en otra, la distancia por sí sola son 100–150 milisegundos inevitables. Un origen en Fráncfort sirviendo a Latinoamérica es el ejemplo clásico. Renderizado en el edge o réplicas regionales lo eliminan.
Usar stale-while-revalidate. Sirve la copia cacheada al instante y refréscala en segundo plano. Los usuarios reciben respuestas a velocidad de edge y un fallo de caché deja de ser un precipicio.
Hacer streaming de la respuesta. Si tu framework lo soporta, vuelca el head del documento — con sus preload y preconnect — antes de tener el body montado. El navegador empieza a pedir recursos críticos mientras el servidor sigue trabajando. No reduce el tiempo de servidor, pero reduce el tiempo que el navegador pasa parado, que es lo que mide el LCP.
Lo que no funciona: comprimir más el HTML, cambiar de formato de imagen, diferir JavaScript. Son optimizaciones reales y ninguna toca el Time to First Byte. Mejoran lo que pasa después del primer byte.
Dónde se tuerce la optimización de TTFB
Optimizar la media. Los Core Web Vitals se evalúan en el percentil 75. Una mediana sana con una cola pesada suspende igual. Mira p75 y p95, nunca la media.
Medir desde un solo sitio. Un TTFB medido desde un datacenter en la misma región que tu origen es ficción. Mide desde donde están tus usuarios.
Creer al laboratorio antes que al campo. PageSpeed Insights enseña la prueba de laboratorio y los datos de campo uno al lado del otro. Google usa los de campo. Cuando no coincidan, gana el campo.
Cachear lo que no se debe cachear. Servir la página de un usuario logueado a otro desde una caché compartida es un incidente de seguridad, no un bug de rendimiento. Pon Cache-Control: private en las respuestas personalizadas y varía la clave de caché a propósito.
Cantar victoria antes de tiempo. El Chrome UX Report va con ventana móvil de 28 días. No verás el arreglo en datos de campo hasta pasadas semanas, y que el día diez esté plano no significa que haya fallado. Despliega, espera y luego juzga.
Desplegar cinco arreglos de golpe. Tentador, y destruye tu capacidad de atribuir la mejora. Secuéncialos o asume que nunca sabrás cuál importó: es un intercambio que conviene hacer explícito y no tropezarse con él. Es la misma disciplina que hace que montar un test A/B de SEO merezca la pena.
Empieza por el servidor y luego ve a ganar rankings
Cuando el tiempo de respuesta del servidor es el cuello de botella, suele aparecer como un fallo de LCP que nadie sabe explicar desde el front. Ese es el momento de dejar de optimizar imágenes. Una auditoría SEO técnica con segmentación de TTFB por plantilla encuentra la causa antes que otra ronda de Lighthouse, y es el tipo de trabajo para el que tiene sentido traer a un consultor SEO freelance, porque hace falta alguien que sepa leer una cascada de red y un plan de ejecución de consultas la misma tarde. Si el arreglo resulta ser arquitectónico, va en una hoja de ruta de SEO técnico y no en un ticket suelto.
La optimización de TTFB no te va a ganar sola una keyword competida. Eso lo hacen el contenido y los enlaces. Pero un origen lento pone techo a todas las métricas de rendimiento que van por detrás, limita cuánto está dispuesto Google a rastrear de tu sitio y devalúa en silencio cada optimización que despliegas. Arregla el servidor primero. Después vete a ganar los rankings donde de verdad se ganan.
