Introducción

Optimizar el almacenamiento en caché dentro de su arquitectura AEM es una de las formas más rápidas de obtener un gran aumento del rendimiento.  Este artículo se centra en explicar cómo optimizar las distintas cachés que están disponibles dentro de una arquitectura AEM.

Arquitectura y Caching AEM

En todas las arquitecturas AEM, el usuario encuentra múltiples capas de caché cuando visita su sitio.  Hay 4 capas de caché a considerar en una arquitectura AEM estándar.  Esto incluye las instancias de Navegador Web, CDN, Dispatcher y AEM.

screenshot_2018-03-25160541

Almacenamiento en caché del navegador

El primer nivel de caché que un usuario encuentra en una visita repetida de su sitio es su propio navegador.  El almacenamiento en caché a nivel de navegador se realiza normalmente a través del Cache-Control: max-age=.... respuesta encabezado.  La configuración de max-age indica al navegador cuántos segundos debe guardar el archivo en caché antes de intentar "revalidar" o solicitarlo de nuevo desde el sitio.  Este concepto de caché max-age se conoce comúnmente como "Cache Expiration" o TTL ("Time to Live").

Hay varias opciones (o "directivas") en el Cache-Control encabezado que afectan a la forma en que se produce el almacenamiento en caché.  Las siguientes son algunas preguntas comunes:

  1. private - la privada directiva en el Cache-Control encabezado hace que el archivo solo se almacene en caché en el navegador, no en cachés intermedios como las CDNs.  Un uso práctico de esta directiva sería si su página incluye contenido personalizado/específico del usuario. 

    Ejemplo de uso:
      Cache-Control: max-age=300, private
  2. s-maxage - la s-maxage directiva en el Cache-Control permite establecer un TTL diferente para las cachés compartidas como las CDNs.  Cuando se establece este valor, el navegador usará lo que está establecido en max-age y otras cachés respetarán la configuración de s-maxage en su lugar.

    Ejemplo de uso:
      Cache-Control: max-age=600, s-maxage=300

Todos los navegadores modernos soportan el encabezado Cache-Control, sin embargo, algunas antiguas cabeceras obsoletas existen desde HTTP/1.0 que aún pueden tener un efecto en el cacheado.  Estas cabeceras son Expires y Pragma.  Si no necesita admitir navegadores muy antiguos, no envíe esas cabeceras de respuesta.
Además del almacenamiento en caché, la revalidación también es un concepto importante.  La revalidación se basa en los encabezados Last-Modified (response) / If-Modified-Since (request) y los ETag (respuesta) / If-None-Match (solicitud).

Precaución:

Pruebas de navegadores:

Al probar el almacenamiento en caché en Google Chrome, si estás probando sobre https y tienes un certificado autofirmado, no se almacenará nada en caché.  Chrome no almacena en caché las respuestas ni realizará una revalidación cuando haya un certificado no confiable o no válido.

Nota sobre el dispatcher:

Hay un problema con AEM Dispatcher v4.2.3 y versiones anteriores en las que /enableTTL solo cachés usando max-age directiva.  Esto significa que incluso cuando se establecen las directivas privado o s-maxage se guarda en caché si se establece max-age.  Este problema se resuelve en Dispatcher 4.2.4 y versiones posteriores.

Almacenamiento en caché de CDN

 Una CDN o "Red de Entrega de Contenido", es una red distribuida de servidores web diseñados para almacenar en caché y servir contenido desde la ubicación más cercana a sus usuarios.  Esto reduce los saltos de la red y la distancia desde el ordenador del usuario hasta su contenido, reduciendo así el "tiempo de viaje de ida y vuelta" (RTT).  RTT es el tiempo que tarda el navegador en enviar una solicitud a su sitio y recibir una respuesta.  La competencia en el espacio de proveedores de CDNs ha hecho que las CDNs sean muy rentables.  Esto hace que la decisión de usar una CDN para su sitio sea fácil.  Si usted no está usando una CDN todavía, entonces definitivamente debería incorporar una CDN en su sitio.

Hay muchos proveedores de CDN, cada uno ofrece diferentes características y configuraciones.

Cómo funciona el almacenamiento en caché de CDN

Las CDNs almacenan contenido en caché siguiendo reglas similares a las de los navegadores.  Se basan en Cache-Control HTTP response generalmente vuelven a la cabecera Expires si no se encuentra ninguna cabecera de Cache-Control.

La mayoría de las CDNs proporcionan alguna forma de activar un vaciado manual de la caché.  En muchos casos, los vaciados de caché tienen retraso (por ejemplo, 15 minutos) en cuanto a la propagación a todos los servidores de periferia que tienen sus archivos.

Optimización del uso de la CDN

Hay algunas cosas que hacer para asegurarse de que está almacenando archivos en caché de forma óptima en la CDN:

  1. Utilice una CDN que admita las cabeceras stale-while-revalidate y stale-if-error directivas en las Cache-Control.
    • stale-while-revalidate: esta directiva le dice a la CDN que sirva la versión antigua (ya almacenada en caché) del archivo mientras recupera una nueva después de que el archivo caché ha expirado.
    • stale-if-error: de manera similar, esta directiva le dice a la CDN que sirva la versión antigua (ya en caché) del archivo cuando el origen responde con un error durante la revalidación.
  2. GZip comprime las respuestas para todos los tipos de archivos que no están precomprimidos.
    • Debería hacerlo desde el nivel de dispatcher.  Esto le asegurará que reducirá el número de bytes enviados a la CDN.  Las CDN suelen cobrar por bytes transferidos, por lo que la compresión de las respuestas reduce los costes.
    • Active la compresión GZip en el nivel Dispatcher:
      • Apache: se usa mod_deflate.  Tenga cuidado con el uso de Vary por parte de mod_deflate.  En algunos casos, el encabezado Vary puede hacer que la CDN y el Navegador omitan por completo el almacenamiento en caché.
      • Microsoft IIS: se usa Compresión dinámica.
  3. Si su proveedor de CDN admite Edge-side Includes (ESI), aproveche esta función.
    • Los componentes AEM se pueden romper usando ESI.  Para hacer esto, use Apache Sling Dynamic Includes o implementar una solución personalizada.
    • Es útil cuando tiene páginas bastante estáticas pero está sirviendo contenido más dinámico en algunas partes de la página.  En estos casos, usted está dividiendo la página en múltiples archivos CDN.  De esta forma, puede almacenar en caché diferentes partes de la página durante diferentes períodos de tiempo.

Proveedores populares de CDN

Aquí hay una lista de algunos proveedores de CDN populares:

Precaución:

Tenga cuidado con el encabezado de respuesta Vary.  En algunos casos, Vary puede hacer que tanto la CDN como el navegador omitan por completo el almacenamiento en caché.  Como regla general, evite añadir Vary excepto Vary: Accept-Encoding (se aplica sólo cuando la respuesta está comprimida en gzip).  En otras palabras, si necesita "vary" la salida de una respuesta, utilice una URL diferente.

Por ejemplo, si tiene una versión diferente de HTML para móviles en comparación con la de escritorio, utilice una URL diferente.  Esto permitirá a las CDNs y a los navegadores almacenar en caché de forma más eficaz.

Almacenamiento en caché del Dispatcher de AEM

Si la caché de la CDN ha caducado, la solicitud llegará a la caché del dispatcher AEM.  En este nivel hay muchas cosas que se pueden hacer para optimizar el almacenamiento en caché.

Dado que este es un tema más amplio, vea este artículo para obtener más detalles sobre cómo optimizar la caché del dispatcher.

Instancias de publicación de AEM

En el nivel AEM hay algunas cosas que se deben hacer para optimizar el almacenamiento en caché a través de las distintas capas de caché:
  1. Configure las siguientes cabeceras de respuesta HTTP que no están configuradas por AEM de forma predeterminada.
    1. Cache-Control: max-age=... : Para establecer esta cabecera, se puede usar ACS Commons - Dispatcher TTL, o se puede implementar código personalizado para establecerla.
    2. Última modificación : Si el contenido de la página es relativamente estático, como por ejemplo un artículo, puede establecer su último encabezado modificado en la fecha/hora cq:lastModified (última vez que se modificó el artículo).  Sin embargo, si la página es dinámica con los resultados de la consulta JCR contenidos en el contenido del componente, lo mejor sería configurarla para que utilice la fecha/hora actual.
    3. ETag : si decide usar esto en lugar de Last-Modified, podría escribir un ReplicationEventListener que escuche las activaciones de página y genere un hash md5 del contenido de la página.  Esto podría establecerse como una propiedad en el nodo jcr:content de la página en la instancia de autor.  Cuando las páginas se replican, se envía a las instancias de publicación.  Para componentes de página con contenido relativamente estático, esto podría funcionar bien, sin embargo, si la página es algo dinámica o hace referencia a mucho contenido, entonces el ETag tendría que ser omitido (o calculado).
  2. Si el sitio tiene contenido personalizado / dinámico:
    1. Utilice las Apache Sling Dynamic incluye para dividir el contenido de modo que las diferentes partes de la página puedan almacenarse en caché durante diferentes periodos de tiempo.
      1. El almacenamiento en caché puede realizarse con las siguientes tecnologías:
        1. Edge-side incluye (ESI) en el CDN
        2. Server-side Includes (SSI) en el servidor web
        3. O bien, Javascript asíncrono y XML (AJAX) en el navegador
      2. Los componentes de la página se pueden dividir en solicitudes separadas que se pueden almacenar en caché durante diferentes períodos de tiempo.  Las partes de la página que son relativamente estáticas podrían almacenarse en caché durante períodos de tiempo mucho más largos.
    2. Considere la posibilidad de utilizar la función de caché HTTP de ACS Commons.
    3. Habilitar la minificación en las librerías del cliente.
    4. Insertar cliente bibliotecas para minimizar y reducir archivos js y css.

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea