Aprende a optimizar la métrica de tiempo hasta el primer byte.
El tiempo hasta el 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 rapidez suficiente para que el percentil 75 de los usuarios experimente un FCP dentro del umbral de “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. Deberías usar los datos de campo como fuente principal para observar al TTFB como se ve afectado por los redireccionamientos, mientras que las herramientas basadas en labs suelen medirse con la URL final, por lo que no se necesita este retraso adicional.
PageSpeed Insights es una manera de obtener información de campo y de laboratorio para sitios web públicos que están disponibles en el Informe sobre la experiencia del usuario en Chrome.
El TTFB para usuarios reales se muestra en la sección superior Descubre la experiencia de tus usuarios reales:
En la auditoría del tiempo de respuesta del servidor, se muestra un subconjunto de TTFB:
Para descubrir más formas de medir el TTFB en el campo y en el lab, consulta la página de métricas de TTFB.
Depura 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 distintos procesos de backend que podrían contribuir a una latencia alta. La estructura del valor del encabezado es flexible y acepta, como mínimo, un controlador que tú 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 aplicaciones, pero es posible que desees prestar especial atención a algunos de ellos:
- Consultas en base de datos
- Tiempo de renderización del servidor, si corresponde
- Búsquedas de discos
- Aciertos o errores de caché del servidor perimetral (si se usa una CDN)
Todas las partes de una entrada Server-Timing están separadas por dos puntos y varias entradas pueden separarse 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 preferido del backend de tu aplicación. En PHP, por ejemplo, podrías 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 - $dbReadStarTime) / 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 tanto en el lab como en el campo.
En el campo, cualquier página con un encabezado de respuesta Server-Timing configurado 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 en Herramientas para desarrolladores de Chrome:
Se visualizaron los encabezados de respuesta Server-Timing 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 CDN y cuánto 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 mediante el análisis de los datos disponibles, puedes continuar con la solución del problema.
Formas de optimizar el TTFB
El aspecto más desafiante de la optimización del TTFB es que, si bien la pila de frontend de la Web siempre será HTML, CSS y JavaScript, las pilas de backend pueden variar de forma significativa. Existen varias pilas de backend y productos de bases 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 solo en la orientación específica de la pila.
Orientación específica para la plataforma
La plataforma que utilices para tu sitio web puede tener un gran impacto en el TTFB. Por ejemplo, el rendimiento de WordPress se ve afectado por la cantidad y la calidad de los complementos o por los temas que se utilizan. Otras plataformas se ven afectadas de manera similar cuando la plataforma es personalizada. Debes consultar la documentación de tu plataforma para obtener asesoramiento específico sobre el proveedor y, así, complementar los consejos de rendimiento más generales que se mencionan en esta publicación. La auditoría de Lighthouse para reducir los tiempos de respuesta del servidor también incluye una guía limitada específica de la pila.
Hosting, hosting, hosting
Antes de considerar otros enfoques de optimización, primero debes considerar el hosting. No existen muchas pautas específicas que se puedan ofrecer aquí, pero una regla general es asegurarse de que el host de su sitio web pueda manejar el tráfico que le envía.
Por lo general, el hosting compartido es más lento. Si estás ejecutando un sitio web personal pequeño que entrega principalmente archivos estáticos, esto probablemente esté bien, y algunas de las técnicas de optimización que siguen te ayudarán a reducir el TTFB lo más posible.
Sin embargo, si ejecutas una aplicación más grande con muchos usuarios que implica personalización, consultas en 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, debes tener en cuenta lo siguiente:
- ¿Cuánta memoria se asignó a la instancia de tu aplicación? Si tu aplicación tiene memoria insuficiente, hará una hiperpaginación y tendrá dificultades para entregar páginas lo más rápido posible.
- ¿Tu proveedor de hosting mantiene la pila de backend actualizada? A medida que se lanzan nuevas versiones de lenguajes de backend de aplicaciones, implementaciones HTTP y software de bases 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 tiene requisitos de aplicación muy específicos y desea el acceso de menor nivel a los archivos de configuración del servidor, pregunte si tiene sentido personalizar el backend de la instancia de su propia aplicación.
Existen muchos proveedores de hosting que se encargarán de esto por ti, pero si comienzas a observar grandes valores de TTFB incluso en proveedores de hosting dedicados, puede ser una señal de que tengas que volver a evaluar las capacidades de tu actual proveedor de hosting para que puedas brindar la mejor experiencia del usuario posible.
Usa una red de distribución de contenidos (CDN)
El tema Uso de CDN es muy conocido, pero por una buena razón: podrías tener un backend de la aplicación muy bien optimizado, pero los usuarios que se encuentran lejos del servidor de origen pueden seguir experimentando un TTFB alto en el campo.
Las CDN resuelven el problema de la proximidad de los usuarios desde tu servidor de origen mediante una red distribuida de servidores que almacenan recursos en caché en servidores físicamente más cercanos a 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.
- HTTP/3 en particular resuelve el problema de bloqueo de línea presente en TCP (en el que se basa HTTP/2) a través del protocolo UDP.
- Es probable que una CDN también proporcione versiones modernas de TLS, lo que disminuye la latencia involucrada en el tiempo de negociación de TLS. En particular, TLS 1.3 está diseñado para que la negociación de TLS sea lo más breve posible.
- Algunos proveedores de CDN proporcionan una función que suele llamarse “trabajador perimetral”, que usa una API similar a la de la API de Service Worker para interceptar solicitudes, administrar respuestas de manera programática en cachés perimetrales o reescribir respuestas por completo.
- Los proveedores de CDN son muy buenos en la optimización de la compresión. La compresión es difícil de realizar por sí sola y puede provocar tiempos de respuesta más lentos en ciertos casos con lenguaje de marcado generado de forma dinámica, que debe comprimirse 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 lleva a la mejor combinación de índice de compresión y tiempo de respuesta.
Si bien adoptar una CDN implica un esfuerzo variable, desde trivial hasta significativo, debe ser una prioridad alta a la hora de optimizar tu TTFB si tu sitio web aún no lo usa.
Usaste contenido almacenado en caché siempre que sea posible
Las CDN permiten que el contenido se almacene 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 apropiado para contenido personalizado, requerir un viaje de regreso 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 total del servidor de origen, mientras que todos los demás visitantes pueden reutilizar el recurso almacenado en caché del servidor perimetral. Algunas CDN permiten la invalidación de caché en las versiones de los sitios, lo que permite aprovechar ambos beneficios: largos tiempos de caché, pero actualizaciones instantáneas cuando es necesario.
Incluso cuando el almacenamiento en caché está configurado correctamente, esto se puede ignorar mediante el uso de parámetros de cadena de consulta únicos para la medición de estadísticas. Estos pueden parecer contenidos diferentes a la CDN a pesar de ser iguales, por lo que no se usará la versión almacenada en caché.
Es posible que el contenido más antiguo o menos visitado no 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 este problema, pero ten en cuenta que, con el aumento de los tiempos de almacenamiento en caché, existe una mayor 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 de bases de datos cuando no se pueda reutilizar 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é previamente pueden tener un mejor rendimiento.
Evita que haya varias redirecciones de página
Un factor común que contribuye a un TTFB alto son los redireccionamientos. Los redireccionamientos se producen cuando una solicitud de navegación de un documento recibe una respuesta que informa al navegador que el recurso existe en otra ubicación. Desde luego, 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 a menudo se redireccionan a través de servicios de análisis con fines de medición. Eliminar los redireccionamientos bajo tu control directo puede ayudar a lograr un buen TTFB.
Existen dos tipos de redireccionamientos:
- Redireccionamientos del mismo origen: El redireccionamiento ocurre íntegramente en tu sitio web.
- Redireccionamientos de origen cruzado: El redireccionamiento ocurre inicialmente en otro origen (como el de un servicio de acortamiento de URLs de redes sociales, por ejemplo) antes de llegar a tu sitio web.
Debes enfocarte en eliminar los redireccionamientos del mismo origen, ya que tendrás control directo sobre esto. Esto implicaría verificar los vínculos en 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:// (de manera que los navegadores usan http:// de forma predeterminada, que luego redirecciona) o porque las barras finales no se incluyen o excluyen correctamente en la URL.
Los redireccionamientos de origen cruzado son más complicados, ya que suelen estar fuera de tu control, pero trata de evitarlos siempre que sea posible; por ejemplo, puedes usar varios acortadores de vínculos cuando los compartas. Asegúrate de que la URL proporcionada a los anunciantes o a los boletines informativos sea la URL final correcta para que no se agregue otro redireccionamiento a las URLs que usan esos servicios.
Otra fuente importante de tiempo de redireccionamiento puede provenir de los redireccionamientos de HTTP a HTTPS. Una forma de evitar esto es usar el encabezado Strict-Transport-Security (HSTS), que aplicará de manera forzosa HTTPS en la primera visita a un origen y, luego, indicará al navegador que acceda de inmediato al origen a través del esquema HTTPS en visitas futuras.
Una vez que implementes una política de HSTS, puedes acelerar el proceso en la primera visita a un origen agregando tu sitio a la lista de precarga de HSTS.
Transmite lenguaje de marcado al navegador
Los navegadores están optimizados para procesar el lenguaje de marcado de forma eficiente cuando se transmite, lo que significa que el lenguaje de marcado se maneja en fragmentos a medida que llega desde el servidor. Esto es crucial cuando se trata de cargas útiles de lenguaje de marcado de gran tamaño, ya que significa que el navegador puede analizar los fragmentos de lenguaje de marcado de manera incremental, en lugar de esperar a que llegue la respuesta completa antes de que pueda comenzar el análisis.
Si bien los navegadores son excelentes para manejar el lenguaje de marcado de transmisión, es fundamental hacer todo lo posible para que la transmisión fluya y que esos fragmentos iniciales de marcado estén en camino lo antes posible. Si el backend está retrasando las cosas, eso es un problema. Debido a que las pilas de backend son numerosas, estaría fuera del alcance de esta guía cubrir cada pila y los problemas que podrían surgir en cada una de ellas en particular.
Por ejemplo, React, y otros frameworks que pueden renderizar lenguaje de marcado a pedido en el servidor, usaron 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 el lenguaje de marcado de transmisión 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 la respuesta completa antes de enviarla.
Otra forma de garantizar que el lenguaje de marcado se transmita rápidamente al navegador es utilizar 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 enviar el archivo de inmediato y la naturaleza inherente de HTTP dará como resultado un lenguaje de 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 lenguaje de marcado se personalice para un usuario específico.
Usa un service worker
La API de Service Worker puede tener un gran impacto en el TTFB tanto para los documentos como para los recursos que cargan. Esto se debe a que un service worker actúa como un proxy entre el navegador y el servidor, pero la posibilidad de que exista un impacto en el TTFB de tu sitio web depende de cómo configuraste el service worker y de si esa configuración se alinea con los requisitos de tu aplicación.
- Usa una estrategia de inactividad durante la revalidació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 revalidación inactiva entregará ese recurso desde la caché primero y, luego, descargará ese recurso en segundo plano y lo publicará desde la caché para futuras interacciones.
- Si tienes recursos de documentos que no cambian con mucha frecuencia, el uso de una estrategia de revalidación inactiva 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 lenguaje de marcado que cambia en función de si un usuario está autenticado o no. En esos casos, lo mejor es seleccionar primero la red para que el documento esté lo más actualizado posible.
- Si tu documento carga recursos no críticos que cambian con cierta frecuencia, pero recuperar el recurso inactivo no afectará en gran medida la experiencia del usuario (como la selección de imágenes o de otros recursos que no son críticos), el TTFB para esos recursos se puede reducir mucho con una estrategia de revalidación inactiva.
- Usa el modelo de shell de la app para aplicaciones renderizadas por el cliente. Este modelo se adapta mejor a las SPA, donde el "shell" de la página se puede enviar de manera instantánea desde la caché del service worker, y el contenido dinámico de la página se completa y se renderiza más adelante en el ciclo de vida de la página.
Usa 103 Early Hints para los recursos esenciales de renderización.
No importa qué tan bien esté optimizado el backend de tu aplicación, todavía podría haber una cantidad significativa de trabajo que el servidor necesita hacer para preparar una respuesta, incluido el trabajo costoso (pero necesario) de la base de datos que retrasa la respuesta de navegación para que no llegue 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 lenguaje de 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 lenguaje de marcado. Este encabezado se puede usar para indicarle al navegador que hay recursos críticos para la renderización que la página debe comenzar a descargar mientras se prepara el lenguaje de marcado. En el caso de los navegadores compatibles, el resultado puede ser una renderización más rápida de los documentos (CSS) y una disponibilidad más rápida de la funcionalidad principal de la página (JavaScript).
Conclusión
Debido a que hay tantas combinaciones de pilas de aplicaciones de backend, no hay un solo artículo que pueda encapsular todo lo que se puede hacer para reducir el TTFB de tu sitio web. Sin embargo, estas son algunas opciones que puedes explorar para hacer que todo vaya un poco más rápido desde el lado del servidor.
Al igual que con la optimización de todas las métricas, el enfoque es bastante similar: mide tu TTFB en el campo, usa herramientas de lab para desglosar las causas y, luego, aplica optimizaciones cuando sea posible. No todas las técnicas que se muestran aquí pueden ser viables para tu situación, pero algunas sí lo serán. Como siempre, tendrás que estar atento a los datos de campo y hacer los ajustes necesarios para garantizar la experiencia del usuario más rápida posible.
Hero image de Taylor Vick, de Unsplash.