Caso de estudio anonimizado

Recuperación confidencial de rendimiento WooCommerce

Esta recuperación WooCommerce B2B anonimizada en la UE (más de 12 000 SKUs) corrigió el lag del checkout móvil sin rebuild. El cliente no puede nombrarse; las correcciones y métricas de abajo son reales.

Restricción inicial

La tienda tenía una forma familiar de WooCommerce: catálogo operativo, un checkout que no podía romperse, varios scripts de marketing, un tema con años de overrides y Core Web Vitals móviles en rojo en plantillas clave.

El riesgo comercial era concreto. Cualquier optimización que tocara carrito, pago, stock, impuestos o sesión debía pasar por staging, medición y rollback.

Diagnóstico

El primer paso separó familias de plantillas: homepage, categoría, producto, carrito, checkout y contenido. Cada familia tenía límites de rendimiento distintos, así que una puntuación única habría ocultado los cuellos de botella reales.

Los costes más altos se acumulaban: scripts de terceros demasiado pronto, CSS sin usar, deriva de tamaño de imágenes, fallos de caché en páginas que podían cachearse con seguridad, y wc-ajax=get_refreshed_fragments sin caché en cada carga que bajo carga inundaba el pool PHP-FPM.

Decisión de arquitectura

El proyecto no empezó con un rewrite. La primera decisión fue proteger la corrección del checkout y solo después mover superficies seguras hacia un caché más fuerte y un render más ligero.

Cloudflare gestionó reglas de edge, límites de caché, redirecciones, filtrado de bots y observabilidad. WordPress y WooCommerce siguieron siendo la fuente comercial de verdad. Los cambios de frontend se acotaron por familia de plantilla, no como una limpieza genérica del tema.

Modelo de entrega

El trabajo se entregó en lotes cortos: baseline, auditoría de scripts, correcciones de imagen y layout, política de caché, aislamiento del checkout, validación en staging, despliegue en producción y medición posterior.

Cada lote tenía ruta de rollback. Eso importa más que un lanzamiento espectacular cuando los ingresos atraviesan el mismo checkout que se está optimizando.

Bandas de resultado

Medición 30 días después del despliegue en la tienda B2B confidencial de la UE: LCP 5,4s a 1,8s (-66%), TTFB de checkout 2,1s a 0,4s (-80%), bloqueo del main-thread 1.200ms a 180ms (-85%), abandono carrito-a-checkout 42% a 34% (-19%).

La lección reutilizable: recuperar rendimiento en WooCommerce no es perseguir una puntuación perfecta, sino fijar bien el límite entre páginas comerciales cacheables y flujos transaccionales en vivo.

Descarga el diagnóstico de latencia de checkout

Usa la misma hoja de medición del diagnóstico de arriba. Las filas de referencia reutilizan las métricas anonimizadas publicadas; las filas en blanco son para la baseline de tu tienda.

Preguntas frecuentes

¿Cómo corregir el lag del checkout WooCommerce en móvil sin reconstruir la tienda?

Empieza midiendo carrito, checkout y plantillas de producto, no con un rewrite. En una tienda B2B confidencial de la UE (más de 12 000 SKUs) corregimos el lag móvil podando más de 450 000 filas autoload en wp_options, cortando wc-ajax=get_refreshed_fragments en cada carga, moviendo más de 25 píxeles a Cloudflare Zaraz y añadiendo Redis sin grupos de checkout. El TTFB de checkout bajó de 2,1s a 0,4s y el LCP de 5,4s a 1,8s; cada lote tuvo staging y rollback si los pagos se desviaban.

¿Qué provoca cart fragments WooCommerce lentos bajo tráfico alto?

El mini-cart por defecto dispara wc-ajax=get_refreshed_fragments sin caché en cada carga. Bajo tráfico concurrente esos AJAX inundan el pool PHP-FPM, encolan conexiones a la base de datos y añaden latencia antes de que arranque el checkout. Aquí el bloat de wp_options (2,1 GB, más de 450 000 filas autoload) agravó el retraso. Fix: desactivar la actualización automática de fragmentos, actualizar el estado del carrito solo tras add-to-cart (usamos sessionStorage) y limpiar el autoload.

¿Cómo reducir la latencia del checkout WooCommerce sin romper pagos?

Trata el checkout como no cacheable y aíslalo antes de afinar el catálogo. Usa Redis para transients y output de queries, pero excluye grupos de session y checkout para que impuestos, stock y precios ERP sigan exactos. Mueve scripts de marketing al edge (Cloudflare Zaraz). Entrega en lotes pequeños con staging y rollback; nunca cachees páginas con cookies de sesión. Resultado medido: TTFB de checkout 2,1s a 0,4s con pagos B2B estables.

¿Por qué no se nombra al cliente?

El contrato impide nombrar en público, capturas, detalles de tráfico y algunos identificadores comerciales. Los deltas de rendimiento medidos y el método de ingeniería son publicables y están documentados arriba.

¿Quieres el mismo diagnóstico para tu tienda?

Envía el stack actual, las plantillas más lentas y la restricción de negocio. Te diré si el primer paso correcto es recuperación, migración headless o una auditoría más pequeña.

Pedir auditoría técnica