Obtén información para realizar optimizaciones en función de la métrica Tiempo hasta el primer byte.
El tiempo de primer byte (TTFB) es una métrica fundamental del rendimiento web que precede a todas las demás métricas significativas de la experiencia del usuario, como el primer procesamiento de imagen con contenido (FCP) y el procesamiento de imagen con contenido más grande (LCP). Esto significa que los valores altos de TTFB agregan tiempo a las métricas que lo siguen.
Se recomienda que tu servidor responda a las solicitudes de navegación con la suficiente rapidez para que el percentil 75 de los usuarios experimente un FCP dentro del umbral "bueno". Como guía aproximada, la mayoría de los sitios deben esforzarse por tener un TTFB de 0.8 segundos o menos.
Cómo medir el TTFB
Antes de optimizar el TTFB, debes observar cómo afecta a los usuarios de tu sitio web. Debes confiar en los datos de campo como fuente principal para observar el TTFB, ya que se ve afectado por los redireccionamientos, mientras que las herramientas basadas en laboratorios suelen medirse con la URL final, por lo que se pierde este retraso adicional.
PageSpeed Insights es una forma de obtener información de campo y de laboratorio para los sitios web públicos que están disponibles en el Informe sobre la experiencia del usuario en Chrome.
El TTFB de los usuarios reales se muestra en la sección superior Descubre lo que experimentan tus usuarios reales:
En el caso de los datos de lab, se muestra un subconjunto de TTFB en la auditoría del tiempo de respuesta del servidor:
Para obtener más información sobre cómo medir el TTFB en el campo y en el laboratorio, consulta la página de la métrica TTFB.
Comprende las diferencias entre el TTFB de campo y de laboratorio
El TTFB de laboratorio y de campo puede diferir por varios motivos. Cuando esto sucede, es importante comprender por qué para poder usar los datos de laboratorio de manera eficaz y mejorar las experiencias de los usuarios.
Cuando el TTFB del lab es mucho mayor que el TTFB del campo, esto indica que el entorno del lab tiene más limitaciones que las experiencias típicas del usuario. Esto no es necesariamente un problema, ya que es probable que los resultados y las recomendaciones del laboratorio sigan siendo válidos, pero es posible que exageren el impacto y la mejora.
Cuando el TTFB de campo es mucho mayor que el TTFB del lab, esto indica que hay problemas que no se notaron durante la ejecución del lab, como el uso de almacenamiento en caché del servidor, redireccionamientos o diferencias de red. En este caso, los resultados y las recomendaciones del lab pueden ser menos útiles, ya que se perderá uno de los problemas principales.
Para ver si la caché del servidor afecta el TTFB de Lab, prueba páginas menos comunes o usa diferentes parámetros de URL para obtener contenido sin almacenar en caché y comprobar si el TTFB está más alineado con el TTFB del campo. También puede ser útil que puedas omitir la caché del servidor con un parámetro de URL en particular. Consulta la sección de contenido almacenado en caché.
En el caso de los redireccionamientos y las diferencias de red, los análisis de cómo llega el tráfico a nuestro sitio y de dónde proviene pueden ser útiles para diagnosticar si esos son posibles problemas.
Cómo depurar un TTFB alto en el campo con Server-Timing
El encabezado de respuesta Server-Timing se puede usar en el backend de tu aplicación para medir procesos de backend distintos que podrían contribuir a una latencia alta. La estructura del valor del encabezado es flexible y acepta, como mínimo, un identificador que definas. Los valores opcionales incluyen un valor de duración (a través de dur) y una descripción opcional legible por humanos (a través de desc).
Serving-Timing se puede usar para medir muchos procesos de backend de la aplicación, pero hay algunos a los que te recomendamos prestar especial atención:
- Consultas en base de datos
- Tiempo de renderización del servidor, si corresponde
- Búsquedas de disco
- Aciertos o errores de caché del servidor perimetral (si se usa una CDN)
Todas las partes de una entrada Server-Timing se separan con dos puntos, y varias entradas se pueden separar con una coma:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
El encabezado se puede configurar con el lenguaje del backend de tu aplicación que elijas. En PHP, por ejemplo, puedes configurar el encabezado de la siguiente manera:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Cuando se configure este encabezado, aparecerá información que puedes usar en el lab y en el campo.
En el campo, cualquier página con un encabezado de respuesta Server-Timing establecido propagará la propiedad serverTiming en la API de Navigation Timing:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
En el lab, los datos del encabezado de respuesta Server-Timing se visualizarán en el panel de tiempos de la pestaña Red de Herramientas para desarrolladores de Chrome:
Encabezados de respuesta de Server-Timing visualizados en la pestaña de red de las Herramientas para desarrolladores de Chrome. Aquí, Server-Timing se usa para medir si una solicitud de un recurso llegó a la caché de la CDN y cuánto tiempo tarda la solicitud en llegar al servidor perimetral de la CDN y, luego, al origen.
Una vez que hayas determinado que tienes un TTFB problemático a partir del análisis de los datos disponibles, puedes pasar a solucionar el problema.
Formas de optimizar el TTFB
El aspecto más desafiante de optimizar el TTFB es que, si bien la pila del frontend de la Web siempre será HTML, CSS y JavaScript, las pilas del backend pueden variar significativamente. Existen varias pilas de backend y productos de base de datos que tienen sus propias técnicas de optimización. Por lo tanto, esta guía se enfocará en lo que se aplica a la mayoría de las arquitecturas, en lugar de enfocarse únicamente en la orientación específica de la pila.
Orientación específica de la plataforma
La plataforma que usas para tu sitio web puede afectar en gran medida el TTFB. Por ejemplo, el rendimiento de WordPress se ve afectado por la cantidad y calidad de los complementos, o los temas que se usan. Otras plataformas se ven afectadas de manera similar cuando se personalizan. Consulta la documentación de tu plataforma para obtener consejos específicos del proveedor que complementen los consejos de rendimiento más generales de esta publicación. La auditoría de Lighthouse para reducir los tiempos de respuesta del servidor también incluye algunas guías específicas de la pila limitadas.
Hosting, hosting, hosting
Antes de considerar otros enfoques de optimización, el alojamiento debe ser lo primero que tengas en cuenta. No podemos ofrecerte mucha orientación específica, pero una regla general es asegurarte de que el host de tu sitio web sea capaz de manejar el tráfico que le envías.
Por lo general, el hosting compartido será más lento. Si ejecutas un sitio web personal pequeño que entrega principalmente archivos estáticos, es probable que esto esté bien, y algunas de las técnicas de optimización que se indican a continuación te ayudarán a reducir el TTFB tanto como sea posible.
Sin embargo, si ejecutas una aplicación más grande con muchos usuarios que incluye la personalización, la consulta de bases de datos y otras operaciones intensivas del servidor, tu elección de hosting se vuelve fundamental para reducir el TTFB en el campo.
Cuando elijas un proveedor de hosting, ten en cuenta lo siguiente:
- ¿Cuánta memoria se asignó a la instancia de tu aplicación? Si tu aplicación tiene memoria insuficiente, se producirá un desorden y tendrá dificultades para entregar páginas lo más rápido posible.
- ¿Tu proveedor de hosting mantiene tu pila de backend actualizada? A medida que se lanzan nuevas versiones de los lenguajes de backend de aplicaciones, las implementaciones de HTTP y el software de base de datos, el rendimiento de ese software mejorará con el tiempo. Es clave asociarse con un proveedor de hosting que priorice este tipo de mantenimiento crucial.
- Si tienes requisitos de aplicación muy específicos y deseas obtener el acceso de nivel más bajo a los archivos de configuración del servidor, pregunta si tiene sentido personalizar el backend de tu propia instancia de aplicación.
Hay muchos proveedores de hosting que se encargarán de estos aspectos por ti, pero si comienzas a observar valores de TTFB largos incluso en proveedores de hosting dedicados, es posible que debas volver a evaluar las capacidades de tu proveedor de hosting actual para poder ofrecer la mejor experiencia del usuario posible.
Usa una red de distribución de contenidos (CDN)
El tema del uso de CDN es muy conocido, pero por una buena razón: podrías tener un backend de aplicación muy bien optimizado, pero los usuarios ubicados lejos de tu servidor de origen podrían experimentar un TTFB alto en el campo.
Las CDN resuelven el problema de la proximidad de los usuarios a tu servidor de origen mediante una red distribuida de servidores que almacenan en caché recursos en servidores que están físicamente más cerca de tus usuarios. Estos servidores se denominan servidores perimetrales.
Los proveedores de CDN también pueden ofrecer beneficios más allá de los servidores perimetrales:
- Los proveedores de CDN suelen ofrecer tiempos de resolución de DNS extremadamente rápidos.
- Es probable que una CDN entregue tu contenido desde servidores perimetrales con protocolos modernos, como HTTP/2 o HTTP/3.
- En particular, HTTP/3 resuelve el problema de bloqueo de fila en TCP (en el que se basa HTTP/2) con el protocolo UDP.
- Es probable que una CDN también proporcione versiones modernas de TLS, lo que reduce la latencia involucrada en el tiempo de negociación de TLS. En particular, TLS 1.3 está diseñado para mantener la negociación de TLS lo más breve posible.
- Algunos proveedores de CDN proporcionan una función que suele denominarse "trabajador de borde", que usa una API similar a la de la API de Service Worker para interceptar solicitudes, administrar de forma programática las respuestas en las cachés de borde o reescribir las respuestas por completo.
- Los proveedores de CDN son muy buenos para optimizar la compresión. La compresión es difícil de hacer correctamente por tu cuenta y puede generar tiempos de respuesta más lentos en ciertos casos con marcado generado de forma dinámica, que se debe comprimir sobre la marcha.
- Los proveedores de CDN también almacenarán automáticamente en caché las respuestas comprimidas para los recursos estáticos, lo que generará la mejor combinación de relación de compresión y tiempo de respuesta.
Si bien adoptar una CDN implica un esfuerzo variable, desde trivial hasta significativo, debería ser una prioridad optimizar el TTFB si tu sitio web aún no usa una.
Usa contenido almacenado en caché siempre que sea posible
Las CDN permiten que el contenido se almacenen en caché en servidores perimetrales que se encuentran físicamente más cerca de los visitantes, siempre que el contenido esté configurado con los encabezados HTTP Cache-Control adecuados. Si bien esto no es adecuado para el contenido personalizado, requerir un viaje de ida y vuelta al origen puede anular gran parte del valor de una CDN.
En el caso de los sitios que actualizan su contenido con frecuencia, incluso un tiempo de almacenamiento en caché breve puede generar mejoras notables en el rendimiento de los sitios con mucho tráfico, ya que solo el primer visitante durante ese tiempo experimenta la latencia completa al servidor de origen, mientras que todos los demás visitantes pueden volver a usar el recurso almacenado en caché del servidor perimetral. Algunas CDN permiten la invalidación de la caché en las versiones del sitio, lo que permite lo mejor de ambos mundos: tiempos de almacenamiento en caché largos, pero actualizaciones instantáneas cuando sea necesario.
Incluso cuando la caché está configurada correctamente, se puede ignorar mediante el uso de parámetros de cadena de consulta únicos para la medición de Analytics. Es posible que la CDN los considere contenido diferente a pesar de que sean iguales, por lo que no se usará la versión almacenada en caché.
Es posible que el contenido más antiguo o menos visitado tampoco se almacene en caché, lo que puede generar valores de TTFB más altos en algunas páginas que en otras. Aumentar los tiempos de almacenamiento en caché puede reducir el impacto de esto, pero ten en cuenta que, con un aumento de los tiempos de almacenamiento en caché, aumenta la posibilidad de entregar contenido potencialmente inactivo.
El impacto del contenido almacenado en caché no solo afecta a quienes usan CDN. Es posible que la infraestructura del servidor deba generar contenido a partir de búsquedas costosas en la base de datos cuando no se pueda volver a usar el contenido almacenado en caché. A menudo, los datos a los que se accede con más frecuencia o las páginas almacenadas en caché pueden tener un mejor rendimiento.
Evita que haya varias redirecciones de página
Un factor común que genera un TTFB alto son los redireccionamientos. Los redireccionamientos ocurren cuando una solicitud de navegación para un documento recibe una respuesta que le informa al navegador que el recurso existe en otra ubicación. Un redireccionamiento puede agregar latencia no deseada a una solicitud de navegación, pero puede empeorar si ese redireccionamiento apunta a otro recurso que genera otro redireccionamiento, y así sucesivamente. Esto puede afectar especialmente a los sitios que reciben grandes volúmenes de visitantes de anuncios o boletines informativos, ya que suelen redireccionar a través de servicios de estadísticas con fines de medición. Eliminar los redireccionamientos que están bajo tu control directo puede ayudarte a obtener un buen TTFB.
Existen dos tipos de redireccionamientos:
- Redireccionamientos del mismo origen, en los que el redireccionamiento se produce por completo en tu sitio web.
- Redireccionamientos de origen cruzado, en los que el redireccionamiento se produce inicialmente en otro origen (por ejemplo, desde un servicio de acortamiento de URLs de redes sociales) antes de llegar a tu sitio web.
Te recomendamos que te enfoques en eliminar los redireccionamientos del mismo origen, ya que es algo sobre lo que tendrás control directo. Esto implicaría verificar los vínculos de tu sitio web para ver si alguno de ellos genera un código de respuesta 302 o 301. A menudo, esto puede deberse a que no se incluye el esquema https:// (por lo que los navegadores usan de forma predeterminada http://, que luego redirecciona) o porque las barras finales no se incluyen o excluyen de forma adecuada en la URL.
Los redireccionamientos entre orígenes son más complicados, ya que a menudo están fuera de tu control, pero intenta evitar los redireccionamientos múltiples siempre que sea posible, por ejemplo, usando varios acortadores de vínculos cuando compartas vínculos. Asegúrate de que la URL que se proporciona a los anunciantes o boletines informativos sea la URL final correcta para no agregar otro redireccionamiento a los que usan esos servicios.
Otra fuente importante de tiempo de redireccionamiento puede provenir de los redireccionamientos de HTTP a HTTPS. Una forma de evitar este problema es usar el encabezado Strict-Transport-Security (HSTS), que aplicará HTTPS en la primera visita a un origen y, luego, le indicará al navegador que acceda de inmediato al origen a través del esquema HTTPS en visitas futuras.
Una vez que tengas una buena política de HSTS implementada, puedes acelerar el proceso en la primera visita a un origen si agregas tu sitio a la lista de precarga de HSTS.
Cómo transmitir el marcado al navegador
Los navegadores están optimizados para procesar el marcado de manera eficiente cuando se transmite, lo que significa que el marcado se maneja en fragmentos a medida que llega del servidor. Esto es fundamental en el caso de cargas útiles de marcado grandes, ya que significa que el navegador puede analizar los fragmentos de marcado de forma incremental, en lugar de esperar a que llegue toda la respuesta para que pueda comenzar el análisis.
Si bien los navegadores son excelentes para controlar el marcado de transmisión, es fundamental hacer todo lo posible para que esa transmisión fluya, de modo que esos bits iniciales de marcado estén en camino lo antes posible. Si el backend está deteniendo el proceso, eso es un problema. Debido a que las pilas de backend son numerosas, estaría fuera del alcance de esta guía abordar cada pila y los problemas que podrían surgir en cada una de ellas.
React, por ejemplo, y otros frameworks que pueden renderizar el lenguaje de marcado a pedido en el servidor, usan un enfoque síncrono para la renderización del servidor. Sin embargo, las versiones más recientes de React implementaron métodos de servidor para transmitir el marcado a medida que se renderiza. Esto significa que no tienes que esperar a que un método de la API del servidor de React renderice toda la respuesta antes de que se envíe.
Otra forma de garantizar que el marcado se transmita al navegador rápidamente es depender de la renderización estática, que genera archivos HTML durante el tiempo de compilación. Con el archivo completo disponible de inmediato, los servidores web pueden comenzar a enviarlo de inmediato, y la naturaleza inherente de HTTP generará un marcado de transmisión. Si bien este enfoque no es adecuado para todas las páginas de todos los sitios web (como las que requieren una respuesta dinámica como parte de la experiencia del usuario), puede ser beneficioso para aquellas páginas que no requieren que el marcado se personalice para un usuario específico.
Usa un trabajador de servicio
La API de Service Worker puede tener un gran impacto en el TTFB de los documentos y los recursos que cargan. El motivo es que un trabajador de servicio actúa como proxy entre el navegador y el servidor, pero si hay un impacto en el TTFB de tu sitio web depende de cómo configures el trabajador de servicio y si esa configuración se alinea con los requisitos de tu aplicación.
- Usa una estrategia de inactividad durante la validación para los activos. Si un recurso se encuentra en la caché del service worker, ya sea un documento o un recurso que este requiere, la estrategia de inactividad durante la validación volverá a entregar ese recurso desde la caché primero y, luego, descargará ese recurso en segundo plano y lo entregará desde la caché para interacciones futuras.
- Si tienes recursos de documentos que no cambian con frecuencia, usar una estrategia de inactividad durante la validación puede hacer que el TTFB de una página sea casi instantáneo. Sin embargo, esto no funciona tan bien si tu sitio web envía lenguaje de marcado generado de forma dinámica, como el lenguaje de marcado que cambia según si un usuario está autenticado. En esos casos, siempre debes acceder a la red primero para que el documento esté lo más actualizado posible.
- Si tu documento carga recursos no esenciales que cambian con cierta frecuencia, pero recuperar el recurso inactivo no afectará en gran medida la experiencia del usuario (como imágenes seleccionadas o recursos que no son esenciales), el TTFB de esos recursos se puede reducir considerablemente con una estrategia de inactividad durante la validación.
- Usa el modelo de shell de la app para aplicaciones renderizadas por el cliente. Este modelo es más adecuado para SPA en los que el "shell" de la página se puede entregar de forma instantánea desde la caché del trabajador del servicio, y el contenido dinámico de la página se propaga y renderiza más adelante en el ciclo de vida de la página.
Usa 103 Early Hints para recursos críticos de renderización
Independientemente de qué tan bien esté optimizado el backend de tu aplicación, es posible que el servidor deba realizar una cantidad significativa de trabajo para preparar una respuesta, incluido el trabajo costoso (pero necesario) de la base de datos que retrasa la llegada de la respuesta de navegación lo más rápido posible. El efecto potencial de esto es que algunos recursos críticos de renderización posteriores podrían retrasarse, como CSS o, en algunos casos, JavaScript que renderiza el marcado en el cliente.
El encabezado 103 Early Hints es un código de respuesta anticipada que el servidor puede enviar al navegador mientras el backend está ocupado preparando el marcado. Este encabezado se puede usar para indicarle al navegador que hay recursos críticos de renderización que la página debe comenzar a descargar mientras se prepara el marcado. En el caso de los navegadores compatibles, el efecto puede ser una renderización de documentos (CSS) y una carga de páginas más rápidas.
Una desventaja de los indicadores anticipados 103 es que, al igual que el almacenamiento en caché, pueden enmascarar el TTFB "real" de un sitio. Si la infraestructura de un servidor es lenta (ya sea porque no tiene suficiente potencia o porque el código necesita optimización), eso puede ser menos evidente cuando se usan los indicadores anticipados 103, ya que el TTFB parece ser rápido. Los sitios que usan 103 sugerencias anticipadas deben considerar medir la hora real del servidor (a través de Server-Timing o finalResponseHeadersStart de la API de PerformanceNavigationTiming).
Conclusión
Dado que hay muchas combinaciones de pilas de aplicaciones de backend, no hay un artículo que pueda encapsular todo lo que puedes hacer para reducir el TTFB de tu sitio web. Sin embargo, estas son algunas opciones que puedes explorar para intentar que todo funcione un poco más rápido en el servidor.
Al igual que con la optimización de cada métrica, el enfoque es bastante similar: mide tu TTFB en el campo, usa herramientas de lab para desglosar las causas y, luego, aplica optimizaciones siempre que sea posible. Es posible que no todas las técnicas que se mencionan aquí sean viables para tu situación, pero algunas sí lo serán. Como siempre, deberás supervisar de cerca tus datos de campo y realizar los ajustes necesarios para garantizar la experiencia del usuario más rápida posible.
Imagen hero de Taylor Vick, de Unsplash.