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 la auditoría del tiempo de respuesta del servidor, se muestra un subconjunto de TTFB:
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.
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
- Hits o misses de la caché del servidor perimetral (si usas 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 las herramientas para desarrolladores de Chrome:
Encabezados de respuesta de Server-Timing visualizados en la pestaña 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 tiempo tarda la solicitud en llegar al servidor perimetral de CDN y, luego, al origen.
Una vez que hayas determinado que tienes un TTFB problemático a través 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. Debes consultar 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 limitadas específicas de la pila.
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 personalización, consultas a 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 las 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 la aplicación, 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 presente en TCP (en el que se basa HTTP/2) mediante 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.
Se usó contenido almacenado en caché siempre que fue 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 el 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 la primera visita a un origen agregando 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 las 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 retrasa 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, lo descargará 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 un lenguaje de marcado generado de forma dinámica, como el 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 críticos que cambian con cierta frecuencia, pero recuperar el recurso inactivo no afectará mucho la experiencia del usuario (como imágenes seleccionadas o recursos que no son críticos), 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
No importa 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 el 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 más rápida (CSS) y una disponibilidad más rápida de la funcionalidad principal de la página (JavaScript).
Conclusión
Dado que hay muchas combinaciones de pilas de aplicaciones de backend, no hay un solo 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.