En btlabs Core, un tiempo de respuesta de un sitio web inferior a 200 ms se refiere al Tiempo hasta el Primer Byte (TTFB) : el tiempo transcurrido desde el inicio de la navegación hasta la llegada del primer byte de respuesta. Este valor no describe el tiempo total de carga ni la puntuación de Lighthouse. Sin embargo, sin datos brutos sobre la URL de prueba, la región de prueba, el estado de la caché, la mediana y el percentil 95, un tiempo inferior a 200 ms no constituye una garantía de rendimiento generalmente verificable.
Esta distinción es importante. En más de 20 años de desarrollo web, he visto con frecuencia a pymes presentar una única métrica impresionante sin explicar la medición ni las condiciones de la prueba. Una puntuación alta puede ser precisa, pero aun así revela poco sobre la capacidad de respuesta diaria del sitio web.
Para hacer una afirmación fiable sobre la velocidad de un sitio web, se necesita una métrica clara, un protocolo de medición abierto y resultados que puedan reproducirse en las mismas condiciones.
¿Qué mide realmente el tiempo de respuesta de un sitio web?
Según web.dev, el Tiempo hasta el Primer Byte (TTFB) mide el tiempo transcurrido desde el inicio de la navegación hasta la llegada del primer byte de respuesta. El TTFB incorpora varias fases:
- posibles redirecciones,
- el comienzo de un trabajador de servicios, si es que existe,
- resolución DNS,
- el establecimiento de la conexión y la negociación TLS,
- la transmisión de la solicitud y el procesamiento hasta el primer byte de respuesta.
TTFB se suele abreviar como tiempo de respuesta del servidor de un sitio web. Este término es incompleto, ya que también incluye las fases de red previas al procesamiento real en el servidor. La ubicación del servidor, el enrutamiento y la distancia entre la región de prueba y el centro de datos afectan al tiempo de respuesta del sitio web, al igual que la propia aplicación.
En este artículo, el término "tiempo de respuesta" se refiere consistentemente al TTFB (Time To First By). El tiempo de respuesta de un sitio web tras un clic dentro de una interfaz de usuario ya cargada es una métrica diferente.
Clasificación correcta de tiempos de respuesta de sitios web inferiores a 200 ms
Web.dev cita un TTFB de no más de 0,8 segundos (800 ms) como referencia para un buen rendimiento. Los valores superiores a 1,8 segundos se consideran deficientes; cualquier valor intermedio indica que se necesita mejorar. Sin embargo, el TTFB no es un Core Web Vital. Por lo tanto, estos umbrales sirven como guía y no como el único criterio para evaluar la experiencia del usuario.
Un tiempo de respuesta medido de un sitio web inferior a 200 ms sería un resultado excepcionalmente rápido. Sin embargo, esto no garantiza que todas las URL, todas las solicitudes y todas las regiones se mantengan consistentemente por debajo de los 200 ms. Las funciones dinámicas, el contenido personalizado, un fallo de caché o una alta carga del servidor pueden generar resultados diferentes.
Para btlabs Core, la documentación proporcionada no incluye un conjunto completo de datos brutos con fecha de prueba, mediciones individuales, mediana y percentil 95. Por lo tanto, la indicación "menos de 200 ms" se presenta aquí como una especificación de rendimiento que debe verificarse, y no como un resultado de medición documentado de forma definitiva. Una verificación fiable requiere la publicación de una serie completa de mediciones.
TTFB, tiempo de carga, LCP y puntuación de Lighthouse diferencian
TTFB: ¿Cuándo comienza la respuesta?
El TTFB finaliza en cuanto llega el primer byte de respuesta. En este punto, es posible que aún falten imágenes, fuentes, hojas de estilo y archivos JavaScript. Un TTFB bajo indica un buen punto de partida, pero no garantiza que la página completa sea visible o utilizable.
Tiempo total de carga: ¿Cuándo finaliza el proceso de carga?
El tiempo total de carga no es una métrica de rendimiento única y universalmente definida. Según la herramienta, puede referirse al evento de carga en sí o a un momento posterior con baja actividad de red. Los archivos multimedia, las fuentes, los scripts y los servicios externos pueden aumentar el tiempo de carga incluso después de que se haya recibido el primer byte HTML.
Pintura con el contenido más grande: ¿Cuándo aparece el contenido visible de mayor tamaño?
Según web.dev, el Largest Contentful Paint (LCP) mide el tiempo de renderizado de la imagen, el bloque de texto o el vídeo más grande visible en el área de visualización. El LCP es uno de los indicadores clave de rendimiento (Core Web Vitals) y se calcula en relación con el inicio de la navegación.
TTFB y LCP miden tiempos diferentes, pero están relacionados: los retrasos hasta que se alcanza el primer byte forman parte del tiempo total de LCP. Un TTFB lento puede degradar el LCP. Por el contrario, un TTFB rápido no garantiza un buen LCP si, por ejemplo, la imagen de portada central es demasiado grande o se solicita con retraso.
Puntuación Lighthouse: ¿Cómo se evalúa el rendimiento general?
Según Chrome para desarrolladores, la puntuación de rendimiento de Lighthouse es un promedio ponderado de varias métricas. El modelo de puntuación documentado incorpora métricas como First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time y Cumulative Layout Shift. Las ponderaciones pueden variar con las nuevas versiones de Lighthouse.
Por lo tanto, la puntuación de Lighthouse no es sinónimo del tiempo de respuesta del servidor de un sitio web. Un sitio web puede tener un TTFB (Time To First By) rápido y aun así obtener una puntuación de Lighthouse mediocre. Por el contrario, una buena prueba de laboratorio de Lighthouse puede enmascarar debilidades regionales o esporádicas en el tiempo de respuesta del sitio web.
Protocolo de medición para una medición reproducible
Una medición reproducible requiere condiciones idénticas. Para btlabs Core y cualquier otro sitio web, el protocolo de medición debe contener al menos la siguiente información:
- Objeto de prueba: dominio completo y URL específica,
- Tipo de página: Página de inicio, página de contenido, página de búsqueda o función dinámica,
- Respuesta: Estado HTTP y posible cadena de redireccionamiento,
- Tiempo: Fecha, hora y zona horaria de la serie de mediciones,
- Trabajo: Nombre y versión de la herramienta de medición,
- Región de prueba: por ejemplo el norte de Italia o Europa central,
- Conexión: perfil de red definido,
- Estado de la caché: La memoria caché fría y la memoria caché caliente son independientes.
- Muestra: Número de carreras de calentamiento y mediciones evaluadas,
- Resultados: Valores individuales, mediana y p95,
- contexto: Ubicación del servidor, uso de CDN y funciones dinámicas.
Para demostrar un tiempo de respuesta del sitio web inferior a 200 ms, se debe definir una URL pública fija del núcleo de btlabs. Además, se deben incluir varias páginas de contenido típicas en la medición. Publicar solo la URL más rápida no proporcionaría una imagen representativa del sistema.
Mida la reserva fría y la reserva caliente por separado.
Una caché fría significa que la respuesta solicitada aún no se puede entregar desde una caché preparada. Es posible que la aplicación necesite leer y reprocesar el contenido de una fuente de datos. Esto suele provocar un fallo de caché.
Con una caché caliente, la respuesta, o una parte significativa de ella, ya está en la caché. Un acierto de caché puede reducir significativamente el TTFB (tiempo hasta el primer hallazgo). Ambos estados responden a preguntas diferentes:
- La prueba de caché en frío muestra el rendimiento cuando es necesario reprocesar el contenido.
- La prueba de caché caliente muestra la entrega del contenido solicitado con frecuencia.
- La relación entre aciertos y fallos de caché muestra con qué frecuencia los usuarios se benefician de la respuesta almacenada en caché.
La combinación de datos de caché fríos y calientes en un solo promedio dificulta la clasificación. Un informe transparente presenta ambas series de mediciones por separado y documenta cómo se alcanzó cada estado.
Mediana y p95 en lugar de los mejores valores individuales.
La mediana es el valor central de una serie ordenada de mediciones: la mitad de las mediciones están por debajo de ella y la otra mitad por encima. La mediana es menos sensible a los valores atípicos individuales que la media aritmética.
El valor p95 representa el percentil 95. El 95 % de las mediciones son igual de rápidas o más rápidas; el 5 % son más rápidas. El valor p95 muestra cómo se comporta el tiempo de respuesta de un sitio web en condiciones menos favorables, pero que ocurren con regularidad.
Para una PYME, ambas métricas son relevantes. La mediana describe el caso típico. El percentil 95 indica si un sistema se mantiene estable o si algunos visitantes experimentan tiempos de espera significativamente más largos. Un único valor inferior a 200 ms solo demuestra que esta velocidad se alcanzó una sola vez. Solo la mediana y el percentil 95, en conjunto, muestran la repetibilidad del rendimiento.
¿Qué arquitectura admite un TTFB rápido?
Un sitio web rápido no se crea con una sola optimización. Lo fundamental es una arquitectura que evite el procesamiento y la transmisión innecesarios.
- Interfaz de usuario simplificada: Menos código innecesario reduce el volumen de datos y el procesamiento en el navegador.
- Procesamiento del lado del servidor: El contenido preparado con antelación se puede entregar antes que el contenido creado íntegramente en el navegador.
- Almacenamiento en caché dirigido: Las solicitudes recurrentes no necesitan procesarse de nuevo cada vez.
- Cadenas de reenvío cortas: Cada redirección adicional crea otro paso de red.
- Entrega optimizada de contenido multimedia: Los formatos y tamaños adecuados mejoran principalmente el LCP y el tiempo de carga completa.
- Pocos scripts de terceros: Los servicios externos aumentan las dependencias y pueden retrasar la renderización y la interactividad.
btlabs Core está diseñado como una plataforma digital central desde la cual los sitios web y otros canales de distribución acceden a una base de contenido común. Explico los fundamentos técnicos en el artículo sobre la arquitectura de btlabs Core . Una arquitectura adecuada crea buenas condiciones, pero no reemplaza las mediciones en condiciones reales.
¿Qué influye en el tiempo de respuesta de un sitio web?
Incluso con el código sin cambios, el tiempo de respuesta del servidor de un sitio web puede fluctuar. Las causas típicas incluyen:
- la distancia entre la región de prueba y la ubicación del servidor,
- el enrutamiento del operador de red,
- la utilización actual de alojamiento, base de datos o aplicación,
- un acierto de caché o un fallo de caché
- contenido personalizado y usuarios registrados,
- funciones de búsqueda dinámica, reserva o tienda,
- interfaces externas y scripts de terceros,
- una conexión de red local inestable.
Para las empresas del Tirol del Sur, se recomienda realizar mediciones en una región de prueba relevante de Europa Central. Si un sitio web está dirigido a usuarios de Italia y la región DACH (Alemania, Austria y Suiza), conviene realizar series de mediciones adicionales en ambas zonas. Una prueba realizada en un centro de datos cercano al servidor no refleja de forma fiable la experiencia de los usuarios ubicados más lejos.
Aquí te explicamos cómo comprobar el tiempo de respuesta de un sitio web.
Para una comparación fiable, se necesita principalmente un enfoque estandarizado:
- Elija entre tres y cinco URL públicas representativas.
- Anote el estado HTTP y las redirecciones de cada URL.
- Defina una herramienta de medición y una región de prueba fija.
- Realice varias carreras de calentamiento que no estén incluidas en la evaluación.
- Luego, registre al menos 20 mediciones por URL y estado de caché.
- Mantenga la memoria caché fría y la memoria caché caliente estrictamente separadas.
- Almacena los valores individuales y calcula la mediana y el percentil 95.
- Repita la medición una segunda vez.
- Compare los sistemas únicamente bajo las mismas condiciones de prueba.
A continuación, compruebe no solo el TTFB (Tiempo hasta la primera visita), sino también el rendimiento general del sitio web . La calidad percibida también incluye el contenido visible, la estabilidad visual, la interactividad y una navegación clara para el usuario.
Después del lanzamiento, un Rendimiento Budget para sitios web de PYMES Se establecen límites para las imágenes, los scripts y los indicadores clave de rendimiento. Esto garantiza que la velocidad siga siendo un requisito de calidad constante.
Por qué esta publicación no incluye una comparación del antes y el después.
Una comparación antes y después solo tiene sentido si ambos sistemas se miden con contenido y funciones similares, la misma región de prueba, la misma herramienta y estados de caché diferentes. Dichos datos comparativos recopilados de forma uniforme no están disponibles en la documentación proporcionada.
Por lo tanto, evito utilizar valores comparativos artificiales o metodológicamente inconsistentes. Al trabajar con pymes, un dato faltante claramente identificado resulta más útil que una cifra impresionante sin una base verificable.
¿Qué datos debe contener un informe de medición de btlabs Core?
Para que un tiempo de respuesta de un sitio web sea considerado "inferior a 200 ms" como un tiempo de respuesta documentado, el informe de medición debe revelar los siguientes datos:
- Dominio probado y URL de prueba específicas,
- Fecha y hora de la medición,
- Herramienta, versión y región de prueba,
- Ubicación del servidor e infraestructura relevante,
- Número de carreras de calentamiento y mediciones,
- Resultados de caché fría y caché caliente,
- Mediana y p95 por URL y estado de caché,
- Valores brutos o un informe de medición exportable,
- Valores atípicos con una clasificación plausible.
Estado editorial: 25 de marzo de 2026. La infraestructura, el contenido y los servicios externos están sujetos a cambios. Por lo tanto, una serie de mediciones publicada requiere una fecha de actualización y debe repetirse tras cambios significativos.
Preguntas y respuestas sobre el tiempo de respuesta de los sitios web
¿Cuál es un buen valor de TTFB para un sitio web?
Web.dev sugiere un máximo de 800 ms como referencia para un buen TTFB (Tiempo hasta el primer byte). Para un proyecto específico de PYME, también considero la mediana, el percentil 95, la región objetivo y el tipo de página, ya que un solo umbral no representa completamente la experiencia del usuario.
¿Un TTFB inferior a 200 ms significa que el sitio web se carga en 200 ms?
No. Menos de 200 ms solo significa que el primer byte de respuesta llegó dentro de ese lapso de tiempo. Las imágenes, las fuentes, JavaScript y el contenido visible aún pueden cargarse y renderizarse posteriormente.
¿Por qué la caché caliente es más rápida que la caché fría?
Con una caché activa, los datos o respuestas preelaborados se pueden entregar directamente, lo que suele resultar en un acierto de caché. Con una caché inactiva, el sistema puede necesitar regenerar el contenido. Por lo tanto, ambos estados deben medirse por separado.
¿Por qué Lighthouse muestra un valor diferente al de una prueba TTFB?
Lighthouse evalúa múltiples métricas de rendimiento ponderadas en condiciones de laboratorio definidas. En cambio, una prueba TTFB solo considera el tiempo transcurrido hasta el primer byte de respuesta. Ambas mediciones responden a preguntas diferentes.
¿Es TTFB un indicador web fundamental?
No, TTFB no es una de las métricas principales de Web Vitals. Sin embargo, esta métrica influye en las fases de carga posteriores y, por lo tanto, puede retrasar el Largest Contentful Paint (LCP).
¿Debo medir el TTFB en mi dispositivo móvil o en mi ordenador de sobremesa?
Para series de mediciones comparables, se deben utilizar condiciones fijas y documentadas. Las pruebas móviles complementarias son útiles porque la cobertura de la red móvil, los dispositivos menos potentes y la calidad fluctuante de la red afectan la experiencia real del usuario.
¿Cuántas medidas necesito?
Una sola prueba no es suficiente para llegar a una conclusión fiable. Para una verificación práctica por parte de un experto en la materia, recomiendo al menos 20 mediciones evaluadas por URL y estado de caché después de varias ejecuciones de calentamiento, así como la evaluación de la mediana y el percentil 95.
¿Puedo comparar directamente dos sistemas web?
Sí, siempre que el contenido y las funciones sean comparables y la región de prueba, la herramienta, el número de mediciones y los estados de caché sean los mismos. Comparar una página de inicio sencilla con una página de tienda personalizada no sería metodológicamente correcto.
¿Garantiza btlabs Core un tiempo de respuesta del sitio web inferior a 200 ms en todo momento?
No. Una sola medición no puede ofrecer una garantía duradera para cada URL, región y función. Dicha afirmación solo puede considerarse un resultado fundamentado con un protocolo de medición completo, datos brutos, mediana y valor p95.
Conclusión: El tiempo de respuesta de un sitio web se puede evaluar de forma transparente.
Un TTFB (tiempo hasta la primera carga) bajo es valioso porque las fases de carga posteriores solo pueden continuar una vez que la respuesta ha comenzado. Sin embargo, el tiempo de respuesta del sitio web es solo un aspecto de su calidad. Para su negocio, la entrega estable, la carga rápida del contenido, la navegación intuitiva y un sistema manejable a largo plazo también son cruciales.
Por lo tanto, con btlabs Core, "menos de 200 ms" no debe presentarse como un valor óptimo aislado. Es necesaria una serie de mediciones documentadas, que incluyan las regiones de prueba relevantes, caché fría y caliente por separado, mediana, percentil 95 y datos brutos accesibles. Esto transforma una especificación de rendimiento en una medición verificable.
