CDN para WooCommerce: guía de configuración

Una tienda WooCommerce funciona bien detrás de un CDN cuando el edge sirve los archivos estáticos y las páginas de catálogo que ven los invitados, mientras que todo lo personal o transaccional va directamente a tu servidor: carrito, checkout, área de cuenta, visitantes con un carrito activo, llamadas AJAX y de API y notificaciones de pago. Acertar con esas excepciones, mantener los precios al día con purgas concretas y probar un pedido real es la mayor parte del trabajo de configuración. Para el resto del rendimiento de la tienda (plugins de caché, base de datos, tareas en segundo plano), consulta la guía para acelerar WooCommerce.

Dos formas de poner un CDN delante de una tienda

• CDN de recursos. Un plugin reescribe las URL de imágenes, CSS y JavaScript hacia el host de un CDN, mientras que todas las páginas siguen saliendo de tu servidor. El riesgo es bajo, porque ninguna página se comparte entre clientes, pero la parte más lenta, generar el HTML, queda intacta.
• Proxy de sitio completo. Todas las peticiones pasan por el edge, HTML incluido, así que una ficha de producto en caché nunca llega a PHP ni a la base de datos. Ahí están las mayores ganancias, y ahí es donde WooCommerce requiere cuidado: el edge es una caché compartida, y una sola regla equivocada hace que el cliente B vea el carrito del cliente A.

El resto de esta guía trata de la segunda opción. Si todavía estás comparando proveedores, la guía para elegir un CDN para WordPress repasa los criterios.

Qué puede cachear el edge sin riesgo

"Solo para invitados" es la clave. La misma URL de producto puede verse distinta para un cliente con sesión iniciada o para alguien con artículos en el carrito, y el edge tiene que saber distinguir esas peticiones.

Query strings

Los parámetros de seguimiento como utm_source crean una entrada de caché distinta por cada variante, así que una campaña puede convertir sin hacer ruido los hits en misses. Los parámetros que cambian el contenido, como orderby o los filtros de navegación por capas, sí necesitan legítimamente sus propias entradas.

Qué tiene que llegar siempre a tu servidor

Páginas

La guía de WooCommerce para configurar plugins de caché (en inglés) cita el carrito, el checkout y Mi cuenta como páginas que hay que excluir. Eso incluye todo lo que cuelga de ellas, como /checkout/order-received/ después del pago y las páginas de pedidos y direcciones bajo /my-account/. Si has cambiado el nombre de estas páginas o tienes una tienda multidioma, cuentan todos los slugs y todas las versiones de idioma.

WooCommerce ayuda: en las páginas de carrito, checkout y cuenta envía cabeceras Cache-Control que prohíben cachearlas. Un CDN que respete las cabeceras del origen no las guardará. Comprueba que ningún plugin de caché o de seguridad de tu web sobrescribe esas cabeceras.

Cookies

Las cabeceras solo cubren esas tres páginas. Una ficha de producto que ve alguien con el carrito lleno tiene cabeceras normales y cacheables, pero puede mostrar su mini carrito, así que la excepción también tiene que depender de las cookies. Las que enumera WooCommerce son:

• woocommerce_cart_hash y woocommerce_items_in_cart (se crean en cuanto hay algo en el carrito)
• wp_woocommerce_session_* (la sesión del cliente)
• woocommerce_recently_viewed y store_notice[notice id] (solo relevantes si usas el widget de productos vistos recientemente o el aviso de la tienda)

Añade la cookie de inicio de sesión de WordPress wordpress_logged_in_*, para que los clientes y el personal con sesión iniciada reciban siempre páginas frescas.

Endpoints

• Peticiones ?wc-ajax=, que se usan para añadir al carrito, aplicar cupones y refrescar el checkout
• /wp-admin/, admin-ajax.php y wp-login.php
• Enlaces con ?add-to-cart=
• La Store API (en inglés) en /wp-json/wc/store/v1/, en la que se basan el carrito y el checkout por bloques. Sus respuestas reflejan la sesión del cliente actual.
• La API REST autenticada en /wp-json/wc/v3/, que usan las integraciones con ERP, inventario y marketplaces
• Las notificaciones de pago (más sobre ellas abajo)

El mini carrito en las páginas cacheadas

Con un tema clásico, el contador del mini carrito de una página cacheada se rellena después mediante el script de cart fragments, que llama a ?wc-ajax=get_refreshed_fragments y guarda el resultado en el almacenamiento de sesión del navegador. Los temas de bloques cargan los datos del carrito con sus propias peticiones, que también tienen que quedarse sin caché. La página se puede cachear precisamente porque la parte personal llega en una petición aparte y sin caché. Si esa petición se cachea, todos los visitantes ven el mismo contador. Si necesitas o no los cart fragments se explica en la guía para acelerar WooCommerce.

Precios, monedas y ubicaciones

Una caché compartida solo funciona si todo lo que cambia una página se ve en la URL o se resuelve con una excepción. Las cookies y las direcciones IP son invisibles para una clave de caché basada en la URL.

• Geolocalización. Con la opción "Geolocate" a secas como ubicación predeterminada del cliente, los precios se generan en el servidor según el país del visitante, así que detrás de una caché compartida el país del primer visitante decide lo que ven todos. La documentación de los ajustes generales de WooCommerce (en inglés) describe para este caso "Geolocate (with page caching support)": geolocaliza mediante AJAX y añade un parámetro ?v= a las URL. Cada variante se convierte en una entrada de caché propia, así que cuenta con más misses.
• Selectores de moneda. Muchos guardan la moneda elegida en una cookie. Si esa cookie no provoca una excepción, una página cacheada muestra la moneda con la que se generó por primera vez. Elige un selector que ponga la moneda en la URL o que cargue los precios en el navegador, y revisa su documentación sobre caché.
• Precios por cliente. Los precios mayoristas o por rol normalmente solo se muestran a usuarios con sesión iniciada, que se saltan la caché de todos modos. Asegúrate de que la forma de mostrar el precio depende de verdad del inicio de sesión y no de otra cookie.

Mantén al día el stock y los precios

Elige la vida en caché del HTML según lo que te cueste una página desactualizada. Una página de contenido puede quedarse en caché durante horas; una ficha de producto con un stock que se mueve rápido debería caducar antes o vaciarse con cada cambio.

• Edición de un producto. Vacía la URL del producto, las páginas de categoría en las que aparece, la página de tienda y la portada si el producto aparece destacado en ella.
• Importaciones y sincronizaciones con el ERP. Haz que el proceso de importación lance purgas de URL mediante la API de tu CDN justo para los productos que ha cambiado, en lugar de esperar a que caduquen las páginas.
• Rebajas programadas. Un precio rebajado que empieza a medianoche no llega solo a una página cacheada. Programa una purga para ese momento.
• Cambios en toda la web. Después de actualizar el tema o lanzar una promoción para toda la tienda, vacíalo todo y luego precalienta tus categorías principales y los productos más vendidos.

Que la purga sea automática o no depende de tu configuración. En cualquier caso, revisa de vez en cuando las cabeceras de respuesta después de un cambio.

Notificaciones de pago y el firewall

Los proveedores de pago confirman los pagos llamando a tu tienda de servidor a servidor. La Payment Gateway API (en inglés) de WooCommerce las gestiona mediante URL wc-api, con la forma /wc-api/<callback>/ o /?wc-api=<callback>. Muchos plugins de pasarela registran además rutas de webhook bajo /wp-json/. Si una notificación falla, los pedidos se quedan en "pendiente de pago" aunque el cliente haya pagado.

Estas peticiones no se deben cachear nunca y, lo que es igual de importante, tampoco se deben bloquear nunca:

• Reglas por país. Los servidores de un proveedor pueden llamar desde un país que bloqueas o al que aplicas un desafío en toda la web.
• Desafíos CAPTCHA. Un servidor no puede resolver un CAPTCHA, así que limita las reglas de desafío a las rutas que usan las personas.
• Límites de peticiones. Los webhooks pueden llegar en ráfagas, por ejemplo tras una tanda de devoluciones. Ajusta los límites por IP en consecuencia.
• Reglas contra bots. Las notificaciones y las integraciones con el ERP son clientes automatizados. Comprueba que los conjuntos de reglas contra bots no los marcan.

Un plan de pruebas para el cambio

Hazlo en staging si puedes, y otra vez justo después del cambio de servidores de nombres (consulta cambiar los servidores de nombres sin caídas).

1. Ficha de producto como invitado. Pídela dos veces. La segunda respuesta debería ser un acierto de caché.
2. Carrito y checkout. Como invitado, deben mostrar bypass o miss, nunca hit.
3. Carrito activo. Añade un producto y recarga una ficha de producto. No debe ser un hit, y el mini carrito debe mostrar tu artículo.
4. Dos navegadores. Llena el carrito en el navegador A. El navegador B tiene que seguir viendo el carrito vacío.
5. Cliente con sesión iniciada. Navega por la tienda y el área de cuenta. Nada debería venir de la caché compartida.
6. Pago de prueba. Completa un pedido en el sandbox o el modo de prueba de la pasarela y confirma que el estado del pedido deja atrás "pendiente de pago". Eso demuestra que la notificación ha llegado.
7. Purga. Cambia un precio, vacía la URL y comprueba que aparece el precio nuevo.

Para comprobar las cabeceras, envía la petición una vez sin cookies y otra con una cookie de carrito:

curl -sI https://shop.example.com/product/example/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/product/example/ | grep -i cache

La segunda petición no debería devolver un hit. Cuando pasen las pruebas funcionales, compara la velocidad antes y después con una herramienta como corewebvitals.page, que muestra datos de campo de usuarios reales y una prueba de laboratorio para móvil y escritorio.

Cómo te ayuda fast.site

fast.site es un proxy de sitio completo que se coloca delante de tu hosting actual de WooCommerce. Mantienes tu proveedor, añades tu dominio en el panel y cambias tus servidores de nombres a fast.site. A partir de ahí, fast.site gestiona tu DNS, así que todos los registros existentes, incluidos los MX del correo de tu tienda, tienen que estar en la zona DNS de fast.site.

Fast Edge Cache™ sirve desde el edge las fichas de producto, las categorías y las páginas de contenido para invitados en las regiones incluidas en tu plan, y un cache HIT nunca llega a tu servidor. fast.site respeta las cabeceras Cache-Control de tu origen, y las respuestas privadas o dinámicas, como el carrito, el checkout y las sesiones iniciadas, muestran fs-cache: BYPASS, así que puedes verificar cada paso del plan de pruebas de arriba (consulta cómo comprobar la caché). Después de importaciones o cambios de precio, vacías URL concretas o todo el dominio desde el panel, con un registro de purgas, o mediante la API desde tus propios scripts.

En el edge, fast.site también convierte las imágenes de producto a WebP para los navegadores compatibles (AVIF según tu plan) y filtra las inundaciones HTTP y los bots maliciosos antes de que lleguen a tu tienda, con reglas de firewall que controlas tú. Tienes los detalles en la página de WooCommerce.

Mide tu tienda antes y después en tus propias páginas, incluido un pedido de prueba completo. Puedes empezar con una prueba gratuita de 7 días.

Preguntas frecuentes

¿Necesito un CDN para WooCommerce?

No todas las tiendas lo necesitan. Si la mayoría de tus clientes están cerca de tu servidor y las páginas ya son rápidas, un hosting mejor o un CDN de recursos pueden bastar. Un CDN de sitio completo compensa sobre todo con visitantes en varias regiones, picos de tráfico por campañas o un servidor que no da abasto.

¿Un CDN puede cachear las fichas de producto de WooCommerce?

Sí, para invitados. Las fichas de producto, las categorías y la página de tienda se pueden cachear siempre que las peticiones con cookies de carrito o de sesión de WooCommerce y los usuarios con sesión iniciada se salten la caché. Vacía las URL de producto cuando cambien el precio o el stock.

¿Un CDN romperá el checkout de WooCommerce?

No, si el carrito, el checkout, las páginas de cuenta, las peticiones wc-ajax, la Store API y las notificaciones de pago se saltan la caché y las reglas del firewall no los bloquean. Prueba un pedido completo con un pago en sandbox después de cada cambio de configuración.

¿Debo mantener mi plugin de caché si uso un CDN?

A menudo sí. Un plugin de caché de página acelera las peticiones que sí llegan a tu servidor, como los misses de caché. Asegúrate de que el plugin y el CDN coinciden en las exclusiones, y vacía los dos después de los cambios.