Rendimiento de Shopware 6: caché HTTP, CDN y errores comunes

Una tienda Shopware 6 lenta rara vez es un misterio. En la mayoría de los casos la caché HTTP está desactivada o se invalida sin parar, el trabajo en segundo plano se ejecuta donde no debe o el servidor hace en cada petición un trabajo costoso que podría ahorrarse. Esta guía explica cómo funciona la caché HTTP de Shopware 6, cómo comprobarla, dónde ayuda un CDN y cuáles son los errores de configuración más habituales.

Cómo funciona la caché HTTP de Shopware 6

Shopware 6 incluye una caché de página completa para el storefront. Cuando está activada, la primera petición de una página (por ejemplo, una categoría o una ficha de producto) la renderiza PHP y se guarda, y las siguientes peticiones de esa misma página reciben la copia guardada sin volver a ejecutar toda la aplicación. Es la palanca más potente para la velocidad de la tienda.

Hay varios factores que influyen en lo bien que funciona:

• Tiene que estar activada. La caché se controla con la variable de entorno SHOPWARE_HTTP_CACHE_ENABLED=1, que normalmente se define en .env.local.
• Almacenamiento. Por defecto, la caché vive en el sistema de archivos, en var/cache. Para un solo servidor es suficiente. Con varios servidores de aplicación, la documentación de cachés de Shopware (en inglés) recomienda una caché compartida como Redis.
• Variantes por contexto. Una página puede verse distinta según si el visitante ha iniciado sesión, la moneda, el régimen de impuestos o las reglas de precio que se aplican. Shopware resume todo eso en la cookie sw-cache-hash y guarda una variante distinta por cada hash, para que ningún cliente vea los precios de otro. Los visitantes en el estado predeterminado (sin sesión, moneda predeterminada, carrito vacío) comparten las mismas páginas en caché.
• Invalidación por etiquetas. Las respuestas en caché llevan etiquetas con los datos a partir de los que se generaron. Cuando cambias un producto, Shopware elimina las páginas en caché etiquetadas con él en lugar de borrarlo todo. Las rutas de tipo listado, como los listados de productos, de categorías y los resultados de búsqueda, no llevan etiquetas de todas las entidades que devuelven y dependen de su tiempo de vida en caché, así que un cambio puede tardar un rato en aparecer ahí.

Caché integrada o proxy inverso

Para tiendas más grandes, Shopware admite un proxy inverso externo, en concreto Varnish con el módulo XKey o Fastly. El proxy guarda las páginas y Shopware le envía peticiones de invalidación con las etiquetas afectadas. Desde Shopware 6.6 se configura en shopware.http_cache.reverse_proxy (las versiones anteriores usan storefront.reverse_proxy) y se define SYMFONY_TRUSTED_PROXIES para que la aplicación vea las IP reales de los clientes. La documentación sobre la caché HTTP inversa (en inglés) describe la configuración completa.

Un proxy inverso quita toda la carga de PHP en los aciertos de caché, algo que se nota en las horas punta. Pero también es un componente más que hay que mantener y vigilar. Para muchas tiendas pequeñas y medianas, la caché integrada con Redis es suficiente.

Comprueba si la caché funciona

Antes de cambiar nada, averigua qué está pasando de verdad. Abre una página de categoría dos veces en una ventana privada y compara los tiempos de respuesta en la pestaña de red del navegador. Con la caché funcionando, la segunda petición es claramente más rápida. Desde la línea de comandos:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -sI https://shop.example.com/some-category/ | grep -i cache-control

Si las dos peticiones son igual de lentas, la caché está desactivada, una cookie la está esquivando o se invalida entre una petición y otra. Revisa también la cabecera Cache-Control: indica a cualquier proxy o CDN situado delante de Shopware si puede guardar la página.

Para una comparación ordenada de antes y después, el TTFB es la métrica que hay que vigilar en el lado del servidor. Nuestra guía para reducir el TTFB profundiza en el servidor y la aplicación.

Errores de configuración habituales

Estos son los problemas que con más frecuencia explican una tienda Shopware 6 perezosa.

Modo dev o depuración activada

APP_ENV=dev activa el profiler y funciones de depuración que ralentizan cada petición. Las tiendas en producción necesitan APP_ENV=prod. Pon también el nivel de log en error o similar en producción, porque un registro detallado escribe en cada petición.

El admin worker se encarga de las tareas en segundo plano

Por defecto, Shopware puede procesar los mensajes en cola (indexación, correos, importaciones) a través de la administración mientras un usuario tiene el backend abierto. Es cómodo en desarrollo, pero en producción hace que el trabajo en segundo plano sea impredecible y carga el servidor web. La documentación de la cola de mensajes (en inglés) lo dice sin rodeos: en producción, procesa la cola por CLI. Define shopware.admin_worker.enable_admin_worker: false en config/packages/shopware.yaml y ejecuta bin/console messenger:consume async como proceso en segundo plano mantenido por systemd o supervisor, además de bin/console scheduled-task:run para las tareas programadas.

Tormentas de invalidación

Las sincronizaciones con el ERP, las actualizaciones de stock y las importaciones de precios tocan muchos productos a la vez. Cada cambio invalida páginas en caché, así que una importación que se ejecuta cada pocos minutos puede dejar la caché vacía casi de forma permanente. Opciones: agrupar las importaciones en menos ejecuciones, escribir solo los campos que han cambiado de verdad y usar la invalidación diferida. Con ella, Shopware acumula las etiquetas que hay que invalidar y las procesa más tarde en una tarea en segundo plano. Por defecto esa lista se guarda en la base de datos; la documentación de ajustes de rendimiento (en inglés) recomienda Redis como almacenamiento siempre que puedas usarlo.

Extensiones que rompen la caché

Los plugins pueden guardar cookies, añadir bloques personalizados o cambiar el contexto en cada petición. Cualquiera de estas cosas puede crear una variante de caché distinta por visitante, lo que en la práctica significa no tener caché. Si la tasa de aciertos se hundió después de instalar una extensión, prueba con ella desactivada en una copia de staging.

Búsqueda MySQL en un catálogo grande

Con catálogos grandes, la búsqueda de productos y los listados filtrados son costosos en MySQL. Shopware admite Elasticsearch u OpenSearch para la búsqueda y los listados del storefront. Los resultados de búsqueda normalmente no se guardan en la caché de página completa, así que esto afecta directamente a las páginas donde los usuarios escriben y filtran.

PHP y OPcache

Asegúrate de que OPcache está activado y dimensionado para el código de Shopware. En producción, opcache.validate_timestamps=0 evita comprobar los archivos en cada petición (a cambio, tienes que reiniciar OPcache en cada despliegue). Usa una versión actual de PHP compatible con tu versión de Shopware.

Imágenes y recursos del tema demasiado pesados

Las fotos de producto sacadas directamente de la cámara, las miniaturas que faltan o los banners gigantes perjudican el Largest Contentful Paint. Deja que Shopware genere las miniaturas, sube las imágenes con dimensiones razonables y plantéate usar formatos modernos. Nuestra guía para optimizar imágenes para la web entra en los detalles.

Dónde ayuda un CDN (y dónde no)

Un CDN se sitúa entre tus visitantes y tu servidor Shopware y sirve el contenido desde ubicaciones más cercanas a ellos.

Lo que un CDN no arregla: las peticiones lentas sin caché. Si el checkout tarda varios segundos por un plugin de pago lento o una base de datos saturada, el CDN transmite ese tiempo tal cual. Arregla primero el origen y añade después la capa de edge.

Un orden de trabajo razonable

1. Define APP_ENV=prod, reduce el logging y revisa OPcache.
2. Activa la caché HTTP y confirma que funciona para invitados.
3. Pasa las tareas en segundo plano a workers por CLI y desactiva el admin worker.
4. Controla las importaciones para que no vacíen la caché continuamente.
5. Añade Redis (y, en tiendas grandes, OpenSearch) donde la carga lo pida.
6. Optimiza las imágenes y los recursos del tema.
7. Pon delante una capa de edge para los recursos estáticos, las páginas de invitados y la protección.

Mide después de cada paso, a ser posible con las mismas páginas y herramientas, para saber qué ha marcado la diferencia. Si también gestionas WooCommerce, los principios son parecidos: consulta cómo acelerar WooCommerce sin romper el checkout.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting actual de Shopware. Mantienes tu proveedor y tu instalación de Shopware, añades el dominio en el panel y apuntas los servidores de nombres de tu dominio a fast.site.

Fast Edge Cache™ guarda las respuestas públicas en el edge. La caducidad sigue las cabeceras Cache-Control que envía tu tienda o las reglas que tú definas, y puedes comprobar cada respuesta con la cabecera fs-cache (HIT, MISS o BYPASS). El carrito, el checkout, la cuenta y el resto de páginas basadas en sesión se saltan la caché, así que los pedidos siguen funcionando como siempre. Después de cambios grandes en el catálogo puedes vaciar URL desde el panel o mediante la API, y el precalentador de caché mantiene listas las páginas importantes.

Además, las imágenes se convierten a WebP al vuelo para los navegadores compatibles (AVIF según tu plan), los recursos 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 antes de que llegue a tu servidor. La página de Shopware y el artículo sobre la integración con Shopware muestran la configuración en detalle.

La prueba honesta es tu propia tienda: compara el TTFB y las Core Web Vitals antes y después. Puedes empezar con una prueba gratuita de 7 días, sin tarjeta de crédito.

Preguntas frecuentes

¿Cómo activo la caché HTTP en Shopware 6?

Define SHOPWARE_HTTP_CACHE_ENABLED=1 en tu .env.local y vacía la caché después. Asegúrate de que la tienda funciona con APP_ENV=prod. Luego abre una página de categoría dos veces como invitado y confirma que la segunda petición es claramente más rápida.

¿Por qué va lenta mi tienda Shopware con la caché HTTP activada?

Los motivos habituales son invalidaciones frecuentes por importaciones, extensiones que guardan cookies o personalizan páginas y páginas lentas sin caché, como la búsqueda, el carrito y el checkout. Comprueba si las páginas de invitados se sirven de verdad desde la caché y revisa después qué se ejecuta en las peticiones sin caché.

¿Necesito Varnish para Shopware 6?

No necesariamente. La caché integrada basta para muchas tiendas, sobre todo con Redis como almacenamiento. Varnish u otro proxy inverso compensa cuando tienes varios servidores de aplicación o mucho tráfico, pero añade infraestructura que tienes que mantener.

¿Puedo usar un CDN con Shopware 6?

Sí. Los recursos estáticos y las imágenes se sirven fácilmente desde un CDN. Las páginas HTML para invitados también se pueden cachear, siempre que el CDN respete las cabeceras de caché de Shopware, se salte el carrito, el checkout y la cuenta, y tengas una forma de vaciar la caché tras los cambios.

¿Cómo vacío la caché de Shopware?

En tiendas autoalojadas, abre en la administración Settings > System > Caches & Indexes y usa Clear cache, o ejecuta bin/console cache:clear en la línea de comandos. Si usas un proxy inverso, bin/console cache:clear:http (disponible desde Shopware 6.6.10) vacía esa caché. Vaciarlo todo suele hacer que los siguientes visitantes encuentren la caché en frío, así que hazlo fuera de las horas punta.