El primer paso para crear un sitio web que se cargue rápidamente es recibir una respuesta oportuna del servidor para el código 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. Un objetivo clave de rendimiento es garantizar que llegue rápido con un retraso mínimo.
Esa solicitud inicial de HTML pasa por varios pasos, cada uno de los cuales lleva 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í hace que sea difícil alcanzar los umbrales designados de “buena” para métricas como Largest Contentful Paint (LCP) y 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 porque requieren que el navegador realice una solicitud HTTP adicional en la ubicación nueva 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 completamente en tu servidor web.
- Redireccionamientos de origen cruzado que inicia 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 URL y otros servicios de terceros. Si bien los redireccionamientos de origen cruzado están fuera de tu control, te recomendamos verificar que evites varios redireccionamientos; por ejemplo, tener un anuncio que vincule a una página HTTP que, a su vez, redireccione a su equivalente a HTTPS o un redireccionamiento de origen cruzado que llegue a tu origen, pero que luego active un redireccionamiento del mismo origen.
Almacenar respuestas HTML en caché
Almacenar en caché las respuestas HTML es difícil, 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 el documento HTML almacenado en caché puede quedar inactivo después de una implementación, ya que contendrá referencias a subrecursos desactualizados.
No obstante, una vida útil de caché corta (en lugar de no tenerlo) 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, lo que permite volver a validar los recursos en lugar de volver a descargarse. Este enfoque funciona mejor para el contenido estático que no cambia en ningún contexto, y un momento apropiado para almacenar en caché los recursos se puede establecer en un número de minutos que consideres apropiado. Cinco minutos para 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 debido a diferentes problemas, como 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 almacenar HTML en caché por completo.
Un enfoque cauteloso para almacenar HTML en caché 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 manera única el recurso solicitado, a menudo mediante un hash del contenido del recurso:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cada vez que el recurso cambia, se debe generar un valor ETag nuevo. En las solicitudes posteriores, el navegador envía el valor ETag a través del encabezado de solicitud If-None-Match. Si el ETag del servidor coincide con el enviado por 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 involucrada en la revalidación de la actualidad de un recurso sigue siendo su propia clase de inconveniente. Como sucede con muchos otros aspectos del desarrollo web, las compensaciones y los compromisos son inevitables. Depende de ti averiguar si vale la pena realizar el esfuerzo adicional para almacenar HTML en caché de esta manera, o si es mejor mantener la seguridad y no molestar en absoluto almacenar el contenido HTML en caché.
Mide los tiempos de respuesta del servidor
Si una respuesta no se almacena en caché, 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 entrega una respuesta generada de forma dinámica, como la recuperación de datos de una base de datos, por ejemplo, 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. Si se muestra un ícono giratorio de carga y luego se recuperan todos los datos del cliente, se traslada el esfuerzo de un entorno del servidor más predecible a uno potencialmente impredecible del lado del cliente. Por lo general, minimizar el esfuerzo del cliente da como resultado métricas mejoradas centradas en el usuario.
Si los usuarios experimentan un TTFB lento en el campo, puedes exponer información sobre dónde se pasó el tiempo en el servidor mediante el 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, se pueden recopilar estos datos de los usuarios en el campo que usa la API de Navigation Timing y analizarlos para comprobar si los usuarios están experimentando retrasos. En el fragmento de código anterior, el encabezado de respuesta incluye dos tiempos:
- El tiempo para autenticar 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 revisar la infraestructura de hosting y confirmar que tienes los recursos adecuados para manejar el tráfico que recibe tu sitio web. Los proveedores de hosting compartido suelen tener 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, se deben comprimir para reducir el tamaño de transferencia a través de la red y poder descargarse más rápido. Los algoritmos de compresión más usados son gzip y Brotli. Los resultados de Brotli mejoran entre un 15% y un 20% en comparación con gzip.
La mayoría de los proveedores de hosting web suelen configurar automáticamente la compresión, pero hay algunos aspectos importantes que debes tener en cuenta si estás en posición de ajustar o modificar la configuración de compresión por tu cuenta:
- Usa Brotli siempre que sea posible. Como se indicó anteriormente, Brotli ofrece una mejora bastante notable en comparación con gzip, y Brotli es compatible con todos los navegadores principales. Usa Brotli cuando sea posible, pero si una gran cantidad de usuarios usan tu sitio web en navegadores heredados, asegúrate de usar gzip como resguardo, ya que cualquier compresión es mejor que no realizar ninguna compresión.
- El tamaño del archivo es importante. Los recursos muy pequeños (menos de 1 KiB) no se comprimen muy bien o, a veces, ni siquiera se comprimen. La eficacia de cualquier tipo de compresión de datos depende de que haya una gran cantidad de datos con los que un algoritmo de compresión pueda trabajar para encontrar más bits de datos que se puedan comprimir. Cuanto más grande es un archivo, mejor funciona la compresión. Sin embargo, no envíes recursos muy grandes solo por el hecho de que se pueden comprimir de manera más eficaz. Los recursos grandes, como JavaScript y CSS, tardan mucho más en analizarse y evaluarse después de que el navegador los descomprime. Además, pueden cambiar con más frecuencia, incluso si solo cambiaron de forma marginal, ya que cualquier cambio genera un hash de archivo diferente.
- Comprende la compresión dinámica frente a la estática. La compresión dinámica y estática son enfoques diferentes en cuanto a cuándo se debe comprimir un recurso. La compresión dinámica comprime un recurso en el momento de la solicitud y, a veces, cada vez que se solicita. Por otro lado, la compresión estática comprime los archivos antes del tiempo, lo que no requiere que se realice ninguna compresión en el momento de la solicitud. La compresión estática quita la latencia involucrada en la compresión, 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, se deben comprimir de forma estática, mientras que los recursos HTML, especialmente si se generan de forma dinámica para usuarios autenticados, se deben comprimir de forma dinámica.
Realizar la compresión por tu cuenta es un desafío y, a menudo, es mejor dejar que una red de distribución de contenidos (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 utiliza la compresión de forma correcta. Ese conocimiento te ayudará a encontrar oportunidades para mejorar tu configuración de compresión y obtener el máximo beneficio para tu sitio web.
Redes de distribución de contenidos (CDN)
Una red de distribución de contenidos (CDN) es una red distribuida de servidores que almacenan recursos en caché del 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 los 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 recuperaría desde el servidor de origen. En algunos casos, el uso de una CDN puede mejorar significativamente el TTFB de tu sitio web.
Pon a prueba tus 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?
A continuación: Comprende la ruta crítica
Ahora que conoces algunas de las consideraciones de rendimiento relacionadas con el código HTML de tu sitio web, estás en una mejor posición para asegurarte de que se pueda cargar lo más rápido posible, pero ese es solo el comienzo del aprendizaje del rendimiento web. A continuación, se aborda la teoría detrás de la ruta de acceso de renderización crítica. En este módulo, se describen conceptos clave, como los recursos de bloqueo de renderización y de análisis, y la función que desempeñan para obtener la renderización inicial de una página en el navegador lo más rápido posible.