El TTFB es el tiempo que tarda el servidor en enviar el primer byte de respuesta después de que alguien teclea la URL del despacho o hace clic en un resultado de Google. Antes de ese primer byte no hay nada que pintar: ni el titular, ni el teléfono de contacto, ni el formulario de la landing. Para una web que compite por leads en Google Ads y en SEO, ese retraso inicial no es un detalle de programador: es el primer obstáculo de cada visita, y el que casi nunca se revisa. Un TTFB alto arrastra al resto de métricas de velocidad aunque el diseño esté cuidado.
Un TTFB bueno es de 0,8 segundos o menos, según el umbral que fija Google en su documentación técnica. Por encima de 1,8 segundos se considera deficiente y penaliza el resto de métricas de carga, porque ninguna puede empezar a contarse hasta que llega ese primer byte del servidor.
Qué mide realmente el TTFB de una web
El TTFB, tiempo hasta el primer byte, no es un único número: suma varias fases que ocurren antes de que el navegador reciba el primer carácter de HTML. Primero la resolución DNS, que traduce el dominio del despacho en una dirección IP. Después la conexión TCP y la negociación TLS del certificado de seguridad. Por último, el tiempo que el servidor tarda en generar la respuesta: consultar la base de datos de WordPress, ejecutar los plugins activos y montar la página antes de enviarla al navegador.
Según documenta web.dev, el TTFB es el tiempo entre el inicio de la navegación y el momento en que empieza a llegar el primer byte de la respuesta: todo lo que tarda el servidor en decir «aquí está tu página», antes de que el navegador empiece a dibujar nada.
Esta fase es distinta de lo que miden el LCP o el CLS, que describen cómo se pinta la página una vez ha empezado a llegar. El LCP suspende en 4 de cada 10 webs que se ven en el móvil precisamente por arrastrar un TTFB alto desde el arranque: si el servidor tarda dos segundos en responder, ya no queda margen para que la imagen principal cargue a tiempo. Por eso Google trata el TTFB como un indicador previo a los Core Web Vitals, no como una métrica en sí, pero sí como la que condiciona a todas las demás.
Los umbrales que marca Google antes del primer byte
La documentación de web.dev fija tres franjas, medidas sobre el percentil 75 de las visitas reales a una página:
- Bueno: 0,8 segundos o menos.
- Mejorable: entre 0,8 y 1,8 segundos.
- Deficiente: más de 1,8 segundos.
La realidad del sector está lejos de ese ideal. Según el Web Almanac 2025 de HTTP Archive, solo el 55% de las páginas analizadas en ordenador logra un TTFB bueno, y en móvil el porcentaje cae al 44%. Un despacho con una web en un hosting compartido y sin caché tiene más papeletas de caer en el tramo deficiente que de quedarse en el bueno, y nadie se lo dice hasta que se mide.
El efecto en cascada sobre el FCP y el LCP
Un TTFB de 2 segundos no suma 2 segundos al tiempo de carga: los multiplica, porque el First Contentful Paint y el Largest Contentful Paint arrancan su propio cronómetro justo después. Si el servidor tarda 2 segundos en responder y la página necesita otro segundo en pintar la imagen principal, el visitante lleva 3 segundos mirando una pantalla en blanco antes de ver el nombre del despacho. En móvil, con una conexión peor que en el ordenador de pruebas, esa cifra sube todavía más. Google no penaliza el TTFB de forma aislada, pero sí penaliza el LCP que arrastra, y el LCP sí es un factor de posicionamiento declarado.
El hosting compartido dispara el tiempo de respuesta
La causa más habitual de un TTFB alto no es el diseño de la web, sino dónde vive. En un hosting para despachos de abogados compartido, el mismo servidor físico reparte CPU y memoria entre decenas de webs ajenas; si una de ellas recibe un pico de tráfico, el servidor tarda más en responder a todas las demás, incluida la del despacho. El plan más barato suele vender espacio en disco y tráfico mensual, pero casi nunca especifica cuántas webs comparten esos mismos recursos de procesamiento en un momento dado.
Bases de datos y plugins que saturan el servidor
En WordPress, cada visita suele disparar varias consultas a la base de datos: el contenido del artículo, el menú, los widgets del lateral, los ajustes de cada plugin activo. Un despacho que acumula plugins de formularios, de SEO, de caché mal configurado y de un constructor visual puede acabar ejecutando más de treinta consultas por carga, muchas redundantes. Sin un índice correcto en las tablas o sin un objeto de caché que recuerde la respuesta anterior, el servidor repite ese trabajo en cada visita, y el TTFB sube con cada plugin nuevo que se instala sin revisar el impacto que tiene sobre el tiempo de respuesta real.
Cómo bajar el TTFB sin cambiar de hosting
Antes de plantear una migración, hay margen para actuar sobre lo que ya existe. La guía de optimización de web.dev señala el caché de página, un objeto de caché persistente y una red de distribución de contenidos como las tres palancas que más reducen el tiempo de respuesta sin tocar el hosting contratado. Para un despacho que publica artículos de blog y apenas cambia el resto de páginas, activar un CDN delante del hosting acerca una copia estática de cada página al navegador que la pide, en lugar de obligar al servidor de origen a regenerarla cada vez.
El caché de página ahorra el procesamiento repetido
Un plugin de caché de página guarda la versión ya generada de cada artículo y la sirve directamente, sin volver a consultar la base de datos ni ejecutar los plugins de nuevo. La diferencia se nota más en las páginas que reciben tráfico de varias fuentes a la vez: un artículo que llega a la vez desde Google, desde una campaña de Google Ads y desde una newsletter no tiene que regenerarse para cada visitante si ya existe una copia en caché lista para servir. Conviene revisar que el caché se invalide al publicar o editar contenido, porque una copia desactualizada sirviendo el artículo antiguo es un problema distinto, pero igual de visible para el cliente.
Factores que conviene mirar en un hosting nuevo
Cuando ni la caché ni el CDN bastan porque el servidor de base ya está saturado, toca comparar hosting. El precio mensual es el dato que más se mira y el que menos dice sobre el TTFB real. Antes de firmar conviene pedir, y exigir por escrito, estos datos:
- La ubicación física del centro de datos, que debería estar en Europa si el despacho opera en España.
- Si el almacenamiento es SSD o NVMe, y no el disco mecánico tradicional que todavía venden algunos planes económicos.
- Si el plan incluye caché a nivel de servidor, no solo un plugin que haya que instalar aparte.
- El tiempo medio de respuesta del soporte técnico, porque un pico de TTFB sin explicación exige alguien que lo revise el mismo día.
El propio examen técnico de los Core Web Vitals que pasa cualquier web es, en el fondo, un reflejo de estas decisiones de infraestructura tomadas meses antes, no de un ajuste de última hora en el diseño.
Preguntas frecuentes sobre el TTFB
¿Qué diferencia hay entre el TTFB y el tiempo de carga total?
El TTFB solo mide hasta que llega el primer byte de respuesta del servidor. El tiempo de carga total incluye además descargar imágenes, hojas de estilo y scripts, y pintar toda la página. Un TTFB bajo no garantiza una carga rápida si luego la web arrastra imágenes sin optimizar.
¿Qué TTFB es aceptable para la web de un despacho?
El umbral que marca Google como bueno es 0,8 segundos o menos, medido en el percentil 75 de las visitas. Por debajo de ese valor el servidor deja de ser el cuello de botella; por encima de 1,8 segundos conviene revisar hosting, caché o plugins antes de tocar otra cosa.
¿El certificado SSL afecta al TTFB?
La negociación TLS del certificado suma tiempo a la conexión inicial, aunque hoy es mínimo con los protocolos modernos. Un certificado mal configurado, con una cadena de confianza incompleta, sí puede añadir comprobaciones extra y empeorar el TTFB de forma apreciable.
¿Cambiar de hosting soluciona siempre un TTFB alto?
No si la causa real son plugins mal configurados o una base de datos sin optimizar: esos problemas viajan con la instalación de WordPress a cualquier servidor nuevo. Cambiar de hosting ayuda cuando el cuello de botella es la CPU o la memoria compartida, no el código de la propia web.