CDN para Shopware 6: qué cachear y qué no

Un CDN delante de Shopware 6 compensa en dos sitios: los archivos estáticos, como el CSS, el JavaScript del tema y las imágenes de producto, que pueden quedarse mucho tiempo en el edge, y las páginas HTML para invitados en el estado predeterminado de Shopware, que necesitan vidas cortas y un plan de purga. Todo lo personal, del carrito y el checkout a las páginas de cuenta, los clientes con sesión iniciada y los invitados que han cambiado de moneda, tiene que ir directamente a tu servidor Shopware. Esta guía muestra dónde trazar esa línea, cómo vaciar la caché y cómo comprobarlo todo.

La optimización de la propia tienda (caché HTTP, workers, OPcache, importaciones) la tratamos en nuestra guía de rendimiento de Shopware 6. Aquí nos centramos en la capa que va delante.

CDN de recursos o CDN de sitio completo

CDN de recursos. Shopware puede generar las URL de los archivos públicos en un host distinto. En la configuración del sistema de archivos (en inglés) defines una url para el sistema de archivos public, y los de tema, recursos y sitemap la heredan por defecto. Esto solo cambia las URL de la página. El CDN sigue descargando los archivos de tu servidor o de tu bucket, y cada petición de HTML sigue llegando a Shopware.

CDN de sitio completo. Todo el dominio pasa por el CDN, configurado mediante servidores de nombres o DNS según el proveedor. El edge ve todas las peticiones, HTML incluido, y puede filtrar el tráfico malicioso antes de que llegue a tu servidor. La ganancia es mayor, y la responsabilidad también: el CDN tiene que saber exactamente qué respuestas puede guardar.

Los archivos estáticos son la parte fácil

Los archivos compilados del tema admiten vidas largas en el edge: en cada compilación, Shopware escribe el CSS y el JavaScript en una carpeta nueva dentro de theme/ con un hash nuevo en el nombre, así que las URL cambian. Las imágenes de producto y las miniaturas cambian poco y a menudo suponen la mayor parte de los bytes de una página. Nuestra guía para optimizar imágenes para la web trata los formatos y los tamaños.

La excepción es un archivo que se sustituye con la misma URL, como una imagen del CMS con el mismo nombre de archivo. Vacía esa URL cuando la cambies.

Qué páginas de Shopware se pueden cachear sin riesgo

Shopware no cachea una sola página para todo el mundo. Según la documentación de la caché HTTP (en inglés), guarda una cookie sw-cache-hash en cuanto el estado de un visitante difiere del predeterminado, que es: ningún cliente con sesión iniciada, la moneda predeterminada y el carrito vacío. El hash codifica el estado de sesión, la moneda, el régimen de impuestos y las reglas relevantes para la caché que se han cumplido, y Shopware guarda una variante de caché distinta por cada hash. Los visitantes en el estado predeterminado comparten una misma variante.

Un CDN que usa solo la URL como clave de caché no sabe nada de estas variantes. Así que la regla para el HTML es: cachea solo lo que ve un invitado en el estado predeterminado y envía a Shopware toda petición que lleve sw-cache-hash.

Los precios por grupo de clientes y otros contenidos basados en reglas también acaban en el hash, así que esos visitantes nunca deben recibir la página predeterminada en caché.

Respeta Cache-Control y las cookies

El edge no debería adivinar qué se puede cachear, porque Shopware ya lo indica. Con la caché HTTP activada, las respuestas cacheables del storefront llevan una vida para cachés compartidas (s-maxage); la documentación del proxy inverso pone como ejemplo Cache-Control: public, s-maxage=7200. Las respuestas para clientes con sesión iniciada o con el carrito lleno no llevan esas cabeceras.

Uses el CDN que uses, hay dos reglas:

1. Guarda solo lo que Shopware marca como público. No guardes nunca respuestas con private, no-cache o no-store, ni una respuesta que establezca una cookie. Una regla general de "cachearlo todo" pasa por encima de las decisiones de Shopware y es así como un cliente acaba viendo el carrito de otro.
2. Sáltate la caché del edge en las peticiones con sw-cache-hash, o incluye esa cookie en la clave de caché. Si el CDN la ignora, un invitado que cambió de moneda puede recibir desde el edge la página en la moneda predeterminada. Peor aún, su variante podría guardarse y servirse a todos los demás.

Si quieres cambiar las vidas en caché, ajústalas en Shopware y no en el edge. Las versiones más recientes ofrecen políticas de caché HTTP (en inglés) con directivas como s_maxage y stale_while_revalidate por área o por ruta. La documentación las marca como experimentales y previstas como opción predeterminada para Shopware 6.8, así que comprueba tu versión.

Varnish, Fastly y un CDN genérico

Shopware admite oficialmente dos proxies inversos: Varnish con el módulo XKey y Fastly. Ambos están integrados en su invalidación: las respuestas en caché llevan etiquetas (surrogate keys) con los datos a partir de los que se generaron, y cuando editas un producto, Shopware envía al proxy una petición de invalidación justo para esas etiquetas. Desde Shopware 6.6 se configura en shopware.http_cache.reverse_proxy. La documentación de la caché HTTP inversa (en inglés) describe la configuración completa.

Un CDN genérico no forma parte de ese circuito. La invalidación por etiquetas de Shopware llega a su propia caché y a un proxy inverso configurado, pero no a una red edge que no conoce. Una página de categoría cacheada en el edge se queda ahí hasta que caduca su vida o la vacías.

Un proxy basado en etiquetas te da una invalidación precisa para catálogos grandes que cambian rápido, pero es un sistema más que mantener. Un CDN genérico de sitio completo es más fácil de añadir y aporta entrega desde el edge y protección, pero la frescura del HTML depende de vidas cortas y de tus propias purgas. Algunas tiendas combinan las dos cosas.

Una estrategia de purga sin etiquetas

Vidas cortas para el HTML. Mantén el HTML para invitados en el edge durante minutos en lugar de horas, mientras que los archivos del tema y las imágenes se quedan mucho más. Así, una copia desactualizada en el edge desaparece como mucho tras una vida, incluso sin purga. La caché integrada de Shopware absorbe los misses adicionales.

Purgas por URL después de cambios grandes. Cuando empiezan unas rebajas, cambian los precios de toda una categoría o editas la navegación, vacía las URL afectadas. Los cambios que aparecen en todas las páginas, como el menú principal, el pie de página o un tema recompilado, justifican vaciar todo el dominio, a ser posible fuera de las horas punta.

Purgas desde tus scripts. La mayoría de los CDN, fast.site incluido, ofrecen una API de purga. Haz que tu importación del ERP o de precios termine con una llamada que vacíe las URL que ha tocado, y que tu pipeline de despliegue vacíe la caché después de theme:compile.

IP reales de los clientes y proxies de confianza

Detrás de un CDN, cada petición llega a Shopware desde un servidor edge. La IP real del visitante viaja en una cabecera como X-Forwarded-For, que Symfony solo lee de los proxies en los que confías mediante SYMFONY_TRUSTED_PROXIES en tu .env (el nombre de la variable desde Shopware 6.6). Si encadenas un CDN y Varnish, confía en los dos saltos.

Esto importa más allá de tus logs. Los plugins de pago y antifraude suelen comprobar la IP del cliente, y los limitadores de peticiones de Shopware para el login, el restablecimiento de contraseña y el formulario de contacto pierden precisión cuando todas las peticiones parecen venir de unas pocas direcciones.

Cómo probar tu configuración de CDN con Shopware

1. Petición como invitado, dos veces. La segunda petición debería venir del edge:

curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'
curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'

En fast.site, busca fs-cache: HIT y un fs-cache-age que va creciendo (consulta cómo comprobar la caché). Otros CDN suelen enviar una cabecera Age y su propia cabecera de estado. Si la página nunca llega a HIT, compara su cabecera Cache-Control con las reglas de arriba.

2. Rutas personales. Comprueba /checkout/cart y /account/login del mismo modo. Nunca deben mostrar un HIT.

3. Un checkout completo. En una ventana privada, añade un producto, comprueba que el contador del carrito se actualiza y completa el checkout con un método de pago de prueba. Cancela después el pedido de prueba.

4. Cliente con sesión iniciada. Inicia sesión con una cuenta de prueba, a ser posible una con precios por grupo de clientes. Las páginas deben mostrar los precios de ese cliente, y la vista de invitado debe volver tras cerrar sesión.

5. Cambio de moneda. Como invitado, cambia a una segunda moneda y recorre unas cuantas categorías. Después abre las mismas páginas en una ventana privada nueva: deben mostrar la moneda predeterminada. Repítelo en el orden inverso. Así detectas un CDN que ignora sw-cache-hash.

Con varios canales de venta o idiomas, repite los pasos 1 y 5 para cada dominio. En cuanto a velocidad, compara los datos de usuarios reales y una prueba de laboratorio en corewebvitals.page antes y después, como se explica en cómo medir bien la velocidad de una web.

Cómo te ayuda fast.site

fast.site es una capa edge de sitio completo delante de tu hosting actual de Shopware. Mantienes tu proveedor, añades el dominio en el panel y apuntas sus servidores de nombres a fast.site; nuestra checklist para cambiar los servidores de nombres te ayuda a conservar intactos los registros DNS y el correo.

Fast Edge Cache™ respeta las cabeceras Cache-Control que envía tu tienda. Las respuestas privadas y dinámicas, como el carrito, el checkout y las sesiones iniciadas, muestran fs-cache: BYPASS, así que puedes seguir directamente el plan de pruebas de arriba. fast.site no recibe las invalidaciones por etiquetas de Shopware. En su lugar, vacías URL concretas o todo el dominio desde el panel, con un registro de purgas, o mediante la API desde tus scripts de importación y despliegue. Un precalentador de caché mantiene listas las páginas importantes.

Las imágenes se convierten a WebP al vuelo (AVIF según tu plan), los archivos de texto se comprimen con Brotli, y la detección de DDoS en capa 7, la limitación de peticiones y los conjuntos de reglas contra bots filtran el tráfico en el edge. La página de Shopware tiene los detalles.

Mide el resultado en tu propia tienda, con las mismas páginas antes y después. Puedes empezar con una prueba gratuita de 7 días, sin tarjeta de crédito.

Preguntas frecuentes

¿Shopware 6 tiene un CDN integrado?

No. Shopware tiene una caché HTTP integrada en tu servidor, y puedes definir una URL aparte para los archivos públicos para que se carguen desde el host de un CDN. Como proxies inversos, Shopware integra oficialmente Varnish con XKey y Fastly.

¿Puedo cachear las páginas HTML de Shopware en un CDN?

Sí, para invitados en el estado predeterminado: sin sesión iniciada, moneda predeterminada y carrito vacío. El CDN tiene que respetar las cabeceras Cache-Control de Shopware, saltarse las peticiones con la cookie sw-cache-hash y no cachear nunca el carrito, el checkout ni las páginas de cuenta.

¿Por qué el carrito o los precios se ven mal después de añadir un CDN?

Normalmente porque el edge cachea algo personal: una respuesta que establece una cookie, una página pedida con sw-cache-hash o una ruta del checkout atrapada por una regla de "cachearlo todo". Elimina la regla, vacía el dominio y repite las pruebas.

¿Sigo necesitando la caché HTTP de Shopware detrás de un CDN?

Sí. Cada miss en el edge y cada petición con cookie sw-cache-hash llega a tu servidor. La caché integrada mantiene rápidas esas peticiones, y las vidas cortas en el edge solo funcionan bien con un origen ágil.

¿Cómo vacío la caché del CDN después de cambios en Shopware?

bin/console cache:clear y cache:clear:http de Shopware no llegan a un CDN genérico. Vacía las URL afectadas o todo el dominio en el panel del CDN, o mediante su API desde el script que hizo el cambio.