El primer paso para crear un sitio web que se cargue rápidamente es recibir una respuesta oportuna del servidor para el HTML de una página. Cuando ingresas una URL en la barra de direcciones del navegador, este envía una solicitud GET al servidor para recuperarla. La primera solicitud de una página web es para un recurso HTML, y garantizar que el HTML llegue rápidamente con demoras mínimas es un objetivo clave de rendimiento.
Esa solicitud inicial de HTML pasa por varios pasos, cada uno de los cuales lleva un tiempo. Reducir el tiempo dedicado a cada paso te brinda un tiempo hasta el primer byte (TTFB) más rápido. Si bien el TTFB no es la única métrica en la que debes enfocarte cuando se trata de la velocidad de carga de las páginas, un TTFB alto sí dificulta alcanzar los umbrales designados como "buenos" para métricas como el Largest Contentful Paint (LCP) y el First Contentful Paint (FCP).
Reducir redireccionamientos
Cuando se solicita un recurso, el servidor puede responder con un redireccionamiento, ya sea con un redireccionamiento permanente (una respuesta 301 Moved Permanently) o uno temporal (una respuesta 302 Found).
Los redireccionamientos ralentizan la velocidad de carga de la página, ya que requieren que el navegador realice una solicitud HTTP adicional en la nueva ubicación para recuperar el recurso. Existen dos tipos de redireccionamientos:
- Redireccionamientos del mismo origen que ocurren completamente dentro de tu origen Estos tipos de redireccionamientos están completamente bajo tu control, ya que la lógica para administrarlos reside por completo en tu servidor web.
- Redireccionamientos de origen cruzado que se inician desde otro origen Por lo general, estos tipos de redireccionamientos están fuera de tu control.
Los redireccionamientos de origen cruzado suelen usarse en anuncios, servicios de acortamiento de URLs y otros servicios de terceros. Si bien los redireccionamientos de origen cruzado están fuera de tu control, es posible que desees verificar que evitas varios redireccionamientos, por ejemplo, tener un anuncio que vincule a una página HTTP que, a su vez, redireccione a su equivalente HTTPS o un redireccionamiento de origen cruzado que llegue a tu origen, pero que luego active un redireccionamiento del mismo origen.
Almacena en caché las respuestas HTML
Es difícil almacenar en caché las respuestas HTML, ya que la respuesta puede incluir vínculos a otros recursos críticos, como CSS, JavaScript, imágenes y otros tipos de recursos. Estos recursos pueden incluir una huella digital única en sus respectivos nombres de archivo, que cambia según el contenido de un archivo. Esto significa que tu documento HTML almacenado en caché puede quedar obsoleto después de una implementación, ya que contendría referencias a recursos secundarios desactualizados.
Sin embargo, una vida útil de la caché corta (en lugar de no usar la caché) puede tener beneficios, como permitir que un recurso se almacene en caché en una CDN (lo que reduce la cantidad de solicitudes que se entregan desde el servidor de origen) y, en el navegador, permitir que los recursos se revaliden en lugar de descargarse de nuevo. Este enfoque funciona mejor para el contenido estático que no cambia en ningún contexto, y se puede establecer un tiempo adecuado para almacenar en caché los recursos en una cantidad de minutos que consideres apropiada. Cinco minutos para los recursos HTML estáticos es una apuesta segura y garantiza que las actualizaciones periódicas no pasen desapercibidas.
Si el contenido HTML de una página está personalizado de alguna manera, por ejemplo, para un usuario autenticado, es muy probable que no quieras almacenar en caché el contenido por diversos motivos, incluidos la seguridad y la actualización. Si el navegador del usuario almacena en caché una respuesta HTML, no podrás invalidar la caché. Por lo tanto, en esos casos, es mejor evitar el almacenamiento en caché de HTML por completo.
Un enfoque cauteloso para almacenar en caché HTML podría ser usar los encabezados de respuesta ETag o Last-Modified. Un encabezado ETag, también conocido como etiqueta de entidad, es un identificador que representa de forma única el recurso solicitado, a menudo con un hash del contenido del recurso:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cada vez que cambia el recurso, se debe generar un valor ETag nuevo. En las solicitudes posteriores, el navegador envía el valor de ETag a través del encabezado de solicitud If-None-Match. Si el ETag del servidor coincide con el que envió el navegador, el servidor responde con una respuesta 304 Not Modified y el navegador usa el recurso de la caché. Si bien esto aún genera latencia de red, una respuesta 304 Not Modified es mucho más pequeña que un recurso HTML completo.
Sin embargo, la latencia de red que implica revalidar la actualización de un recurso sigue siendo una desventaja. Al igual que con muchos otros aspectos del desarrollo web, las compensaciones y los compromisos son inevitables. Depende de ti determinar si vale la pena el esfuerzo adicional de almacenar en caché el código HTML de esta manera o si es mejor no almacenar en caché el contenido HTML.
Mide los tiempos de respuesta del servidor
Si no se almacena en caché una respuesta, el tiempo de respuesta del servidor depende en gran medida de tu proveedor de hosting y de la pila de aplicaciones de backend. Una página web que publica una respuesta generada de forma dinámica (por ejemplo, que recupera datos de una base de datos) puede tener un TTFB más alto que una página web estática que se puede publicar de inmediato sin un tiempo de procesamiento significativo en el backend. Mostrar un spinner de carga y, luego, recuperar todos los datos en el cliente traslada el esfuerzo de un entorno del servidor más predecible a uno del cliente potencialmente impredecible. Por lo general, minimizar el esfuerzo del cliente mejora las métricas centradas en el usuario.
Si los usuarios experimentan un TTFB lento en el campo, puedes exponer información sobre dónde se invirtió el tiempo en el servidor a través del uso del encabezado de respuesta Server-Timing:
Server-Timing: auth;dur=55.5, db;dur=220
El valor de un encabezado Server-Timing puede incluir varias métricas, así como una duración para cada una. Luego, estos datos se pueden recopilar de los usuarios en el campo con la API de Navigation Timing y analizar para ver si los usuarios experimentan demoras. En el fragmento de código anterior, el encabezado de respuesta incluye dos tiempos:
- El tiempo para autenticar a un usuario (
auth), que tardó 55.5 milisegundos. - El tiempo de acceso a la base de datos (
db), que tardó 220 milisegundos.
También te recomendamos que revises tu infraestructura de hosting y confirmes que tienes los recursos adecuados para manejar el tráfico que recibe tu sitio web. Los proveedores de alojamiento compartido suelen ser susceptibles a un TTFB alto, y las soluciones dedicadas que proporcionan tiempos de respuesta más rápidos pueden ser más costosas.
Compresión
Las respuestas basadas en texto, como las imágenes HTML, JavaScript, CSS y SVG, deben comprimirse para reducir su tamaño de transferencia a través de la red y que se descarguen más rápido. Los algoritmos de compresión más utilizados son gzip y Brotli. Brotli genera una mejora de entre el 15% y el 20% en comparación con gzip.
La mayoría de los proveedores de hosting web suelen configurar la compresión automáticamente, pero hay algunas cuestiones importantes que debes tener en cuenta si puedes configurar o ajustar la configuración de compresión por tu cuenta:
- Usa Brotli siempre que sea posible. Como se mencionó anteriormente, Brotli proporciona una mejora bastante notable en comparación con gzip, y Brotli es compatible con todos los navegadores principales. Usa Brotli siempre que sea posible, pero si tu sitio web lo usa una gran cantidad de usuarios en navegadores heredados, asegúrate de que gzip se use como alternativa, ya que cualquier compresión es mejor que ninguna.
- El tamaño del archivo es importante. Los recursos muy pequeños (menos de 1 KiB) no se comprimen bien o, a veces, ni siquiera se comprimen. La eficacia de cualquier tipo de compresión de datos depende de tener una gran cantidad de datos con los que un algoritmo de compresión pueda trabajar para encontrar más bits de datos comprimibles. Cuanto más grande sea un archivo, mejor funcionará la compresión. Sin embargo, no envíes recursos muy grandes solo porque se pueden comprimir de manera más eficaz. Los recursos grandes, como JavaScript y CSS, por ejemplo, tardan mucho más en analizarse y evaluarse después de que el navegador los descomprime, y pueden cambiar con mayor frecuencia, incluso si solo cambiaron de forma marginal, ya que cualquier cambio genera un hash de archivo diferente.
- Comprende la diferencia entre la compresión dinámica y la estática. La compresión dinámica y la estática son enfoques diferentes sobre cuándo se debe comprimir un recurso. La compresión dinámica comprime un recurso en el momento en que se solicita y, a veces, cada vez que se solicita. Por otro lado, la compresión estática comprime los archivos con anticipación, por lo que no es necesario realizar ninguna compresión en el momento de la solicitud. La compresión estática elimina la latencia que implica la compresión en sí, lo que puede aumentar los tiempos de respuesta del servidor en el caso de la compresión dinámica. Los recursos estáticos, como las imágenes de JavaScript, CSS y SVG, deben comprimirse de forma estática, mientras que los recursos HTML, especialmente si se generan de forma dinámica para los usuarios autenticados, deben comprimirse de forma dinámica.
Lograr una compresión adecuada por tu cuenta es un desafío, y, a menudo, lo mejor es dejar que una red de distribución de contenido (CDN), que se analiza en la siguiente sección, se encargue de esto por ti. Sin embargo, conocer estos conceptos puede ayudarte a discernir si tu proveedor de hosting está usando la compresión de forma adecuada. Ese conocimiento puede ayudarte a encontrar oportunidades para mejorar la configuración de compresión de modo que produzca el máximo beneficio para tu sitio web.
Redes de distribución de contenidos (CDN)
Una red de distribución de contenido (CDN) es una red distribuida de servidores que almacenan en caché los recursos de tu servidor de origen y, a su vez, los entregan desde servidores perimetrales que están físicamente más cerca de tus usuarios. La proximidad física a tus usuarios reduce el tiempo de ida y vuelta (RTT), mientras que las optimizaciones, como HTTP/2 o HTTP/3, el almacenamiento en caché y la compresión, permiten que la CDN entregue contenido más rápido que si se recuperara de tu servidor de origen. En algunos casos, utilizar una CDN puede mejorar significativamente el TTFB de tu sitio web.
Ponga a prueba sus conocimientos
¿Qué tipo de redireccionamiento está completamente bajo tu control?
El encabezado Server-Timing puede contener varias métricas.
¿Qué tipo de servidor es más probable que esté físicamente más cerca de tus usuarios finales?
Siguiente: Cómo comprender la ruta crítica
Ahora que conoces algunas de las consideraciones de rendimiento relacionadas con el HTML de tu sitio web, estás en una mejor posición para asegurarte de que se cargue lo más rápido posible, pero eso es solo el comienzo del aprendizaje sobre el rendimiento web. A continuación, se explica la teoría detrás de la ruta de renderización crítica. En este módulo, se describen conceptos clave, como los recursos que bloquean la renderización y los que bloquean el análisis, y el papel que desempeñan para lograr que la renderización inicial de una página en el navegador se realice lo más rápido posible.