Mejora el rendimiento usando una red de distribución de contenidos.
Las redes de distribución de contenidos (CDN) mejoran el rendimiento del sitio utilizando una red distribuida de servidores para distribuir recursos a los usuarios. Debido a que las CDN reducen la carga del servidor, reducen los costos de este y son adecuadas para controlar los aumentos repentinos de tráfico. En este artículo, se explica cómo funcionan 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 a los usuarios con rapidez. Aunque podría decirse que las CDN son más conocidas por entregar contenido almacenado en caché, las CDN también pueden mejorar la entrega de contenido que no se puede almacenar en caché. En términos generales, cuanto más contenido del sitio publique la CDN, mejor.
En un nivel superior, los beneficios de rendimiento de las CDN surgen de varios principios: los servidores de CDN se encuentran 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 cargue "directamente" desde el servidor de origen. Por último, las cachés de CDN eliminan la necesidad de que una solicitud de CDN vaya al servidor de origen.
Entrega de recursos
Aunque pueda parecer poco intuitivo, usar una CDN para entregar recursos (incluso los que no se pueden almacenar 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 de CDN y el origen) se produce a través de la red de la CDN, que a menudo incluye conexiones existentes y persistentes con el origen. Los beneficios son dobles: finalizar la nueva conexión lo más cerca posible del usuario elimina los costos innecesarios de configuración de la conexión (establecer una nueva conexión es costoso y requiere múltiples recorridos); el uso de una conexión previamente preparada permite que los datos se transfieran de inmediato a la máxima capacidad de procesamiento posible.
Algunas CDN mejoran esto aún más, ya que enrutan el tráfico al origen a través de varios servidores de CDN distribuidos en Internet. Las conexiones entre los servidores de CDN se producen a través de rutas confiables y altamente optimizadas, en lugar de rutas determinadas por el Protocolo de Puerta de Enlace Fronteriza (BGP). Aunque BGP es el protocolo de enrutamiento de facto de Internet, sus decisiones de enrutamiento no siempre están orientadas al rendimiento. Por lo tanto, es probable que las rutas determinadas por BGP tengan menos rendimiento que las rutas ajustadas entre servidores de CDN.
Almacenamiento en caché
El almacenamiento en caché de recursos en los servidores de una CDN elimina la necesidad de que las solicitudes se trasladen al origen para poder entregarse. Como resultado, el recurso se entrega más rápido; esto también reduce la carga en el servidor de origen.
Agrega recursos a la caché
El método más usado para propagar las cachés de CDN es hacer que los recursos de “extracción” de la CDN sean necesarios, lo que se conoce como “extracción de origen”. La primera vez que se solicite un recurso específico de la caché, la CDN lo solicitará al servidor de origen y almacenará la respuesta en caché. 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 de ella recursos poco útiles. Además, los propietarios de los sitios pueden utilizar la eliminación definitiva 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, deja lugar para nuevos recursos mediante la eliminación de recursos 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 memorias caché de una red de CDN.
Purgación
La eliminación definitiva (también conocido como “invalidación de caché”) es un mecanismo para quitar un recurso de las cachés de una CDN sin tener que esperar a que venza o se expulse. Por lo general, se ejecutan a través de una API. Borrar definitivamente es fundamental en situaciones en las que se debe retractar el contenido (por ejemplo, para corregir errores tipográficos, errores de precios o 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 la depuración casi instantánea, la eliminación definitiva se puede usar como un mecanismo para administrar el almacenamiento en caché del contenido dinámico: almacena en caché el contenido dinámico con un TTL largo y, luego, borra definitivamente el recurso cada vez que se actualiza. De esta manera, es posible maximizar la duración del almacenamiento en caché de un recurso dinámico, a pesar de no saber con antelación cuándo cambiará el recurso. A veces, esta técnica se conoce como “almacenamiento en caché de espera”.
Cuando la depuración 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 que los propietarios de los sitios asocien uno o más identificadores adicionales (a veces denominados "etiquetas") con un recurso almacenado en caché. Estas etiquetas se pueden usar para realizar eliminaciones definitivas muy detalladas. Por ejemplo, puedes agregar una etiqueta de “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 la etiqueta "footer".
Recursos que se pueden almacenar en caché
Si un recurso debe almacenarse en caché y cómo hacerlo 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 puede almacenarlos en caché. Una CDN puede considerar que un recurso puede almacenarse en caché si no tiene un encabezado
Cache-Control: no-storeoCache-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 la página principal de una 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é durante períodos muy cortos (por ejemplo, 5 segundos) puede reducir significativamente la carga en el servidor de origen y, al mismo tiempo, tener un impacto mínimo en la actualización 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 versiones suelen ser ejemplos de este tipo de contenido. Dado que el contenido estático no cambia, se debe almacenar en caché con un tiempo de actividad (TTL) prolongado, por ejemplo, 6 meses o 1 año.
Cómo elegir una CDN
El rendimiento suele ser una consideración importante a la hora de elegir una CDN. Sin embargo, es importante considerar las demás características 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
A un alto nivel, la estrategia de rendimiento de una CDN puede considerarse en términos de la compensación entre minimizar la latencia y maximizar la tasa 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 debido a que el tráfico se divide entre más cachés. Por el contrario, las CDN con menos PoP se pueden ubicar 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 por 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, lo buscará en un PoP central. Con este enfoque, se cambia una latencia ligeramente mayor por una mayor probabilidad de que el recurso se pueda entregar desde una caché de CDN, aunque no necesariamente una caché perimetral.
La compensación entre minimizar la latencia y maximizar la tasa de aciertos de caché es un espectro. Ningún enfoque en particular es universalmente mejor; 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 significativamente 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ó antes en este artículo, el propósito principal de una CDN es reducir la latencia mediante la distribución de recursos a los servidores que están geográficamente más cerca de los usuarios. Por esta razón, 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 cuando se agrega una CDN a 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 el Procesamiento de imagen con contenido más grande (LCP), que es una métrica centrada en el usuario.
Las CDN son especialmente eficaces para mejorar el LCP, ya que pueden optimizar la entrega de documentos (si se reduce el TTFB en la configuración de la conexión y el almacenamiento en caché del documento) y la entrega de los recursos estáticos necesarios para renderizar el elemento LCP.
Características adicionales
Por lo general, las CDN ofrecen una amplia variedad de funciones además de su oferta principal de CDN. Entre las funciones que se suelen ofrecer, se incluyen el balanceo de cargas, la optimización de imágenes, la transmisión de video por Internet, el procesamiento perimetral y los productos de seguridad.
Cómo configurar una CDN
Lo ideal es que uses una CDN para entregar todo tu sitio. En términos generales, el proceso de configuración para esto consiste en registrarse con un proveedor de CDN y, luego, actualizar el 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 el uso de una CDN para entregar todos los recursos no es una opción, puedes configurarla para que solo entregue un subconjunto de recursos; por ejemplo, solo recursos estáticos. Para ello, puedes crear un registro CNAME independiente que solo se use para los recursos que deba entregar la CDN. Por ejemplo, puedes crear un registro CNAME static.example.com que apunte a example.my-cdn.com. También deberás reescribir 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 la configuración. En las siguientes dos secciones de este artículo, se explicará cómo aprovechar al máximo tu CDN mediante el aumento de la tasa de aciertos de caché y la habilitación de las funciones de rendimiento.
Mejora la tasa de aciertos de caché
Una configuración eficaz de la CDN servirá tantos recursos como sea posible desde la caché. Por lo general, esto se mide por 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 de solicitudes totales 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. Un CHR del 90% es un buen objetivo para la mayoría de los sitios. Tu proveedor de CDN debería proporcionarte informes y análisis relacionados con tus CHR.
Cuando optimices CHR, lo primero que debes verificar es que todos los recursos que se pueden almacenar en caché se almacenen en caché durante el tiempo correcto. Se trata de una evaluación sencilla que deben realizar todos los centros.
En términos generales, el siguiente nivel de optimización de CHR consiste en ajustar la configuración de la CDN para asegurarte de que las respuestas del servidor equivalentes de forma lógica 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 proporcionan análisis 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 la 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á CHR.
Como mínimo, se debe configurar normalmente uno de estos encabezados para que una CDN almacene en caché un recurso:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
Además, aunque no afecta si una CDN almacena en caché un recurso ni afecta la manera en que lo hace, se recomienda configurar también la directiva Cache-Control: immutable.Cache-Control: immutable indica que un recurso “no se actualizará durante su vida útil”. Como resultado, el navegador no volverá a validar el recurso cuando lo entregue desde la caché del navegador, lo que eliminará una solicitud innecesaria del servidor. Lamentablemente, esta directiva solo es compatible con Firefox y Safari, y los navegadores con Chromium no la admiten. Este problema realiza un seguimiento de la compatibilidad de Chromium con Cache-Control: immutable. Destacar este problema puede ayudar a fomentar el apoyo para esta función.
Para obtener una explicación más detallada sobre el 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 la clave para almacenar en caché y recuperarlo. En la práctica, esto sigue siendo abrumador, pero se complica un poco por el impacto de elementos como los encabezados de solicitud y los parámetros de consulta. Como resultado, reescribir las URLs de las solicitudes es una técnica importante para maximizar las CHR y garantizar que se proporcione el contenido correcto a los usuarios. Una instancia de CDN configurada correctamente logra el equilibrio adecuado entre el almacenamiento en caché demasiado detallado (que perjudica a CHR) y el almacenamiento en caché lo suficientemente detallado (lo que da como resultado la entrega de respuestas incorrectas a los usuarios).
Parámetros de consulta
De forma predeterminada, las CDN tienen en cuenta los parámetros de consulta cuando almacenan en caché un recurso. Sin embargo, los ajustes pequeños en el manejo de parámetros de consulta pueden tener un impacto significativo en las CHR. Por ejemplo:
Parámetros de consulta innecesarios
De forma predeterminada, una CDN almacenará en caché
example.com/blogyexample.com/blog?referral_id=2zjkpor separado, aunque probablemente sean el mismo recurso subyacente. Para solucionar este problema, ajusta la configuración de una CDN de modo que ignore el parámetro de consultareferral\_id.Orden del parámetro de consulta
Una CDN almacenará en caché
example.com/blog?id=123&query=dogsde forma independiente deexample.com/blog?query=dogs&id=123. En la mayoría de los sitios, el orden del parámetro de consulta no importa, por lo que configurar la CDN para ordenar los parámetros de consulta (lo que normaliza 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 memorias caché que la respuesta del servidor que corresponde 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 estas respuestas en caché por separado. El encabezado Vary no es ampliamente compatible con las CDN y es posible que la caché no entregue un recurso que, de otro modo, se puede almacenar en caché.
Si bien el encabezado Vary puede ser una herramienta útil, el uso inadecuado perjudica las CHR. Además, si usas Vary, normalizar los encabezados de solicitud ayudará a mejorar CHR. Por ejemplo, sin 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 configuran en las solicitudes a través del encabezado Cookie; 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 suelen ofrecer las CDN como parte de su oferta principal de productos. Muchos sitios se olvidan de habilitar estas funciones y, por lo tanto, pierden frente a mejoras sencillas en el rendimiento.
Compresión
Todas las respuestas basadas en texto se deben comprimir con gzip o Brotli. Si tienes la opción, elige Brotli en lugar de gzip. Brotli es un algoritmo de compresión más nuevo y, en comparación con gzip, puede lograr índices de compresión más altos.
Existen dos tipos de compatibilidad de CDN para la compresión Brotli: "Brotli from origin" y "Compresión Brotli automática".
Brotli de origen
Brotli desde el origen es cuando una CDN entrega recursos que el origen comprimió Brotli. Aunque esta pueda parecer una función que todas las CDN deberían ser compatibles de inmediato, requiere que una CDN pueda almacenar en caché varias versiones (es decir, versiones comprimidas en gzip y Brotli) del recurso correspondiente a una URL determinada.
Compresión automática de Brotli
La compresión automática de Brotli ocurre cuando la CDN comprime los recursos de Brotli. Las CDN pueden comprimir recursos que se pueden almacenar en caché y que no.
La primera vez que se solicita un recurso, se entrega a través de una compresión “suficientemente buena”, por ejemplo, Brotli-5. Este tipo de compresión se aplica a los recursos que pueden almacenarse en caché y a los que no.
Mientras tanto, si un recurso puede almacenarse en caché, la CDN usará el procesamiento sin conexión para comprimir el recurso con un nivel de compresión más potente, pero mucho más lento, por ejemplo, Brotli-11. Una vez que 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 desean maximizar el rendimiento deben aplicar la compresión Brotli en el servidor de origen y en la CDN. La compresión 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 la entrega de solicitudes, el origen debe comprimir los recursos dinámicos con 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 y gzip-9 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 ofrece mejor privacidad y rendimiento en comparación con TLS 1.2.
TLS 1.3 acorta el protocolo de enlace TLS de dos ida y vuelta a uno. Para las conexiones que usan HTTP/1 o HTTP/2, acortar el protocolo de enlace TLS a un recorrido completo reduce el tiempo de configuración de la conexión en un 33%.
HTTP/2 y HTTP/3
HTTP/2 y HTTP/3 ofrecen ventajas de rendimiento en comparación con HTTP/1. De ambos, HTTP/3 ofrece mayores beneficios posibles de rendimiento. HTTP/3 aún no está completamente estandarizado, pero será muy compatible cuando esto ocurra.
HTTP/2
Si tu CDN aún no tiene habilitado HTTP/2 de forma predeterminada, te recomendamos que lo actives. HTTP/2 ofrece varios 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 multiplexación, priorización de la transmisión y compresión de encabezados.
Multiplexación
La multiplexación es posiblemente la característica más importante de HTTP/2. La multiplexación permite que una sola conexión TCP entregue múltiples 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, esto 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 de 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 transmisiones
La multiplexación permite múltiples transmisiones simultáneas; la priorización de transmisiones 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 transmisión a través de un árbol de dependencias y es simplemente una declaración de preferencia: Es decir, el servidor no está obligado a cumplir (ni tener en cuenta) las prioridades que proporciona el navegador. La priorización de transmisión se vuelve 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 la priorización de recursos HTTP/2 de forma completa y correcta, consulta ¿Es HTTP/2 Fast Yet?.
Aunque cambiar la instancia de CDN a HTTP/2 implica, en gran medida, activar un interruptor, es importante probar exhaustivamente 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 flexible cuando no se respetan estas convenciones. Como resultado, las prácticas que no cumplen con las especificaciones, como incluir caracteres que no son ASCII o mayúsculas en los encabezados, pueden comenzar a generar errores una vez que se habilite HTTP/2. Si esto ocurre, fallarán los intentos de descarga del recurso de un navegador. El intento de descarga fallido aparecerá 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 más importantes tienen compatibilidad experimental con HTTP/3, y algunas CDN lo admiten. El rendimiento es el beneficio principal de HTTP/3 en comparación con HTTP/2. Específicamente, HTTP/3 elimina el bloqueo de encabezado 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 utilizar una sola conexión para transmitir múltiples transmisiones de datos simultáneamente. Sin embargo, con HTTP/2, un solo paquete descartado bloquea todas las transmisiones de una conexión (un fenómeno conocido como bloqueo de cabeza de línea). Con HTTP/3, un paquete descartado solo bloquea una transmisión. Esta mejora es, en gran parte, el resultado de HTTP/3 mediante UDP (HTTP/3 usa UDP a través de QUIC) en lugar de TCP. Esto hace que HTTP/3 sea particularmente útil para la transferencia de datos en redes con pérdidas o congestionadas.
Menor 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 nueva conexión solo requiere un solo recorrido de ida y vuelta, y reanudar una conexión existente no requiere ningún recorrido de ida y vuelta.
HTTP/3 tendrá el mayor impacto sobre 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 resultante 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 imagen que se pueden aplicar automáticamente para reducir el tamaño de transferencia de la imagen. 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 página web mediana, por lo que optimizarlas puede reducir significativamente el tamaño de la página.
Reducción
La reducción quita los caracteres innecesarios de JavaScript, CSS y HTML. Es preferible reducir el valor en el servidor de origen, en lugar de la CDN. Los propietarios de los sitios tienen más contexto sobre el código que se debe reducir y, por lo tanto, a menudo pueden usar técnicas de reducción más agresivas que las que emplean las CDN. Sin embargo, si no es posible reducir el código en el origen, la reducción por parte de la CDN sí lo es.
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 con diferentes duraciones. Audita tu sitio de forma periódica para asegurarte de almacenar en caché el contenido de forma óptima.
- Habilita funciones de rendimiento de CDN: Las funciones como Brotli, TLS 1.3, HTTP/2 y HTTP/3 mejoran aún más el rendimiento.