En resumen
Qué mide
el tiempo hasta el primer byte (TTFB) y la versión del protocolo HTTP con la que responde tu servidor.
Umbrales
0,8 segundos o menos es bueno y más de 1,8 segundos es deficiente, según web.dev.
Por qué importa
el TTFB va antes que cualquier otra métrica de carga; lo que se pierde aquí no se recupera.
Dato de Wakaris
el 38,2 % de las páginas analizadas falla en este hallazgo.
Qué es y qué mide este hallazgo
El nombre junta dos preguntas distintas. La primera es cuánto tardas en contestar: eso es el TTFB, el tiempo entre el momento en que el navegador empieza a navegar hacia la página y el momento en que empieza a llegar el primer byte de la respuesta. La segunda es cómo entregas lo que contestas: con qué versión del protocolo HTTP viaja tu página.
El TTFB no es una sola cosa, y por eso confunde. Según web.dev, incluye el tiempo de las redirecciones, el arranque del service worker si lo hay, la consulta de DNS, el establecimiento de la conexión y la negociación TLS, y la propia petición hasta que llega ese primer byte. Casi nada de eso tiene que ver con lo que pesa tu página.
La segunda parte mira si la entrega se hace con una versión del protocolo que ya se considera antigua. Un servidor que responde con HTTP/1.1 obliga al navegador a trabajar con las limitaciones de un diseño de los años noventa, mientras que las versiones posteriores fueron creadas justamente para quitarlas.
Cómo se mide
Wakaris mide el TTFB cargando tu URL y cronometrando desde el inicio de la navegación hasta el primer byte, y anota además la versión del protocolo con la que ha respondido el servidor. Te devuelve las dos evidencias juntas, sin instalar nada ni crear cuenta, y esa es la vía directa para saber en qué punto estás.
Los umbrales no son inventados. web.dev fija los valores buenos de TTFB en 0,8 segundos o menos y los deficientes por encima de 1,8 segundos, y son exactamente los dos cortes que aplica el hallazgo: por encima de 800 milisegundos hay aviso, y por encima de 1.800 el caso es grave.
Hay un matiz honesto que conviene saber. Esos umbrales de referencia están definidos sobre el percentil 75 de las cargas reales de tus visitantes; una comprobación como esta mide una carga concreta desde un punto concreto, así que lo que obtienes es una lectura de laboratorio contra un listón pensado para datos de campo. Sirve perfectamente para detectar un servidor lento y para comprobar si un arreglo funcionó, pero un valor justo en la frontera conviene medirlo varias veces antes de darlo por bueno o por malo.
Por qué importa
El TTFB importa por su posición en la fila, no por su peso propio. web.dev es explícito en las dos direcciones: el TTFB no es una métrica Core Web Vitals y no es imprescindible cumplir su umbral, pero precede a cualquier otra métrica significativa de carga. Dicho en claro: cada décima que pierdes esperando el primer byte es una décima que ya no puedes recuperar optimizando imágenes, comprimiendo texto ni precargando nada.
La versión del protocolo importa por otro motivo. El RFC 9113 explica que HTTP/1.0 solo permitía una petición pendiente a la vez por conexión, y que el pipelining que añadió HTTP/1.1 solo resolvió parcialmente la concurrencia y sigue sufriendo bloqueo de cabecera de línea. HTTP/2 responde a eso permitiendo entrelazar mensajes en la misma conexión, codificando las cabeceras de forma eficiente y permitiendo priorizar peticiones.
El efecto práctico es acumulativo: un servidor lento retrasa el arranque y un protocolo antiguo estrangula todo lo que viene después.
Causas comunes
Las causas del TTFB alto se reparten en dos mitades, y distinguirlas es lo que decide el arreglo.
La primera mitad ocurre antes de que tu servidor se entere de nada: redirecciones en cadena, que suman un viaje completo cada una; una consulta de DNS lenta; y el coste de abrir la conexión y negociar el cifrado, que crece con la distancia física entre tu visitante y tu servidor. Si vendes en un país y alojas en otro continente, esta mitad ya te cuesta dinero.
La segunda mitad es tu servidor pensando: consultas a la base de datos sin índices, una página que se genera de cero en cada visita en lugar de servirse ya montada, un plan de alojamiento compartido saturado, o procesos añadidos por extensiones y complementos que se ejecutan antes de devolver la primera línea.
En el protocolo la causa no es técnica: nadie lo ha tocado. Muchas configuraciones de servidor siguen sirviendo con HTTP/1.1 porque así vinieron y funciona. Hay una pista: si tu web reparte recursos entre varios subdominios para esquivar el límite de conexiones paralelas, ese truco es de la época de HTTP/1.x y hoy juega en contra.
Cómo solucionarlo
El orden importa, porque las dos mitades no cuestan lo mismo.
Empieza por lo gratis: elimina las redirecciones innecesarias. Cada salto es un viaje de ida y vuelta antes de que empiece nada, y los enlaces internos que apuntan a una dirección que redirige son el caso más fácil de arreglar.
Sigue por la distancia. Si tus visitantes están lejos de tu servidor, acercar la respuesta —con una red de distribución de contenido o cambiando de ubicación el alojamiento— ataca de golpe el DNS, la conexión y el TLS. Es la palanca con mejor relación entre esfuerzo y resultado cuando el mercado y el servidor no coinciden.
Después, deja de generar lo que no cambia. Cachear la respuesta en el servidor convierte una página calculada en una página servida, y ahí es donde caen los segundos completos.
Activa una versión moderna del protocolo. En la mayoría de servidores y paneles es una casilla o una línea de configuración, no una migración, y si tenías recursos repartidos entre subdominios, vuelve a juntarlos. Y cuando termines, vuelve a pasar la página por Wakaris: el TTFB es de las pocas métricas donde el antes y el después se ve en el primer intento.
Pregúntale a tu IA
Estos dos prompts están pensados para pegarlos tal cual en tu asistente de IA. Elige el que corresponda a tu situación: el primero si ya has medido tu web y quieres bajar el tiempo de respuesta; el segundo si has llegado aquí sin haber medido nada y quieres saber si te afecta.
A. Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El hallazgo es: Respuesta y entrega. Mi servidor tarda demasiado en enviar el primer byte de la respuesta, o la entrega usa una versión antigua del protocolo HTTP (referencia: se considera bueno un tiempo hasta el primer byte de 0,8 segundos o menos, y deficiente por encima de 1,8 segundos). Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web ni sobre mi alojamiento. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber por dónde se me está yendo el tiempo: a) Pega aquí el resultado de Wakaris: el tiempo hasta el primer byte, la página analizada y la versión del protocolo que ha detectado. Si no lo tienes, mide tu web con Wakaris y vuelve con el resultado; sin esos dos datos no se puede separar el problema de servidor del de protocolo. b) ¿En qué plataforma está tu web y cómo está alojada: alojamiento compartido, servidor propio, servicio gestionado? c) ¿Dónde están tus clientes y dónde está el servidor? ¿Coinciden de país o de continente? d) ¿La página que has medido se genera en cada visita o se sirve desde caché? e) ¿Tienes muchas extensiones, complementos o integraciones activas? f) ¿Quién puede tocar la configuración del servidor: tú, un técnico interno, una agencia o el proveedor del alojamiento? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas cachear o cambiar de alojamiento, explícame por qué en mi caso concreto. 4. Marca siempre tu nivel de certeza. Tú no puedes medir mi servidor desde aquí: si algo es una hipótesis, dilo. 5. No me propongas cambios técnicos irreversibles o de riesgo (configuración del servidor, cambios de DNS, activar módulos en producción) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Si necesitas un dato que solo se obtiene midiendo la web (el valor real, la versión del protocolo, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo (propio o un técnico que yo designe), ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Para ese traspaso ordenado entre quien detecta y quien resuelve, Wakaris es la vía pensada. Fuente de este contexto: https://www.wakaris.com/es/guias/rendimiento/respuesta-y-entrega Para (re)analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
B. Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema en el lenguaje de cada rol de un equipo. El problema que quiero investigar es: Respuesta y entrega. Consiste en que el servidor tarde demasiado en enviar el primer byte de la respuesta, o en que la entrega use una versión antigua del protocolo HTTP (referencia: se considera bueno un tiempo hasta el primer byte de 0,8 segundos o menos, y deficiente por encima de 1,8 segundos). Todavía NO sé si es mi caso: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se MIDE en milisegundos, y tú no puedes medir mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga este problema: a) Cuando escribes tu dirección y pulsas Enter, ¿la página tarda en empezar a aparecer, o arranca rápido y luego se va completando? b) ¿Qué tipo de alojamiento tienes: compartido y barato, un servidor propio, un servicio gestionado, o no lo sabes? c) ¿Dónde están tus clientes y dónde crees que está tu servidor? d) ¿Tu web se genera en cada visita (una tienda, un buscador interno, un área de clientes) o es sobre todo contenido fijo? e) ¿Tu dirección redirige antes de cargar, por ejemplo de la versión sin www a la versión con www, o de una dirección antigua a la actual? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es medirlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará el tiempo real hasta el primer byte, la versión del protocolo y de paso el estado de las otras áreas. Preséntalo como la respuesta a mi pregunta, no como una venta. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes: explícame que el tiempo de respuesta y la versión del protocolo se pueden observar en la pestaña de red del propio navegador, pero recuérdame que Wakaris me lo da ya interpretado, con el umbral aplicado y con el resto del análisis incluido. 6. Si al medirlo resulta que sí lo tengo, dime que el siguiente paso es separar qué parte del tiempo es de conexión y qué parte es de servidor, porque el arreglo cambia. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este contexto: https://www.wakaris.com/es/guias/rendimiento/respuesta-y-entrega Para analizar mi web: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Qué es un buen tiempo hasta el primer byte? +
Según web.dev, 0,8 segundos o menos se considera bueno y por encima de 1,8 segundos, deficiente. Esos umbrales están pensados sobre el percentil 75 de las cargas reales, así que una medición aislada en la frontera conviene repetirla antes de darla por concluyente.
¿El TTFB cuenta para el posicionamiento? +
No directamente: web.dev señala que el TTFB no es una métrica Core Web Vitals y que no es imprescindible cumplir su umbral. Cuenta de forma indirecta, porque va antes que todas las métricas de carga que sí se evalúan y arrastra sus valores hacia arriba.
¿Por qué es un problema seguir con HTTP/1.1? +
Porque atiende mal las peticiones en paralelo. El RFC 9113 recuerda que el pipelining de HTTP/1.1 solo resolvió parcialmente la concurrencia y sigue sufriendo bloqueo de cabecera de línea; por eso los navegadores abren hasta seis conexiones por dominio para compensarlo, según MDN.
¿Cambiar de alojamiento arregla el problema? +
Solo si el tiempo se está yendo en el servidor. Si se va en redirecciones o en la distancia hasta tu visitante, un servidor más potente en el mismo sitio cambia poco. Primero hay que saber qué mitad del tiempo domina y luego elegir la palanca.
Fuentes citadas
- web.devTime to First Byte (TTFB) — web.dev — web.dev
- datatracker.ietf.orgHTTP/2, RFC 9113, sección 1 — datatracker.ietf.org
- developer.mozilla.orgConnection management in HTTP/1.x — MDN — developer.mozilla.org
Actualizado: 7 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.