Cómo acelerar una tienda WooCommerce sin romper el carrito

Una tienda lenta pierde ventas dos veces: una en la ficha de producto, cuando el visitante se va antes de que cargue, y otra en el pago, cuando un carrito roto o un campo de pago congelado lo echa. La mayoría de los consejos de rendimiento tratan una tienda como un blog. Así es exactamente como los carritos acaban vacíos, los precios acaban mal y los botones de pago dejan de responder.

Esta guía es el mapa. Muestra lo que se puede optimizar en una tienda, lo que nunca debe tocarse, y enlaza con la guía detallada de cada problema.

Una tienda son dos sitios en uno

El catálogo es la página de inicio, las páginas de categoría y las fichas de producto. Todos los visitantes ven lo mismo, así que estas páginas se pueden cachear, recortar y diferir como cualquier otra página.

La transacción es el carrito, la página de pago y la cuenta del cliente. Cada visitante ve su propio contenido: sus artículos, su dirección, sus pedidos. Estas páginas nunca deben servirse desde una caché, y las optimizaciones que se basan en una instantánea de la página no se les aplican.

Y entre ambos hay un tercer estado: un visitante que navega por el catálogo con artículos en el carrito. La página parece pública, pero la cabecera muestra su carrito. WooCommerce marca a ese visitante con cookies como woocommerce_items_in_cart y wp_woocommerce_session_, y una caché de página bien configurada se aparta para él.

Una caché de página que respeta el carrito

Una caché de página es la mayor ganancia en una tienda, y el ajuste más peligroso. Tres reglas:

• Excluya las páginas transaccionales: carrito, página de pago y todas las páginas de mi cuenta. Servir una página de pago cacheada puede mostrar a un cliente los datos de otro.
• Sáltese la caché para los visitantes con carrito o sesión: si no, la cabecera muestra un carrito vacío a alguien que acaba de añadir un producto, o el contador del carrito de otro visitante.
• Vigile las query strings: enlaces add-to-cart, parámetros de seguimiento como utm_source o gclid, y filtros. Cada URL distinta puede convertirse en un fallo de caché.

La trampa de la geolocalización. La opción de WooCommerce «Geolocalizar (con soporte para caché de página)» añade un parámetro v a las URL para que cada país tenga su propia versión en caché. Si no necesita precios o impuestos por país, este modo fragmenta su caché para nada. Si lo necesita, sepa que cada página del catálogo existe ahora en tantas versiones como ubicaciones haya.

Cookies puestas para nada. Un visitante nuevo con el carrito vacío no debería recibir ninguna cookie en una página del catálogo. Basta una sola cabecera Set-Cookie para que la mayoría de los CDN, Cloudflare incluido, se nieguen a cachear la página, y para que muchas cachés de página se aparten. Los culpables habituales: un plugin que inicia una sesión de WooCommerce para cada visitante (listas de deseos, selectores de moneda, productos vistos recientemente), o una cookie de contador del carrito que se escribe incluso cuando el carrito está vacío. Compruébelo como visitante nuevo:

# Una página del catálogo, como visitante nuevo con el carrito vacío: no debe salir ninguna línea.
curl -s -o /dev/null -D - https://your-store.com/product/any-product/ | grep -i "set-cookie"

Si vuelve una cookie, busque el plugin que la pone y haga que espere a que el visitante añada de verdad algo al carrito.

Cart fragments: la petición en cada página

El minicarrito de la cabecera se mantiene al día mediante una petición AJAX, wc-ajax=get_refreshed_fragments, enviada por wc-cart-fragments.js. Nunca se cachea, así que llega a PHP y a la base de datos en cada vista de página donde se ejecuta.

Desde WooCommerce 7.8, el script ya no se carga por defecto en todas las páginas: solo donde lo necesita el widget clásico de minicarrito. Muchos temas lo siguen cargando en todas partes. Revise la pestaña Network de una página del catálogo: si la petición se lanza en páginas sin minicarrito, limítela a las páginas que lo tienen. No la elimine sin más donde existe el minicarrito, o el contador del carrito dejará de actualizarse.

Cuando las optimizaciones hacen que el minicarrito desaparezca o deje de abrirse, la causa y la solución se detallan en nuestra guía sobre el minicarrito de WooCommerce.

Imágenes de producto: la parte más pesada del catálogo

• Miniaturas en las cuadrículas de categoría: WooCommerce genera varios tamaños; el navegador solo elige el correcto si el atributo sizes coincide con la cuadrícula. Un sizes incorrecto hace que los móviles descarguen miniaturas de escritorio. Consulte nuestra guía sobre srcset y sizes.
• Una prioridad mal colocada: desde WordPress 6.3, la primera imagen grande de una página recibe fetchpriority="high". En una página de inicio o de categoría, suele ser la primera miniatura de producto de una cuadrícula muy por debajo de la primera pantalla, que entonces compite con la verdadera imagen principal.
• La imagen principal del producto suele ser el Largest Contentful Paint de una ficha de producto. No debe cargarse con lazy loading, y puede ser distinta en móvil y en escritorio: nuestra guía sobre la imagen LCP por dispositivo explica cómo precargar la correcta.
• Los scripts de galería, zoom y lightbox se cargan en cada ficha de producto. Son buenos candidatos para un retraso, siempre que el botón «añadir al carrito» y los selectores de variación sigan funcionando.

CSS y JavaScript sin romper la tienda

CSS recortado. Las herramientas de CSS usado renderizan un único estado de la página. En una tienda, muchos elementos solo aparecen tras una acción: el minicarrito abierto, una variación seleccionada, un error de cantidad, un campo de cupón. Sus estilos se eliminan. Cómo encontrar y restaurar las reglas que faltan se explica en nuestra guía sobre los estilos que faltan. Y en las páginas de carrito, pago y mi cuenta, no recorte el CSS en absoluto: la instantánea se toma sin sesión iniciada, con el carrito vacío, y se pierde todo lo que ve el cliente.

JavaScript retrasado. No retrase nunca el botón «añadir al carrito», los scripts de variaciones, los scripts de la página de pago ni los campos de pago (formularios de tarjeta, botones de monedero): un campo de pago que espera una primera interacción es un pedido perdido. Retrase lo que no hace falta para comprar: chat, widgets de reseñas, pop-ups, píxeles de marketing. El método para encontrar lo que ha roto un retraso está en nuestra guía sobre el retraso de JavaScript, y un banner de consentimiento que carga tarde se trata en nuestra guía sobre los banners de consentimiento.

Desplazamientos de diseño. Las cuadrículas de productos que cargan sus imágenes sin dimensiones, las etiquetas de oferta y las estrellas de valoración que aparecen tarde, y las barras fijas de «añadir al carrito» mueven la página. Las causas y las soluciones están en nuestra guía sobre el CLS.

Las páginas que nunca se cachean

El carrito y la página de pago siempre los genera PHP para cada visitante, así que su velocidad es la velocidad bruta de su servidor y su base de datos. Ahí es donde se notan el alojamiento, la versión de PHP y la salud de la base de datos. Algunos puntos que revisar:

• Las versiones recientes de WooCommerce guardan los pedidos en tablas dedicadas (High-Performance Order Storage), mucho más rápidas que el antiguo almacenamiento basado en entradas en tiendas con muchos pedidos.
• Las tablas de acciones programadas y las sesiones de cliente caducadas pueden crecer mucho en una tienda con mucho tráfico; revise su tamaño y su limpieza.
• Cada plugin que se engancha al carrito o a la página de pago se ejecuta en cada una de estas peticiones: calculadoras de envío, ventas adicionales, controles antifraude. Mida la página de pago con y sin ellos en una copia de staging.

Medir la tienda, no solo la página de inicio

• Pruebe una página de categoría y una ficha de producto en móvil, sin sesión iniciada, como visitante nuevo.
• Vuelva a probar con un artículo en el carrito: la caché debería apartarse y la página debería seguir siendo rápida.
• Recorra todo el proceso de compra después de cada cambio: añadir al carrito, cambiar una variación, aplicar un cupón, llegar al paso de pago. Hágalo en una copia de staging o en el modo de prueba de su pasarela de pago: un pedido de prueba en una tienda en producción es un pedido real.
• Lea los datos de campo, no solo la puntuación de laboratorio, como se explica en nuestra guía sobre datos de laboratorio y de campo, y cambie un solo ajuste cada vez, como en nuestro método para optimizar sin romper nada.

Con Mantys Core

En resumen

• Trace primero la línea: el catálogo se optimiza a fondo; el carrito, el pago y mi cuenta nunca se cachean ni se recortan.
• Sáltese la caché de página para los visitantes con carrito, y vigile las query strings y la geolocalización.
• Un carrito vacío no debe recibir ninguna cookie: basta un solo Set-Cookie para que el CDN deje de cachear la página.
• Cargue los cart fragments solo donde un minicarrito activo los necesite.
• Ajuste el tamaño de las imágenes de producto, cargue la imagen principal de inmediato y corrija la prioridad de las miniaturas de la cuadrícula.
• No retrase nunca los scripts de «añadir al carrito», de variaciones, de checkout ni de pago; retrase en su lugar la capa de marketing.
• Pruebe todo el proceso de compra, en staging o en modo de prueba, después de cada cambio.