Maximizar la tasa de aciertos en caché

Una de las mejores maneras de mejorar el rendimiento de su storefront es maximizar la tasa de aciertos en caché. Cualquier solicitud que pueda satisfacerse desde la caché de la CDN de Managed Runtime cuenta como un acierto en caché. Con cada acierto en caché, se acelera la carga de la página para el usuario porque se ahorra el costo de renderizar dicha página del lado del servidor y de hacer solicitudes a los sistemas de backend y a las API.

Esta guía cubre tres técnicas diferentes para maximizar los aciertos en caché: la configuración del tiempo de almacenamiento óptimo en la caché, el renderizado condicional y el filtrado de las cadenas de consulta. Veamos cada técnica en detalle.

La cantidad óptima de tiempo para almacenar una solicitud de HTTP en la caché depende de lo que se solicite. Una solicitud para cargar una página de contenido que cambia muy poco puede almacenarse en la caché de forma segura durante mucho tiempo. Por el contrario, una página de listado de productos que se actualiza con frecuencia con productos nuevos podría requerir un almacenamiento corto en la caché, como de quince minutos. Siempre que sea posible, elija tiempos largos de almacenamiento en la caché para maximizar la tasa de aciertos en la caché.

Un encabezado de control de la caché en la respuesta de HTTP determina el tiempo que una respuesta a una solicitud de página se almacena en la caché de la CDN. El tiempo de almacenamiento en la caché para las respuestas de las páginas en un proyecto PWA Kit es de 600 segundos (o 10 minutos) predeterminados. Puede personalizar el tiempo de almacenamiento en la caché de las páginas una por una, o puede establecer uno para todas por igual.

La función getProps de cualquier componente de página permite personalizar la respuesta de HTTP mediante un objeto que se pasa llamado res. Para establecer el tiempo de almacenamiento en la caché de una página, utilice el método set del objeto res para establecer un encabezado Cache-Control y especifique un valor en segundos para la directiva max-age.

Por ejemplo, este componente ProductList amplía tiempo de almacenamiento en la caché de los 600 segundos predeterminados a los 900 segundos:

Se puede establecer el tiempo de almacenamiento en la caché para todas las páginas desde app/ssr.js. Puede cambiar el tiempo predeterminado de almacenamiento de la caché estableciendo un nuevo valor para defaultCacheTimeSeconds. Si necesita un control más detallado del encabezado de HTTP, añada un manejador Express que establezca un encabezado personalizado, de esta forma:

Puede comprobar que los controles de la caché estén presentes en los encabezados de respuesta inspeccionando las solicitudes de red con las DevTools de Chrome en la pestaña Red. De manera alternativa, puede ejecutar el siguiente comando curl en su terminal, que muestra todos los encabezados de respuesta. Sustituya <URL> en el comando de ejemplo por la URL completa que desea probar e incluya cualquier cadena de consulta necesaria.

Para asegurarse de que una página es apta para el almacenamiento en caché por la CDN, debe añadir código condicional para evitar la renderización de los siguientes tipos de contenido del lado del servidor:

• Contenido personalizado, como el nombre del usuario, el número de artículos en el carrito y el método de pago preferido. El contenido personalizado es inapropiado e irrelevante para cualquier persona que no sea un único usuario. El almacenamiento en caché de las respuestas para un único usuario no aumenta los aciertos en la caché.
• Contenido que cambia frecuentemente, como el precio de un producto, el inventario restante o las promociones de venta. Este contenido no es adecuado para el almacenamiento en caché porque se corre el riesgo de confundir al usuario cuando la página contiene información que ya está desactualizada.

Piense en la página que se renderiza del lado del servidor como una base genérica sobre la que se construye la que ve el cliente. Después de cargar rápidamente la versión del lado del servidor de la página en el dispositivo del usuario, el navegador se encarga de renderizar el contenido personalizado y el contenido que cambia con frecuencia.

Para determinar si la renderización se produce del lado del cliente o del servidor, compruebe la presencia del objeto window, que solo está presente del lado del cliente. El siguiente ejemplo utiliza esta técnica para renderizar un precio solo del lado del cliente:

La mayoría de las aplicaciones de storefront utilizan la cadena de consulta de una URL para almacenar parámetros y valores que representan aspectos del estado de la aplicación. Por ejemplo, cuando un usuario busca “suéteres”, puede incluir el término de búsqueda en la cadena de consulta de esta forma: ?search=sweaters. Las cadenas de consulta también se utilizan comúnmente para rastrear las acciones del usuario. Por ejemplo, podemos añadir una cadena de consulta única a cada vínculo de un correo electrónico para hacer un seguimiento de las interacciones con este: user=juanita&source=email.

No todos los parámetros de cadenas de consulta son relevantes cuando se trata del almacenamiento en caché. Managed Runtime incluye una función perimetral llamada procesador de solicitudes que permite modificar la cadena de consulta de una solicitud antes de buscar respuestas en la caché. Puede aumentar los aciertos en la caché utilizando el procesador de solicitudes para mapear URL similares a la misma respuesta en caché.

Para personalizar el procesador de solicitudes, edite la función processRequest definida en app/request-processor.js.

El siguiente ejemplo define un procesador de solicitudes que filtra los parámetros gclid y utm_campaign de la cadena de consulta. Estos parámetros están comúnmente asociados a las campañas de marketing de Google y solo son útiles del lado del cliente. Para simplificar el trabajo con las cadenas de consulta, importa la clase QueryParameters del SDK de React del PWA Kit.

La URL completa que se utiliza para buscar el objeto correspondiente en la caché incluye la versión de la cadena de consulta que devuelve el procesador de solicitudes. Si no hay una respuesta en la caché para esa URL, esta misma versión modificada de la URL se pasa a la aplicación Express.

Tenga cuidado con dos cosas al usar este enfoque:

En primer lugar, asegúrese de que su aplicación no dependa de ningún parámetro filtrado para la renderización. Por ejemplo, si filtrara el parámetro search de arriba, le costaría mostrar los resultados de búsqueda correctos.

En segundo lugar, tenga cuidado al filtrar los parámetros de las solicitudes que espera redirigir. Si el código no puede acceder a un parámetro filtrado, dicho parámetro tampoco puede utilizarse para la redirección. Considere una solicitud como un componente de la página de inicio que redirige una solicitud de www.example.com?lang=en a una ruta específica de configuración local, como www.example.com/en. Si se filtra el parámetro lang, no se puede redirigir a la configuración local correcta.

Considere esta secuencia:

1. El procesador de solicitudes se encarga de las solicitudes para www.example.com/?gclid=123.
2. El procesador de solicitudes filtra el parámetro de cadena de consulta gclid.
3. La solicitud se reenvía a la aplicación con la URL completa www.example.com.
4. La aplicación devuelve un redireccionamiento a www.example.com/en.

Observe cómo, en este último paso, hemos perdido el parámetro original gclid, por lo que no estará disponible en el navegador después de que el usuario sea redirigido. Para solucionar este problema, evite filtrar las cadenas de consulta de las solicitudes que espera redirigir.

Ahora ya sabe utilizar diferentes técnicas para mejorar los aciertos de la caché para las solicitudes de páginas.

Lea nuestra guía sobre Solicitudes de conexión del proxy para obtener más información acerca del almacenamiento en caché de solicitudes de API y otros beneficios de las conexiones proxy.