Respuesta corta: la velocidad no es una métrica técnica, sino un multiplicador de todo el embudo. Actúa a la vez sobre la conversión, las posiciones en buscadores y el precio del clic de pago. Es la única mejora que no se puede hacer «solo para un canal»: funciona en todas partes a la vez.
Qué mide exactamente Google
Desde 2020 existen tres métricas que Google recoge de usuarios reales de su web, no en un laboratorio. Se llaman Core Web Vitals y los umbrales son estos:
| Métrica | Qué significa en cristiano | Umbral «bueno» |
|---|---|---|
| LCP | Cuándo aparece el bloque principal de la página: la foto del producto, el titular | hasta 2,5 s |
| INP | Con qué rapidez reacciona la página a los clics | hasta 200 ms |
| CLS | Cuánto salta el contenido durante la carga | hasta 0,1 |
Un detalle que se escapa con regularidad: cuenta el percentil 75. No basta con que «en mi portátil se abre rápido»: tres cuartas partes de las visitas reales, incluidos los Android viejos con datos móviles, deben entrar dentro del umbral.
En las tiendas WordPress, lo que más suele fallar es INP: la página llega a dibujarse, pero durante otro segundo no reacciona a los clics, porque en segundo plano siguen trabajando los scripts de plugins, del chat, de los píxeles y del carrito. El usuario no lo lee como «web lenta», sino como «la web se ha roto», y se va.
Cuánto cuesta en dinero
La ilustración pública más honesta es el caso de estudio de Vodafone en web.dev: una prueba A/B con dos versiones visualmente idénticas de la página mostró que mejorar el LCP un 31 % dio un 8 % más de ventas. Sin rediseño, sin una nueva promoción: solo velocidad.
Traslade esto a sus propias cifras igual que en el primer tema: si la tienda factura 40.000 € al mes, el 8 % son 3.200 € cada mes. El trabajo de velocidad es puntual.
Hay además un segundo efecto que rara vez se cuenta: la velocidad cambia el coste de la publicidad. Una página de destino lenta empeora el nivel de calidad en los sistemas publicitarios y encarece el clic. Paga doble: llegan menos personas y cada llegada ha costado más.
Por qué se ralentiza precisamente WooCommerce
WooCommerce en sí no es lento. Lo hace lento la construcción típica que lo rodea. Según mis auditorías, el orden de los culpables es casi siempre este:
- Un tema con constructor. Un tema multiuso con un builder visual arrastra decenas de archivos CSS y JS en cada página, incluidos los que solo hacen falta en la portada. Es la causa más frecuente y más infravalorada.
- Plugins que se cargan en todas partes. El plugin de slider, de formulario, de opiniones y de calculadora de envío registran sus scripts en toda la tienda, no solo donde se usan.
- Sin caché de páginas. Cada visita a una categoría es un ciclo completo de PHP más consultas a la base de datos. En un alojamiento compartido de 5 €/mes son 1,5–3 segundos hasta el primer byte.
- Fragmentos del carrito. WooCommerce lanza por defecto
wc-ajax=get_refreshed_fragmentsen cada página para actualizar el contador del carrito. En una página por lo demás cacheada, es la única petición no cacheable que bloquea al resto. - Fotos en su tamaño original. El fotógrafo entregó JPEG de 4000 px de 3 MB y se subieron sin cambios. El navegador descarga 3 MB para mostrar una imagen de 600 px de ancho.
- Scripts externos. Chat, píxeles, mapas, widgets de opiniones. Cada uno parece inocente; juntos se comen el INP.
Qué arreglar por orden de retorno
El orden importa: primero lo más barato y eficaz:
- Fotos: conversión a WebP/AVIF, servir el tamaño correcto, carga diferida de todo lo que está por debajo de la primera pantalla, pero no de la foto principal del producto (eso estropea el LCP)
- Caché de páginas + object cache: caché estática de categorías y fichas de producto, Redis o Memcached para las consultas a la base de datos
- Desactivar los fragmentos del carrito donde no hacen falta, o sustituirlos por una actualización ligera del contador
- Revisión de plugins: eliminar los que no se usan, limitar la carga de scripts a las páginas que de verdad los necesitan
- Aplazar los scripts externos: cargar el chat y los píxeles tras la interacción, y no en
<head> - Fuentes: alojamiento propio,
font-display: swap, solo las variantes que se usan - Alojamiento: si tras todo esto el TTFB sigue superando los 600 ms, el problema está en el hardware, no en el código
Los tres primeros puntos dan normalmente el 70 % del efecto y llevan unos días. Los detalles técnicos de cada uno están en la guía vecina: Core Web Vitals, imágenes, fuentes y scripts y caché.
Apunte para el programador
- Active HPOS. High-Performance Order Storage traslada los pedidos de
wp_posts/wp_postmetaa tablas dedicadas. En una tienda con decenas de miles de pedidos cambia tanto el panel como cada consulta de pedidos. - Mida datos de campo, no de laboratorio. El modo de laboratorio de PageSpeed Insights es cómodo para depurar, pero la valoración sale de los datos de campo de CrUX. El informe de Core Web Vitals de Search Console dice la verdad.
- Busque tareas largas, no el «peso de la página». El INP lo matan manejadores concretos: el repintado del carrito, el script del slider, el código de analítica síncrono. Perfile la pestaña Performance en lugar de contar kilobytes.
- Revise las opciones autoload.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes': si son megabytes, cada petición arrastra ese lastre. Suelen ser restos de plugins eliminados. - Verifique con un perfil móvil con limitación de red y de CPU. En su MacBook siempre va rápido.
Cuándo optimizar el tema deja de ayudar
Hay un límite más allá del cual ya no queda nada que mejorar: el tema y los plugins imponen un mínimo de trabajo que no se puede eliminar sin romper la tienda. Síntomas de que lo ha alcanzado:
- El LCP móvil se ha atascado en 3–4 segundos aunque las fotos y la caché ya están hechas
- Cada plugin nuevo empeora claramente las métricas
- Tiene que elegir entre «rápido» y «tiene las funciones necesarias»
En este punto quedan dos caminos. El primero es recortar funcionalidad: renunciar al builder, reescribir plantillas, eliminar parte de los plugins. El segundo es separar la web y el backend: dejar WooCommerce para productos, pedidos y el panel, y construir el frontend aparte sobre una pila rápida. Cómo funciona y cuándo compensa lo describe la página WooCommerce y headless, incluida una descripción honesta de cuándo no compensa. Una solución ya lista de este tipo es NextWoo, una web en Next.js sobre el WooCommerce existente.
Prueba práctica
- He abierto el informe de Core Web Vitals en Google Search Console y he mirado las direcciones móviles
- Conozco el LCP, el INP y el CLS a partir de datos de campo, y no solo de la prueba de laboratorio
- He comprobado el peso de la foto principal del producto: menos de 150–200 KB
- He comprobado el TTFB en la página de categoría: menos de 600 ms
- He desactivado o limitado los fragmentos del carrito
- He revisado la lista de plugins: cada uno es necesario o está eliminado
- He calculado cuánto vale en mi dinero un 8 % más de ventas
Qué sigue
Una tienda rápida es una condición, no un motivo de compra. A continuación el visitante llega a la ficha de producto y decide si confía en usted lo bastante como para entregar su dinero: ficha de producto que vende.
Si quiere delegarlo: aceleración de la web: auditoría, lista de trabajos por prioridad y precio cerrado por la implantación.