Antes de cambiar plugins, activar caché o invertir en publicidad, mide la home, las categorías, la ficha de producto, el carrito y el checkout por separado. Una mejora de solo 1 segundo en la carga puede reducir abandonos y hacer más rentable cada visita, especialmente en móvil.
La optimización de velocidad para tiendas WooCommerce no consiste solo en instalar un plugin de caché: hay que medir cada plantilla, excluir carrito y checkout de la caché y localizar los scripts, plugins o consultas que frenan la compra. Con métricas, waterfall y Query Monitor podrás priorizar cambios seguros que mejoren los Core Web Vitals sin poner en riesgo ventas ni pagos.
Mide cada plantilla antes de tocar ajustes
Registra una línea de salida por plantilla y sabrás qué arreglar primero. Abre una ventana privada del navegador, entra en PageSpeed Insights y analiza cinco URLs: home, una categoría con productos, un producto simple, el carrito y el checkout. Hazlo en móvil y escritorio, porque Google evalúa primero la experiencia móvil.
Guarda en una hoja los resultados de TTFB, LCP, INP y CLS. El TTFB es el tiempo que tarda el servidor en empezar a contestar; imagínalo como el tiempo que tarda un camarero en decir «ahora voy». LCP mide cuándo aparece el elemento visual principal, INP cuánto tarda la web en responder a un toque, y CLS indica si los elementos saltan mientras el cliente intenta pulsarlos.
Google considera buenos unos valores de campo de hasta 2,5 segundos para LCP, 200 milisegundos para INP y 0,1 para CLS. No persigas una nota de 100: busca que las cinco plantillas permitan comprar sin esperas, saltos ni botones muertos. Este primer registro tarda entre 15 y 25 minutos si ya tienes las URLs a mano.
Crea una hoja de control simple
Copia esta tabla en Google Sheets y rellénala antes de cambiar nada. Anota también la fecha, el dispositivo y si estabas con sesión iniciada, pues el carrito cambia la carga de la página.
| Plantilla | URL de prueba | Dato a vigilar | Prueba de compra |
|---|
| Home | Portada | LCP y peso del banner | No aplica |
| Categoría | Categoría con filtros | INP y filtros | Añadir un producto |
| Producto | Producto variable | LCP y variaciones | Elegir variación |
| Carrito y pago | /cart/ y /checkout/ | TTFB e INP | Cupón, envío y pago |
Separa laboratorio y clientes reales
PageSpeed Insights mezcla una prueba puntual con datos de usuarios reales cuando los tiene. Revisa también Google Search Console, en Experiencia y Core Web Vitals, para saber si el problema afecta a clientes de España durante los últimos 28 días, no solo a tu conexión.
El error más frecuente en este punto es medir solo la portada. Una home ligera puede ocultar una ficha de producto lenta por galería, recomendaciones, reseñas o variaciones; y el checkout puede ser más lento por impuestos, métodos de envío y Stripe o PayPal.
Prioriza cada hallazgo con una tabla sencilla de impacto, esfuerzo y riesgo. Da prioridad alta a una imagen LCP demasiado pesada, una consulta que ralentiza todas las fichas de producto o una caché de WooCommerce mal configurada; suelen afectar muchas visitas y tienen una solución comprobable. Deja para una segunda fase cambios con riesgo alto, como retrasar scripts de pago, sustituir el tema o modificar reglas de precios. Para cada tarea, registra la URL, el valor inicial de TTFB, LCP, INP y CLS, el cambio aplicado, el resultado tras la caché caliente y la prueba funcional realizada.
Revisa también pedidos, errores de pago y tasa de conversión durante varios días: una mejora técnica solo es válida si conserva la capacidad de vender.
Revisa home, categorías, producto y compra
Compara las cinco plantillas y convierte una nota confusa en tareas concretas. Abre cada URL en Chrome, pulsa F12, entra en la pestaña Network y recarga con la casilla “Disable cache” marcada. La cascada, o waterfall, muestra cada archivo como una barra de tiempo: permite ver quién llega tarde y quién bloquea al resto.
En la home, mira primero la imagen o vídeo que aparece arriba sin hacer scroll. En categorías, prueba filtros, orden y añadir al carrito. En producto, selecciona dos variaciones y cambia cantidad; en carrito aplica un cupón; en checkout cambia provincia y método de pago. Cada acción tarda entre 5 y 10 minutos, pero descubre fallos que PageSpeed no puede simular.
Tras más de 10 años trabajando en diseño web y marketing digital, he visto un caso real: una categoría con filtros cargaba rápido al abrirse, pero tardaba más de 3 segundos al filtrar en móvil; retirar un script de reseñas de esa plantilla redujo la espera sin tocar el checkout.
Examina la home y las categorías
Busca en la cascada imágenes de más de 300 KB en el primer bloque visible, vídeos que se descargan solos, fuentes duplicadas y sliders que cargan varias diapositivas aunque solo se vea una. Una imagen principal en WebP o AVIF, con ancho y alto definidos, evita parte del CLS y suele ayudar al LCP.
Prueba los filtros AJAX, es decir, filtros que cambian productos sin recargar toda la página. Si al pulsarlos aparece una petición larga a admin-ajax.php, anota el nombre del plugin de filtros. No desactives ese plugin todavía: primero confirma que esa llamada es lenta en dos categorías distintas.
Examina producto, carrito y checkout
El producto variable es la prueba más útil porque carga selección de atributos, stock y, a veces, precio dinámico. Comprueba que el botón de añadir sigue activo después de retrasar JavaScript, y que la foto y el precio cambian al elegir talla o color.
Carrito y checkout deben probarse con una ventana privada, un cupón válido y una dirección española. Añade un producto, cambia la cantidad, actualiza el envío, elige tarjeta con Stripe y PayPal si ambos están activos, y llega hasta la página de confirmación sin completar un pago real. Si usas bloques modernos de WooCommerce, pruébalos aparte de los shortcodes clásicos porque sus scripts no se comportan igual.
Orden seguro de revisión por plantilla
1. Home
banner y fuentes
2. Categoría
filtros y listado
3. Producto
galería y variantes
4. Carrito
cupón y envío
5. Checkout
pago y pedido
Mide primero, cambia una sola cosa y repite la misma prueba. Así separas una mejora real de una impresión visual.
Una tienda WooCommerce rápida se decide plantilla por plantilla: mejora primero el TTFB si el servidor tarda en responder, el LCP si tarda en verse el contenido principal, y el INP si filtros o botones responden tarde. Excluye carrito, checkout y mi cuenta de la caché de página, excepto cuando tu proveedor tenga reglas específicas para datos de sesión. Después de cada ajuste, repite una compra de prueba en móvil.
Localiza scripts, consultas y AJAX lentos
En Query Monitor, abre “Database Queries”, ordena por tiempo y revisa qué plugin, tema o función lanza las consultas más costosas. Una consulta SQL es una pregunta que WordPress hace a MySQL o MariaDB, como pedir los productos de una categoría; muchas preguntas repetidas hacen que el servidor se atasque como una caja con una sola persona atendiendo.
Mira también “HTTP API Calls” y “Scripts”. Una llamada externa lenta puede venir de un chat, un mapa, una herramienta de reseñas o un píxel publicitario. Si tarda entre 800 milisegundos y 2 segundos, no la borres sin más: valora cargarla tras consentimiento o solo en la página donde aporta una venta.
Encuentra el plugin responsable
Apunta el nombre del componente que sale en las consultas lentas y visita solo una plantilla afectada. Desactiva ese plugin en un entorno de pruebas o mediante un plugin de carga selectiva, vuelve a medir y verifica qué función desaparece. La forma rápida es desactivar plugins uno a uno en producción, pero no es segura cuando hay pedidos; la forma correcta usa una copia de pruebas y tarda entre 30 y 60 minutos.
Lo que omiten muchas guías es que un plugin no tiene que ser “pesado” en toda la web para ser un problema. Un buscador con filtros puede ser correcto en una categoría y disparar consultas innecesarias en el checkout; un constructor visual puede cargar su CSS en todas las fichas aunque solo se use en la home.
Revisa cart fragments y admin-ajax
Los fragmentos de carrito son pequeñas piezas de HTML que WooCommerce actualiza por AJAX, por ejemplo el contador de artículos del menú. Son útiles cuando el cliente añade productos sin recargar, pero cada visita puede generar peticiones extra a admin-ajax.php.
En Network, filtra por “Fetch/XHR” y recarga una página pública. Si ves get_refreshed_fragments en home o artículos y no necesitas un contador que cambie al instante, configura tu plugin de caché o tema para limitar esa carga fuera de tienda, categoría, producto y carrito. Hazlo solo si el contador sigue actualizándose al añadir un producto.
Una cascada lenta con barras largas antes de descargar archivos suele indicar TTFB o procesos PHP. Barras que empiezan tarde tras CSS o JavaScript suelen indicar bloqueo de renderizado o scripts que compiten por el navegador.
Los bloques de carrito y checkout de WooCommerce merecen una revisión separada de los shortcodes clásicos. En Network, filtra por Fetch/XHR y observa las peticiones a la Store API, habitualmente bajo rutas como /wp-json/wc/store/, al cambiar cantidades, cupones, dirección o envío. Una respuesta lenta puede deberse a cálculos de impuestos, reglas de envío, validaciones de plugins o llamadas externas, no solo a admin-ajax.php. Mantén la carga de scripts imprescindible para recalcular totales y procesar pagos, pero evita cargar extensiones de checkout en home, categorías o fichas si no las usan.
Tras cualquier descarga condicional, prueba el carrito de compra en móvil, un cupón, una dirección distinta y cada pasarela activa para confirmar que el rendimiento móvil mejora sin romper la compra.
Cachea lo público y excluye la compra
Activa caché de página en contenido público y protege las URLs con sesión. La caché de página guarda una copia preparada de una URL, como dejar los pedidos más repetidos ya empaquetados. Home, categorías, productos y entradas suelen poder servirse así a visitantes anónimos.
Excluye de la caché /cart/, /checkout/ y /my-account/, junto con sus subpáginas, endpoints de pago y URLs que tu pasarela indique. Revisa también que el sistema no cachee visitantes con las cookies woocommerce_items_in_cart, woocommerce_cart_hash o wp_woocommerce_session_; estas cookies indican que hay una sesión de compra activa.
WP Rocket funciona en muchos hostings con Apache o Nginx. LiteSpeed Cache tiene sentido si el servidor usa LiteSpeed, y Cloudflare puede acercar archivos estáticos al visitante mediante una CDN, una red de servidores repartidos. Elige una herramienta principal de caché: dos plugins con minificación o carga diferida activa suelen romperse entre sí.
Configura exclusiones y purgas
En el plugin elegido, abre el apartado “Never Cache URLs”, “Exclude URLs” o similar. Añade una línea por ruta: /cart/, /checkout/, /my-account/. Si tu tienda usa slugs traducidos, copia los que aparecen en Páginas de WordPress, no los ejemplos en inglés.
Activa la purga al actualizar un producto, precio o stock. La purga borra la copia guardada para que el siguiente visitante reciba información actual. No pulses “vaciar toda la caché” cada hora: puede provocar picos de servidor y hacer más lenta la tienda durante varios minutos.
Elige cada tipo de caché
| Tipo | Dónde ayuda | Tiempo habitual | Exclusión necesaria |
|---|
| Página | Home, categorías y productos | Ahorra entre 0,3 y 2 s si el TTFB era alto | Carrito, checkout y cuenta |
| Objetos con Redis | Consultas repetidas y sesiones | Mejora variable según catálogo | No sustituye reglas de sesión |
| CDN | Imágenes, CSS y JavaScript | Reduce latencia a distancia | No cachear HTML de pago sin reglas |
Reduce peso visual y JavaScript con pruebas
Aligera el primer bloque visible y conserva el código que hace posible cobrar. Convierte las imágenes de producto a WebP cuando sea posible y usa AVIF si tu sistema lo sirve bien. Sube una imagen con el tamaño cercano al que se verá: una foto de 2.500 píxeles para un recuadro de 500 píxeles obliga a descargar un camión para entregar una caja.
No apliques carga diferida, o lazy loading, a la imagen principal de home o producto. Esa imagen suele ser el LCP y debe cargarse pronto; aplica lazy loading a imágenes bajo el primer bloque visible, galerías secundarias y fotos de recomendaciones. Define ancho y alto para que el navegador reserve sitio y no mueva botones.
Minifica CSS y JavaScript con una sola herramienta. Minificar elimina espacios y comentarios, pero no arregla código lento. Retrasa solo scripts no esenciales, como un mapa, chat o widget social, y prueba después las variaciones, filtros, formularios y pagos.
Ordena CSS, fuentes y LCP
Activa CSS crítico si tu plugin lo genera, pero revisa en móvil que no aparezca texto sin estilo ni menús deformados. El CSS crítico es la porción mínima necesaria para pintar el primer trozo de página, como preparar primero el escaparate antes de ordenar el almacén.
Reduce familias y pesos de fuentes a uno o dos. Si el tema carga cuatro variantes de una tipografía y otra para iconos, la home puede pedir entre 6 y 10 archivos extra. Usa fuentes locales si tienes capacidad técnica, o mantén las actuales y elimina variantes que no se usan.
Controla etiquetas y servicios externos
Revisa Google Tag Manager, píxeles de anuncios, chat, reseñas, mapas y banners de consentimiento. Desactiva temporalmente un servicio en pruebas, mide y decide si su valor justifica el retraso. Cargar un mapa de Google solo al pulsar “ver mapa” suele ahorrar peticiones en contacto.
La mayoría de guías dicen “retrasa todo JavaScript”. Lo que no mencionan es que una tienda depende de scripts para validar campos, recalcular envío y crear el token de pago; retrasarlos puede dejar una página bonita que no acepta pedidos.
En un caso real, una tienda retrasó el script de su pasarela y el pago por tarjeta dejó de abrirse en Safari móvil; excluir ese archivo concreto conservó la mejora visual y devolvió el proceso de cobro.
Refuerza servidor, redis y tareas pendientes
Mejora el servidor cuando el TTFB siga alto después de limpiar el frontal. Un hosting compartido puede servir una tienda pequeña, pero un catálogo grande, campañas de pago o muchos pedidos simultáneos exigen más procesos PHP y base de datos. Si el TTFB supera de forma repetida entre 1 y 2 segundos en páginas no cacheadas, pide al proveedor sus registros de CPU, memoria y procesos PHP-FPM.
Comprueba en Herramientas, Salud del sitio, que PHP esté en una versión compatible y que OPcache esté activo. OPcache guarda código PHP ya preparado para no traducirlo desde cero en cada visita. Pregunta también si el plan ofrece HTTP/2 o HTTP/3 y compresión Brotli; son mejoras del transporte, no sustitutos de un buen servidor.
Redis es una caché de objetos: guarda resultados repetidos en memoria para evitar consultas iguales. Puede ayudar mucho cuando WooCommerce consulta stock, opciones y datos de sesión, pero requiere memoria y una configuración correcta. No compres un VPS solo por Redis si la tienda recibe poco tráfico y carga bien.
Configura redis con apoyo del hosting
Pregunta al soporte si Redis está incluido y solicita estos tres datos: host, puerto y si requiere contraseña. Instala el plugin “Redis Object Cache”, actívalo y pulsa “Enable Object Cache” solo después de tener esos datos. Comprueba en su pantalla de estado que aparezca conectado, luego prueba producto, carrito y checkout.
Redis ayuda cuando hay consultas repetidas, pero no arregla una imagen de 2 MB ni un script externo lento. En tiendas con catálogo o pedidos elevados, su efecto puede notarse entre cargas repetidas y picos de tráfico; en una tienda pequeña puede ser casi imperceptible.
Limpia action scheduler sin borrar ventas
WooCommerce usa Action Scheduler para tareas como emails, renovaciones, sincronizaciones y trabajos de plugins. Ve a WooCommerce, Estado, Acciones programadas, filtra por “fallida” y “pendiente”, y mira qué gancho se repite. No borres acciones pendientes relacionadas con suscripciones, pagos o envíos sin saber qué plugin las creó.
Limpia transients caducados desde WooCommerce, Estado, Herramientas, y crea antes una copia de seguridad verificable. Programa estas tareas en horas de menor venta, por ejemplo de madrugada, porque limpiar tablas grandes puede tardar entre 10 y 40 minutos según el hosting. Corrige primero las tareas fallidas recurrentes y confirma con el hosting que WP-Cron o un cron real se ejecutan con regularidad: Redis y OPcache reducen trabajo repetido, pero no resuelven una cola bloqueada.
Valida la compra antes de publicar cambios
Repite un pedido completo y confirma que la mejora no ha roto ninguna venta. Haz las pruebas en móvil real y escritorio, con sesión cerrada y abierta. Crea un pedido de prueba con producto simple, uno variable, una unidad sin stock y un cupón; comprueba que cada mensaje se muestra donde debe.
Revisa que el foco del teclado llegue a todos los campos y botones, que los errores de dirección se lean y que el botón de pagar no salte de sitio. Estas comprobaciones siguen el sentido práctico de las Web Content Accessibility Guidelines (WCAG): una compra rápida no sirve si una persona no puede completar el formulario.
Guarda la comparación antes y después en la misma hoja. Si el LCP baja pero aumentan los errores de pago, revierte el cambio. Una reducción de entre 0,5 y 1,5 segundos en una plantilla de producto puede ayudar a la experiencia, pero no permite prometer una subida concreta de ventas.
Sigue este orden de publicación
Primero aplica el ajuste en una copia de pruebas. Segundo, borra solo la caché relacionada y prueba el recorrido completo. Tercero, pasa el cambio a producción en una hora tranquila, repite el pedido de prueba y observa los pedidos reales durante las siguientes 24 horas.
Un caso habitual: se activa minificación en producción, el selector de provincia deja de recalcular el envío y el fallo se detecta al día siguiente. Separar cambios y probar dirección, envío y pago evita buscar después cuál de cinco ajustes causó el problema.
Decide por impacto, esfuerzo y riesgo
Prioriza primero imágenes LCP grandes, caché pública bien excluida y scripts externos innecesarios: suelen tener impacto alto y riesgo bajo o medio. Deja para después Redis, cambios de tema o sustitución de hosting, porque requieren más coordinación aunque puedan resolver un TTFB persistente.
No confundas rapidez visual con compra rápida. La decisión correcta es la que mejora una plantilla medida y mantiene stock, precio, impuesto, cupón y pago correctos durante una transacción completa.
Resuelve tus dudas
¿Cómo acelero una tienda WooCommerce?
Mide home, categoría, producto, carrito y checkout en móvil antes de cambiar nada. Cachea páginas públicas, excluye compra y corrige primero el recurso que empeora TTFB, LCP, INP o CLS.
¿Qué páginas no debo cachear en WooCommerce?
No cachees /cart/, /checkout/ ni /my-account/, ni sus subrutas y endpoints de pago. Excluye también sesiones identificadas por cookies de WooCommerce para evitar precios o pedidos incorrectos.
¿WP Rocket o LiteSpeed Cache para WooCommerce?
WP Rocket encaja en muchos servidores Apache o Nginx, mientras LiteSpeed Cache aprovecha mejor un servidor LiteSpeed. Usa solo uno para caché, minificación y lazy loading, y prueba carrito y pago tras configurarlo.
¿Por qué mi WooCommerce es lento solo al pagar?
El checkout consulta sesión, impuestos, envío y pasarelas, por eso no se beneficia igual de la caché de página. Revisa TTFB, llamadas AJAX, métodos de envío, plugins de pago y consultas con Query Monitor.
¿Redis acelera cualquier tienda WooCommerce?
Redis ayuda sobre todo con consultas repetidas, catálogos grandes o tráfico concurrente. No mejora por sí solo una home con imágenes pesadas, un servidor saturado o JavaScript bloqueante.
¿Cuánto cuesta mejorar la velocidad de WooCommerce?
El coste puede ir desde 0 euros si corriges imágenes y ajustes existentes, hasta cuotas mensuales de hosting, CDN o Redis. Depende del tráfico, catálogo, tema y del tiempo técnico necesario para probar el checkout sin riesgos.
Mantén la tienda rápida sin poner ventas en riesgo
Conserva una sola herramienta principal de caché, imágenes ajustadas, scripts externos bajo control y tareas programadas vigiladas. Si el TTFB no baja tras estos pasos, trata el hosting como la siguiente decisión, no como un detalle menor.
La velocidad que más protege la tasa de conversión es la que permite ver un producto, elegirlo y pagarlo sin dudas. Mide, cambia una sola cosa, prueba la compra y conserva solo aquello que haga más fácil vender.
⚠️ Antes de actualizar WooCommerce, WordPress o una pasarela, crea una copia de seguridad y prueba el pedido en un entorno de pruebas cuando sea posible.
