Aumento de la descarga en el origen

El aumento de la proporción de aciertos de caché (CHR) con CloudFront mejora el rendimiento de una aplicación web y reduce la carga en su origen. CHR es la proporción entre las solicitudes HTTP que se atienden desde la memoria caché de CloudFront y el número total de solicitudes. Las solicitudes atendidas desde la memoria caché de CloudFront se benefician de una mejor latencia (por ejemplo, el tiempo transcurrido hasta el último byte), lo que convierte a la CHR en un buen indicador de la descarga en el origen y del rendimiento de la aplicación. La CHR de una distribución de CloudFront se puede supervisar mediante la métrica tasa de aciertos de caché de CloudWatch. Para aumentar la CHR, puede optimizar la configuración de almacenamiento en caché en CloudFront, habilitar Origin Shield y optimizar el comportamiento de sus aplicaciones.

Puede controlar durante cuánto tiempo se almacena en caché un objeto en CloudFront mediante el encabezado Cache-Control enviado por su origen, limitado por la configuración de tiempo de vida en las políticas de caché. El aumento de los TTL tiene un impacto positivo en la CHR y, por lo tanto, se recomienda:

• Configure los encabezados de Cache-Control en el origen para controlar mejor el TTL en CloudFront y aprovechar el almacenamiento en caché del navegador.
• Almacene en caché los activos estáticos como objetos inmutables (por ejemplo, Cache-Control: max-age=31536000, immutable) y modifique su ruta URL (por ejemplo, /static/app.1be87a.js).
• Implemente etiquetas de identidad (ETAG) en sus objetos para beneficiarse de las solicitudes HTTP condicionales a su origen.
• Encuentre el equilibrio adecuado para obtener contenido más dinámico, como HTML, entre el almacenamiento en caché (TTL alto) y el grado de tolerancia de la aplicación con el contenido obsoleto (TTL bajo).

La configuración de las claves de caché mediante las políticas de caché determina si CloudFront reutiliza o no un objeto en caché para una solicitud HTTP. Una configuración de claves de caché optimizada da como resultado una relación de 1 a 1 entre claves de caché únicas y objetos únicos. Piense en una aplicación web que publique el mismo /about.html, independientemente de los parámetros de consulta adjuntos (por ejemplo, /about.html?utm_medium=social). Si la clave de caché está configurada para incluir el parámetro de consulta utm_medium, CloudFront almacenará en caché diferentes URL (por ejemplo, /about.html?utm_medium=social y /about.html?utm_medium=email) con dos claves de caché distintas. Esto da como resultado dos errores de caché en el origen, aunque ambas solicitudes sean iguales para el mismo archivo en el origen, lo que no es óptimo.

La primera práctica recomendada para optimizar la configuración de la clave de caché es incluir exclusivamente en la solicitud de clave de caché los atributos cuyas respuestas en el origen varían. Para lograrlo, se recomienda:

• Configure comportamientos de caché independientes para los objetos que requieren configuraciones de clave de caché diferentes.
• Si los parámetros de consulta, los encabezados o las cookies tienen respuestas en el origen que varían, incluya solo las elementos que realmente lo hagan (por ejemplo, user_id de la cookie en lugar de todas las cookies).
• Use políticas de encabezados de respuesta en CloudFront para administrar CORS, en lugar de agregar encabezados CORS (por ejemplo, Origin, Access-Control-Request-Method, Access-Control-Request-Headers) a la clave de caché y administrar CORS en el origen.
• Transfiera el control de acceso a CloudFront mediante URL firmadas, CloudFront Functions o Lambda@Edge, en lugar de agregar el encabezado de autorización a la clave de caché y administrarlo en el origen.
• Use la política de solicitudes de origen en CloudFront para reenviar los atributos HTTP al origen en lugar de agregarlos a la clave de caché.
  
  

La segunda práctica recomendada es normalizar un atributo de solicitud antes de agregarlo a la clave de caché para reducir la cardinalidad de sus valores posibles, cada uno de los cuales resulta en una clave de caché única. Para lograrlo, se recomienda:

• Enviar los parámetros de consulta, cuando se utilizan, en el mismo orden y con el mismo tipo de letra
• Utilice los encabezados generados por CloudFront, como CloudFront-Is-Mobile-Viewer, para identificar un tipo de dispositivo en lugar de agregar el encabezado User-agent a la clave de caché.
• Usar CloudFront Functions para aplicar normalizaciones avanzadas, como reordenar y convertir a minúsculas los parámetros de consulta; ofrecer una versión diferente de una página web en función de la existencia de una cookie en lugar de agregar la cookie a la clave de caché; reducir la variabilidad de las respuestas que varían en función del país cuando se puede enviar la misma respuesta a un grupo de países; reducir aún más la cardinalidad de Accept-Encoding cuando se necesita compresión, o la cardinalidad de los encabezados de detección de dispositivos de CloudFront cuando se usan varios.

De forma predeterminada, CloudFront reduce la cantidad de errores de caché en el origen mediante el uso de dos capas de almacenamiento en caché de alto nivel: una capa en el nivel de PoP y otra capa en el nivel de caché periférica regional (REC). Un PoP de CloudFront se asocia nominalmente a una de las más de 10 REC de todo el mundo. Cuando una solicitud provoca un error de caché de PoP, CloudFront comprueba la caché de la REC asociada para cumplir con la solicitud y, solo si no está almacenado en caché en esa REC, CloudFront reenvía la solicitud al origen. Las REC están aisladas unas de otras para mantener una alta disponibilidad y, en consecuencia, no comparten sus cachés. Como resultado, cuando se solicitan objetos populares desde diferentes ubicaciones del mundo, CloudFront envía varias solicitudes de los mismos objetos al origen desde varias REC.

Para reducir el número de solicitudes reenviadas al origen, puede habilitar Origin Shield en CloudFront, que es una tercera capa de almacenamiento en caché de alto nivel entre las REC y su origen. En lugar de solicitar objetos directamente desde el origen, las REC primero intentan cumplir con las solicitudes de la caché de Origin Shield.

Tenga en cuenta los cambios de la aplicación que pueden influir positivamente en la proporción de aciertos de caché. Entre los ejemplos se incluyen:

• Reducción de los objetos de cardinalidad publicados por la aplicación. Cuando la aplicación produzca varias copias del mismo recurso, por ejemplo, tamaños diferentes de una imagen para adaptarse a diferentes pantallas, considere la posibilidad de limitar el número de valores posibles de anchura y altura.
• Aprovechamiento del almacenamiento en caché del navegador. Esto se puede hacer usando el encabezado Cache-Control enviado por el origen. Puede diferenciar los TTL entre CloudFront y el navegador mediante el uso de las directivas max-age con s-maxage en el encabezado Cache-Control o mediante el encabezado Cache-Control para el navegador y controlar los TTL de CloudFront usando las políticas de caché.
• Utilice solicitudes de rango de bytes en sus clientes para descargar solo lo que sea necesario.

• Blog: Improve your website performance with Amazon CloudFront
• Video: Amazon CloudFront Cache Policies Tutorial
• AWS re:Invent 2020: Improving website performance using Amazon CloudFront
  
• Blog: Host Single Page Applications (SPA) with Tiered TTLs on CloudFront and S3