Redes de distribución de contenidos (CDN)

Mejora el rendimiento mediante el uso de una red de distribución de contenidos.

Katie Hempenius

Las redes de distribución de contenidos (CDN) mejoran el rendimiento del sitio a través de una red distribuida de servidores para entregar recursos a los usuarios. Debido a que las CDN reducen la carga de los servidores, reducen sus costos y son adecuadas para controlar los aumentos repentinos de tráfico. En este artículo, se analiza el funcionamiento de las CDN y se proporciona orientación independiente de la plataforma para elegir, configurar y optimizar una configuración de CDN.

Descripción general

Una red de distribución de contenidos consiste en una red de servidores optimizados para entregar contenido rápidamente a los usuarios. Aunque podría decirse que las CDN son más conocidas por entregar contenido almacenado en caché, también pueden mejorar la publicación de contenido que no se puede almacenar en caché. En términos generales, cuanto más contenido para tu sitio entregue tu CDN, mejor.

En un nivel alto, los beneficios de rendimiento de las CDN surgen de varios principios: los servidores de CDN se ubican más cerca de los usuarios que los servidores de origen y, por lo tanto, tienen una latencia de tiempo de ida y vuelta (RTT) más corta. Las optimizaciones de red permiten que las CDN entreguen contenido más rápido que si el contenido se cargara "directamente" desde el servidor de origen. Por último, las memorias caché de CDN eliminan la necesidad de que una solicitud viaje al servidor de origen.

Término clave: servidor de origen hace referencia al servidor del que una CDN recupera contenido.

Entrega de recursos

Aunque puede parecer no intuitivo, usar una CDN para entregar recursos (incluso los que no pueden almacenarse en caché) suele ser más rápido que hacer que el usuario cargue el recurso “directamente” desde tus servidores.

Cuando se usa una CDN para entregar recursos desde el origen, se establece una nueva conexión entre el cliente y un servidor de CDN cercano. El resto del recorrido (en otras palabras, la transferencia de datos entre el servidor CDN y el origen) ocurre a través de la red de la CDN, que a menudo incluye conexiones existentes y persistentes con el origen. Los beneficios de esto son dobles: finalizar la nueva conexión lo más cerca del usuario posible elimina los costos innecesarios de configuración de conexión (establecer una nueva conexión es costoso y requiere varios recorridos). El uso de una conexión preparada permite que los datos se transfieran de inmediato con la máxima capacidad de procesamiento posible.

Algunas CDN mejoran esta función aún más mediante el enrutamiento del tráfico hacia el origen a través de varios servidores de CDN distribuidos por Internet. Las conexiones entre servidores de CDN se realizan a través de rutas confiables y altamente optimizadas, en lugar de rutas determinadas por el Protocolo de puerta de enlace de frontera (BGP). Aunque BGP es el protocolo de enrutamiento de hecho de Internet, sus decisiones de enrutamiento no siempre están orientadas al rendimiento. Por lo tanto, es probable que las rutas determinadas por BGP sean menos eficaces que las rutas ajustadas con precisión entre servidores de CDN.

Almacenar en caché

El almacenamiento de recursos en caché en los servidores de una CDN elimina la necesidad de que una solicitud se traslade hasta el origen para ser atendida. Como resultado, el recurso se entrega más rápido y también reduce la carga en el servidor de origen.

Agrega recursos a la caché

El método más usado para propagar cachés de CDN es hacer que los recursos de “extracción” de la CDN sean necesarios, lo que se conoce como “extracción del origen”. La primera vez que se solicite un recurso específico de la caché, la CDN lo solicitará al servidor de origen y almacenará en caché la respuesta. De esta manera, el contenido de la caché se acumula con el tiempo a medida que se solicitan recursos adicionales no almacenados en caché.

Quita recursos de la caché

Las CDN usan la expulsión de caché para quitar periódicamente recursos no tan útiles de la caché. Además, los propietarios de sitios pueden usar la opción de borrar definitivamente para quitar recursos de forma explícita.

• Expulsión de caché

  Las cachés tienen una capacidad de almacenamiento limitada. Cuando una caché se acerca a su capacidad, libera espacio para nuevos recursos mediante la eliminación de aquellos a los que no se accedió recientemente o que ocupan mucho espacio. Este proceso se conoce como expulsión de caché. La expulsión de un recurso de una caché no significa necesariamente que se haya expulsado de todas las cachés de una red de CDN.

• Eliminación definitiva

  El proceso de borrado definitivo (también conocido como “invalidación de caché”) es un mecanismo para quitar un recurso de cachés de CDN sin tener que esperar a que venza o se expulse. Por lo general, se ejecuta a través de una API. La eliminación definitiva es fundamental en situaciones en las que es necesario retractar el contenido (por ejemplo, corregir errores tipográficos, de precios o de artículos de noticias incorrectos). Además de eso, también puede desempeñar un papel crucial en la estrategia de almacenamiento en caché de un sitio.

  Si una CDN admite una eliminación casi instantánea, esta se puede usar como mecanismo para administrar el almacenamiento en caché del contenido dinámico: almacena en caché el contenido dinámico mediante un TTL largo y, luego, borra definitivamente el recurso cada vez que se actualice. De esta manera, es posible maximizar la duración del almacenamiento en caché de un recurso dinámico, a pesar de no saber de antemano cuándo cambiará el recurso. A veces, esta técnica se conoce como “almacenamiento en caché por tiempo de espera”.

  Cuando la eliminación definitiva se usa a gran escala, por lo general, se usa en conjunto con un concepto conocido como “etiquetas de caché” o “claves de caché subrogadas”. Este mecanismo permite a los propietarios de sitios asociar uno o más identificadores adicionales (a veces denominados "etiquetas") con un recurso almacenado en caché. Estas etiquetas se pueden usar para realizar una eliminación definitiva altamente detallada. Por ejemplo, puedes agregar una etiqueta "pie de página" a todos los recursos (por ejemplo, /about, /blog) que contengan el pie de página de tu sitio. Cuando se actualice el pie de página, indica a tu CDN que borre definitivamente todos los recursos asociados con esa etiqueta.

Recursos que pueden almacenarse en caché

La manera en que un recurso debe almacenarse en caché depende de si es público o privado, estático o dinámico.

Recursos privados y públicos

• Recursos privados

  Los recursos privados contienen datos destinados a un solo usuario y, por lo tanto, una CDN no debe almacenarlos en caché. Los recursos privados se indican con el encabezado Cache-Control: private.

• Recursos públicos

  Los recursos públicos no contienen información específica del usuario y, por lo tanto, una CDN los puede almacenar en caché. Una CDN puede considerar que un recurso puede almacenarse en caché si no tiene un encabezado Cache-Control: no-store o Cache-Control: private. El tiempo que un recurso público puede almacenarse en caché depende de la frecuencia con la que cambia el recurso.

Contenido dinámico y estático

• Contenido dinámico

  El contenido dinámico es aquel que cambia con frecuencia. Una respuesta de la API y una página principal de la tienda son ejemplos de este tipo de contenido. Sin embargo, el hecho de que este contenido cambie con frecuencia no necesariamente impide que se almacene en caché. Durante períodos de mucho tráfico, almacenar estas respuestas en caché por períodos muy cortos (por ejemplo, 5 segundos) puede reducir de forma significativa la carga en el servidor de origen, a la vez que tiene un impacto mínimo en la actualidad de los datos.

• Contenido estático

  El contenido estático cambia con poca frecuencia o nunca. Las imágenes, los videos y las bibliotecas con control de versiones suelen ser ejemplos de este tipo de contenido. Debido a que el contenido estático no cambia, debe almacenarse en caché con un tiempo de actividad (TTL) prolongado, por ejemplo, 6 meses o 1 año.

Cómo elegir una CDN

Por lo general, el rendimiento es un aspecto fundamental cuando se elige una CDN. Sin embargo, es importante considerar las otras funciones que ofrece una CDN (por ejemplo, las funciones de seguridad y estadísticas), así como el precio, la asistencia y la integración de una CDN.

Rendimiento

En un nivel alto, la estrategia de rendimiento de una CDN puede considerarse en términos de la compensación entre minimizar la latencia y maximizar la proporción de aciertos de caché. Las CDN con muchos puntos de presencia (PoP) pueden ofrecer una latencia más baja, pero pueden experimentar tasas de aciertos de caché más bajas como resultado de que el tráfico se divide en más cachés. Por el contrario, las CDN con menos PoP pueden ubicarse geográficamente más lejos de los usuarios, pero pueden lograr tasas de aciertos de caché más altas.

Como resultado de esta compensación, algunas CDN usan un enfoque en niveles para el almacenamiento en caché: los PoP ubicados cerca de los usuarios (también conocidos como “cachés perimetrales”) se complementan con PoP centrales que tienen tasas de aciertos de caché más altas. Cuando una caché perimetral no puede encontrar un recurso, buscará en un PoP central para el recurso. Este enfoque cambia una latencia ligeramente mayor por una mayor probabilidad de que el recurso pueda entregarse desde una caché de CDN, aunque no necesariamente una caché perimetral.

La compensación entre minimizar la latencia y maximizar la proporción de aciertos de caché es un espectro. Ningún enfoque en particular es mejor a nivel universal; sin embargo, según la naturaleza de tu sitio y su base de usuarios, es posible que uno de estos enfoques ofrezca un rendimiento significativamente mejor que el otro.

También vale la pena señalar que el rendimiento de la CDN puede variar de forma significativa según la ubicación geográfica, la hora del día y hasta los eventos actuales. Si bien siempre es una buena idea investigar por tu cuenta el rendimiento de una CDN, puede ser difícil predecir el rendimiento exacto que obtendrás de ella.

Efectos en el Procesamiento de imagen con contenido más grande (LCP)

Como se describió anteriormente en este artículo, el propósito principal de una CDN es reducir la latencia a través de la distribución de recursos a servidores que están geográficamente más cerca de los usuarios. Por ello, el principal beneficio de una CDN es que mejora el rendimiento de carga. En particular, el tiempo hasta el primer byte (TTFB) de un recurso puede mejorarse significativamente si se introduce una CDN en la arquitectura del servidor de tu sitio web.

Si bien el TTFB no es una métrica de rendimiento centrada en el usuario, es una métrica importante para diagnosticar problemas con Largest Contentful Paint (LCP), que es una métrica centrada en el usuario.

Las CDN son especialmente eficaces para mejorar el LCP, ya que pueden mejorar tanto la entrega de documentos (al reducir el TTFB en la configuración de la conexión y el almacenamiento en caché del documento) y mejorar la entrega de los recursos estáticos necesarios para procesar el elemento de LCP.

Características adicionales

Normalmente, las CDN ofrecen una amplia variedad de funciones además de su oferta principal de CDN. Entre las funciones que se ofrecen comúnmente, se incluyen balanceo de cargas, optimización de imágenes, transmisión de video por Internet, procesamiento perimetral y productos de seguridad.

Cómo configurar una CDN

Lo ideal es que uses una CDN para publicar todo el sitio. En términos generales, el proceso de configuración consiste en registrarte con un proveedor de CDN y, luego, actualizar tu registro DNS CNAME para que apunte al proveedor de CDN. Por ejemplo, el registro CNAME de www.example.com podría apuntar a example.my-cdn.com. Como resultado de este cambio de DNS, el tráfico a tu sitio se enrutará a través de la CDN.

Si no puedes usar una CDN para entregar todos los recursos, puedes configurarla para que entregue solo un subconjunto de recursos, por ejemplo, solo recursos estáticos. Para ello, crea un registro CNAME independiente que solo se use para los recursos que la CDN debe entregar. Por ejemplo, puedes crear un registro CNAME static.example.com que apunte a example.my-cdn.com. También deberás volver a escribir las URLs de los recursos que entrega la CDN para que apunten al subdominio static.example.com que creaste.

Aunque tu CDN estará configurada en este punto, es probable que haya ineficiencias en tu configuración. En las siguientes dos secciones de este artículo, se explicará cómo aumentar la tasa de aciertos de caché y habilitar funciones de rendimiento para aprovechar al máximo tu CDN.

Mejora la tasa de aciertos de caché

Una configuración de CDN eficaz entregará tantos recursos como sea posible de la caché. Por lo general, esto se mide mediante la tasa de aciertos de caché (CHR). La tasa de aciertos de caché se define como la cantidad de aciertos de caché dividida por la cantidad total de solicitudes durante un intervalo de tiempo determinado.

Una caché recién inicializada tendrá un CHR de 0, pero esto aumentará a medida que la caché se propague con recursos. Una CHR del 90% es un buen objetivo para la mayoría de los sitios. Tu proveedor de CDN debería proporcionarte informes y estadísticas sobre tu CHR.

Cuando se optimiza la CHR, lo primero que se debe verificar es que todos los recursos que pueden almacenarse en caché se almacenen en caché durante el período correcto. Se trata de una evaluación sencilla que todos los sitios deben realizar.

En términos generales, el siguiente nivel de optimización de la CHR consiste en ajustar la configuración de la CDN para garantizar que las respuestas del servidor con sus equivalentes lógicas no se almacenen en caché por separado. Esta es una ineficiencia común que se produce debido al impacto de factores como los parámetros de consulta, las cookies y los encabezados de solicitud en el almacenamiento en caché.

Auditoría inicial

La mayoría de las CDN proporcionarán estadísticas de caché. Además, herramientas como WebPageTest y Lighthouse también se pueden usar para verificar rápidamente que todos los recursos estáticos de una página se almacenen en caché durante el tiempo correcto. Esto se logra verificando los encabezados de caché HTTP de cada recurso. Almacenar un recurso en caché con el tiempo de actividad (TTL) máximo adecuado evitará recuperaciones de origen innecesarias en el futuro y, por lo tanto, aumentará la CHR.

Por lo general, se debe configurar uno de estos encabezados como mínimo para que una CDN pueda almacenar en caché un recurso:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Además, aunque esto no afecta si una CDN almacena en caché un recurso ni cómo lo hace, se recomienda establecer también la directiva Cache-Control: immutable.Cache-Control: immutable indica que un recurso "no se actualizará durante su vigencia de actualización". Como resultado, el navegador no vuelve a validar el recurso al entregarlo desde la caché del navegador, lo que elimina una solicitud innecesaria de servidor. Lamentablemente, esta directiva solo es compatible con Firefox y Safari, por lo que no es compatible con los navegadores basados en Chromium. Este problema hace un seguimiento de la compatibilidad de Chromium con Cache-Control: immutable. Destacar este problema puede ayudar a fomentar la compatibilidad con esta función.

Para obtener una explicación más detallada del almacenamiento en caché HTTP, consulta Evita solicitudes de red innecesarias con la caché HTTP.

Ajuste

Una explicación un poco simplificada de cómo funcionan las cachés de CDN es que la URL de un recurso se usa como clave para almacenar en caché y recuperar el recurso de la caché. En la práctica, esto es abrumadoramente cierto, pero se complica un poco debido al impacto de elementos como los encabezados de solicitud y los parámetros de consulta. Como resultado, volver a escribir las URLs de las solicitudes es una técnica importante para maximizar la CHR y garantizar que se muestre el contenido correcto a los usuarios. Una instancia de CDN configurada correctamente logra el equilibrio correcto entre el almacenamiento en caché demasiado detallado (que perjudica la CHR) y el almacenamiento en caché insuficiente (lo que da como resultado que se entreguen respuestas incorrectas a los usuarios).

Parámetros de consulta

Según la configuración predeterminada, las CDN tienen en cuenta los parámetros de consulta cuando almacenan en caché un recurso. Sin embargo, pequeños ajustes en el control de los parámetros de consulta pueden tener un impacto significativo en la CHR. Por ejemplo:

• Parámetros de consulta innecesarios

  De forma predeterminada, una CDN almacena en caché example.com/blog y example.com/blog?referral_id=2zjk por separado, aunque es probable que sean el mismo recurso subyacente. Para solucionar este problema, se ajusta la configuración de una CDN para que ignore el parámetro de consulta referral\_id.

• Orden de los parámetros de consulta

  Una CDN almacenará en caché example.com/blog?id=123&query=dogs por separado de example.com/blog?query=dogs&id=123. Para la mayoría de los sitios, el orden de los parámetros de consulta no es importante, por lo que configurar la CDN para ordenar los parámetros de consulta (normalizar así la URL que se usa para almacenar en caché la respuesta del servidor) aumentará la CHR.

Variar

El encabezado de respuesta Vary informa a las cachés que la respuesta del servidor correspondiente a una URL en particular puede variar según los encabezados establecidos en la solicitud (por ejemplo, los encabezados de solicitud Accept-Language o Accept-Encoding). Como resultado, le indica a una CDN que almacene en caché estas respuestas por separado. El encabezado Vary no es ampliamente compatible con las CDN y puede hacer que un recurso que se puede almacenar en caché no se entregue desde una caché.

Si bien el encabezado Vary puede ser una herramienta útil, el uso inapropiado perjudica la CHR. Además, si usas Vary, la normalización de los encabezados de solicitud ayudará a mejorar la CHR. Por ejemplo, sin la normalización, los encabezados de solicitud Accept-Language: en-US y Accept-Language: en-US,en;q=0.9 generarían dos entradas de caché separadas, aunque es probable que su contenido sea idéntico.

Unas galletas

Las cookies se establecen en las solicitudes a través del encabezado Cookie y se establecen en las respuestas a través del encabezado Set-Cookie. Se debe evitar el uso innecesario del encabezado Set-Cookie, ya que, por lo general, las cachés no almacenan en caché las respuestas del servidor que contienen este encabezado.

Funciones de rendimiento

En esta sección, se analizan las funciones de rendimiento que comúnmente ofrecen las CDN como parte de su oferta de productos principales. Muchos sitios se olvidan de habilitar estas funciones, por lo que se pierden en facilidades de rendimiento.

Compresión

Todas las respuestas basadas en texto deben comprimirse con gzip o Brotli. Si puedes, elige Brotli en lugar de gzip. Brotli es un algoritmo de compresión más reciente y, en comparación con gzip, puede alcanzar proporciones de compresión más altas.

Existen dos tipos de compatibilidad de CDN para la compresión Brotli: "Brotli de origen" y "compresión automática de Brotli".

Brotli desde su origen

Brotli desde el origen se produce cuando una CDN entrega recursos que el origen comprimió mediante Brotli. Aunque puede parecer una función que todas las CDN deberían admitir de forma inmediata, es necesario que una CDN pueda almacenar en caché varias versiones (es decir, versiones comprimidas en gzip y en Brotli) del recurso correspondientes a una URL determinada.

Compresión automática de Brotli

La compresión automática Brotli ocurre cuando los recursos se comprimen mediante Brotli mediante la CDN. Las CDN pueden comprimir tanto los recursos que pueden almacenarse en caché como los que no.

La primera vez que se solicita un recurso, se entrega mediante una compresión que es “suficientemente buena”, por ejemplo, Brotli-5. Este tipo de compresión se aplica tanto a los recursos que pueden almacenarse en caché como a los que no.

Mientras tanto, si un recurso puede almacenarse en caché, la CDN utilizará el procesamiento sin conexión para comprimir el recurso en un nivel de compresión más potente y mucho más lento (por ejemplo, Brotli-11). Cuando se complete esta compresión, la versión más comprimida se almacenará en caché y se usará para solicitudes posteriores.

Prácticas recomendadas de compresión

Los sitios que deseen maximizar el rendimiento deben aplicar la compresión Brotli tanto en el servidor de origen como en la CDN. La compresión de Brotli en el origen minimiza el tamaño de transferencia de los recursos que no se pueden entregar desde la caché. Para evitar demoras en las solicitudes de entrega, el origen debe comprimir los recursos dinámicos mediante un nivel de compresión bastante conservador; por ejemplo, Brotli-4; los recursos estáticos se pueden comprimir con Brotli-11. Si un origen no admite Brotli, se puede usar gzip-6 para comprimir recursos dinámicos, mientras que gzip-9 se puede usar para comprimir recursos estáticos.

TLS 1.3

TLS 1.3 es la versión más reciente de la seguridad de la capa de transporte (TLS), el protocolo criptográfico que usa HTTPS. TLS 1.3 proporciona mejor privacidad y rendimiento en comparación con TLS 1.2.

TLS 1.3 acorta el protocolo de enlace TLS de dos idas y vueltas a uno. Para conexiones que usan HTTP/1 o HTTP/2, acortar el protocolo de enlace TLS a un recorrido completo reduce de manera efectiva el tiempo de configuración de la conexión en un 33%.

HTTP/2 y HTTP/3

Tanto HTTP/2 como HTTP/3 ofrecen beneficios de rendimiento en comparación con HTTP/1. De los dos, HTTP/3 ofrece mayores beneficios potenciales de rendimiento. HTTP/3 aún no está completamente estandarizado, pero será ampliamente compatible cuando esto ocurra.

HTTP/2

Si tu CDN aún no habilita HTTP/2 de forma predeterminada, considera activarlo. HTTP/2 proporciona múltiples beneficios de rendimiento en comparación con HTTP/1 y es compatible con todos los navegadores principales. Las funciones de rendimiento de HTTP/2 incluyen la multiplexación, la priorización de transmisión y la compresión de encabezados.

• Multiplexación

  La multiplexación puede ser la característica más importante de HTTP/2. La multiplexación permite que una sola conexión TCP entregue varios pares de solicitud-respuesta al mismo tiempo. Esto elimina la sobrecarga de configuraciones de conexión innecesarias; dado que la cantidad de conexiones que un navegador puede tener abierta en un momento determinado es limitada, también implica que el navegador ahora puede solicitar más recursos de una página en paralelo. En teoría, la multiplexación elimina la necesidad de optimizaciones HTTP/1 como la concatenación y las hojas de objeto. Sin embargo, en la práctica, estas técnicas seguirán siendo relevantes dado que los archivos más grandes se comprimen mejor.

• Priorización de transmisión

  La multiplexación permite varias transmisiones simultáneas. La priorización de transmisión proporciona una interfaz para comunicar la prioridad relativa de cada una de estas transmisiones. Esto ayuda al servidor a enviar los recursos más importantes primero, incluso si no se solicitaron primero.

El navegador expresa la priorización de la transmisión a través de un árbol de dependencias y solo es una declaración de preferencia: en otras palabras, el servidor no está obligado a cumplir (ni considerar) las prioridades proporcionadas por el navegador. La priorización de la transmisión es más eficaz cuando se entrega más contenido de un sitio a través de una CDN.

Las implementaciones de CDN de priorización de recursos HTTP/2 varían ampliamente. Para identificar si tu CDN admite de forma completa y correcta la priorización de recursos HTTP/2, consulta el artículo ¿HTTP/2 aún es rápido?.

Si bien cambiar tu instancia de CDN a HTTP/2 es básicamente una cuestión de activar un interruptor, es importante probar minuciosamente este cambio antes de habilitarlo en producción. HTTP/1 y HTTP/2 usan las mismas convenciones para los encabezados de solicitud y respuesta, pero HTTP/2 es mucho menos tolerante cuando no se cumplen estas convenciones. Como resultado, las prácticas que no pertenecen a las especificaciones, como incluir caracteres que no son ASCII o en mayúscula en los encabezados, pueden comenzar a causar errores una vez que se habilite HTTP/2. Si esto ocurre, los intentos de un navegador para descargar el recurso fallarán. El intento de descarga fallido se podrá ver en la pestaña "Red" de Herramientas para desarrolladores. Además, se mostrará el mensaje de error "ERR_HTTP2_PROTOCOL_ERROR" en la consola.

HTTP/3

HTTP/3 es el sucesor de HTTP/2. A partir de septiembre de 2020, todos los navegadores principales tienen compatibilidad experimental con HTTP/3, y algunas CDN la admiten. El rendimiento es el beneficio principal de HTTP/3 en lugar de HTTP/2. Específicamente, HTTP/3 elimina el bloqueo de línea a nivel de conexión y reduce el tiempo de configuración de la conexión.

• Eliminación del bloqueo de cabeza de línea

  HTTP/2 introdujo multiplexación, una función que permite usar una única conexión para transmitir múltiples flujos de datos simultáneamente. Sin embargo, con HTTP/2, un solo paquete descartado bloquea todas las transmisiones en una conexión (un fenómeno conocido como bloqueo de encabezado de línea). Con HTTP/3, un paquete descartado solo bloquea una sola transmisión. Esta mejora es en gran parte el resultado de que HTTP/3 usa UDP (HTTP/3 usa UDP a través de QUIC) en lugar de TCP. Esto hace que HTTP/3 sea especialmente útil para la transferencia de datos en redes congestionadas o con pérdida.

• Reducción del tiempo de configuración de la conexión

  HTTP/3 usa TLS 1.3 y, por lo tanto, comparte sus beneficios de rendimiento: establecer una conexión nueva solo requiere un recorrido de ida y vuelta, y reanudar una conexión existente no requiere ida y vuelta.

HTTP/3 tendrá el mayor impacto en los usuarios con conexiones de red deficientes: no solo porque HTTP/3 maneja la pérdida de paquetes mejor que sus predecesores, sino también porque el ahorro de tiempo absoluto que resulta de una configuración de conexión 0-RTT o 1-RTT será mayor en redes con latencia alta.

Optimización de la imagen

Por lo general, los servicios de optimización de imágenes de CDN se enfocan en optimizaciones de imágenes que pueden aplicarse automáticamente para reducir el tamaño de transferencia de imágenes. Por ejemplo, quitar datos EXIF, aplicar compresión sin pérdidas y convertir imágenes a formatos de archivo más nuevos (por ejemplo, WebP). Las imágenes representan aproximadamente el 50% de los bytes de transferencia en la mediana de la página web, por lo que optimizar las imágenes puede reducir de manera significativa el tamaño de la página.

Reducción

La reducción quita los caracteres innecesarios de JavaScript, CSS y HTML. Se prefiere realizar la reducción en el servidor de origen, en lugar de en la CDN. Los propietarios de los sitios tienen más contexto sobre el código que se reducirá y, por lo tanto, pueden usar técnicas de reducción más agresivas que las que emplean las CDN. Sin embargo, si reducir el código en el origen no es una opción, la reducción a través de la CDN es una buena alternativa.

Conclusión

• Usa una CDN: Las CDN entregan recursos con rapidez, reducen la carga en el servidor de origen y son útiles para lidiar con los aumentos repentinos de tráfico.
• Almacena el contenido en caché de la manera más agresiva posible: Tanto el contenido estático como el dinámico pueden y deben almacenarse en caché, aunque para distintas duraciones. Audita tu sitio de forma periódica para asegurarte de que el contenido se almacene de forma óptima.
• Habilita las funciones de rendimiento de CDN: Funciones como Brotli, TLS 1.3, HTTP/2 y HTTP/3 mejoran aún más el rendimiento.