De 40 a 98 PageSpeed: cómo transformé una tienda WooCommerce

Cada segundo cuenta en el e-commerce. Para una tienda WooCommerce que procesa miles de pedidos al mes, eso se traduce directamente en ingresos perdidos. Este caso de estudio documenta cómo, en WPPoland, transformé una tienda europea de muebles e-commerce en dificultades, de una puntuación PageSpeed de 40 a 98 - y lo que eso significo para sus resultados financieros.

#Tienda de muebles con WooCommerce en Europa

Mi cliente opera una tienda de muebles online de tamaño medio que atiende a clientes en Europa Central y Occidental. Con un catálogo de más de 3.500 productos y 12.000 imágenes de productos, había mucho en juego. Su tienda WooCommerce había crecido orgánicamente durante cinco años, acumulando deuda técnica con cada instalación de plugin, personalización de tema e integración de terceros.

A principios de 2026, la tienda estaba perdiendo ingresos. Competidores con sitios más rápidos los estaban superando en los resultados de búsqueda, y los usuarios móviles - que representaban el 64 por ciento de su tráfico - estaban abandonando el sitio en masa.

#Por qué la tienda WooCommerce era lenta

Cuando audité el sitio por primera vez, encontré un patrón familiar pero grave de degradación de rendimiento:

• 38 plugins activos, muchos con funcionalidad superpuesta
• Hosting compartido sin cache a nivel de servidor
• Base de datos no optimizada con más de 2,3 millones de transients expirados
• 12.000 imágenes de productos servidas como archivos PNG y JPEG sin comprimir
• Sin CDN - todos los recursos servidos desde un único servidor de origen en Alemania
• JavaScript bloqueador de renderizacion de 14 plugins cargados en cada página
• Proceso de checkout de 5 pasos con 22 campos de formulario

El resultado era un sitio que se sentía roto en móvil. Las páginas tardaban 8 segundos en cargar, el diseño saltaba mientras los elementos se renderizaban, y el proceso de checkout era tan engorroso que el 68 por ciento de los visitantes abandonaba el sitio antes de completar una compra.

#Métricas de WooCommerce antes de la optimización

#Cómo acelerar WooCommerce en 7 fases

Seguí un enfoque sistemático y basado en datos para la optimización de velocidad WordPress. Cada fase se construye sobre la anterior, y medí el impacto de cada cambio de forma aislada antes de pasar a la siguiente.

#Fase 1: Auditoría técnica (días 1-3)

Antes de tocar una sola línea de código, pasé tres días analizando cada aspecto del sitio:

• Análisis GTmetrix Waterfall para identificar las cadenas de peticiones más largas
• Pruebas WebPageTest multi-ubicación desde Frankfurt, Londres y Varsovia
• Chrome DevTools Performance Panel para analizar la actividad del hilo principal
• Registro de consultas a base de datos con el plugin Query Monitor para encontrar consultas lentas
• Análisis de plugins para medir el impacto de cada plugin en el tiempo de carga

La auditoría revelo que el 73 por ciento del tiempo de carga era atribuible a tres factores: imágenes no optimizadas (31 por ciento), JavaScript excesivo (26 por ciento) y consultas lentas a la base de datos (16 por ciento).

#Fase 2: Optimización del servidor (días 4-7)

La base de cualquier sitio web rápido es el servidor. Migré al cliente de hosting compartido a un VPS dedicado con el siguiente stack:

• Servidor Web LiteSpeed con soporte HTTP/3 y QUIC
• Redis Object Cache para caching persistente de objetos WordPress
• MariaDB 11.4 con configuración my.cnf optimizada
• PHP 8.3 con preloading de OPcache habilitado

La configuración de LiteSpeed incluyo ajustes específicos para WooCommerce:

# Reglas de cache LiteSpeed para WooCommerce
<IfModule LiteSpeed>
  CacheLookup on
  RewriteRule .* - [E=Cache-Control:no-autoflush]
  RewriteRule ^/cart.* - [E=Cache-Control:no-cache]
  RewriteRule ^/checkout.* - [E=Cache-Control:no-cache]
  RewriteRule ^/my-account.* - [E=Cache-Control:no-cache]
</IfModule>

La configuración de Redis fue ajustada para el manejo de sesiones WooCommerce:

// Adiciones a wp-config.php para Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFIX', 'wc_store_');
define('WP_REDIS_SELECTIVE_FLUSH', true);

Impacto después de la Fase 2: TTFB bajo de 2,4 segundos a 180 milisegundos.

#Fase 3: Limpieza de base de datos (días 8-11)

Cinco años de operación habían dejado la base de datos en estado crítico. Realicé una limpieza metódica:

1. Eliminación de 2,3 millones de transients expirados - la tabla wp_options había crecido a 847 MB
2. Optimización de 47 consultas lentas identificadas durante la fase de auditoría
3. Adición de índices faltantes en las tablas wp_postmeta y wp_wc_order_stats
4. Limpieza de post meta huerfaños - 340.000 filas de metadatos de productos eliminados
5. Conversión de tablas a InnoDB donde aun se usaba MyISAM

Los índices personalizados mejoraron significativamente la búsqueda y filtración de productos:

-- Indices personalizados para consultas de productos WooCommerce
ALTER TABLE wp_postmeta ADD INDEX idx_meta_lookup (meta_key, meta_value(32));
ALTER TABLE wp_wc_product_meta_lookup ADD INDEX idx_price_stock (min_price, max_price, stock_status);
ALTER TABLE wp_woocommerce_order_items ADD INDEX idx_order_type (order_id, order_item_type);

Impacto después de la Fase 3: El tiempo de consulta a la base de datos bajo un 84 por ciento, y la tabla wp_options se redujo de 847 MB a 12 MB.

#Fase 4: Optimización de imágenes (días 12-15)

Con 12.000 imágenes de productos, esta fase tuvo el mayor impacto individual en el peso de la página:

• Conversión de todas las imágenes a AVIF con fallback WebP para navegadores antiguos
• Implementación de srcset responsivo con breakpoints en 320, 640, 960, 1.280 y 1.920 píxeles
• Adición de lazy loading con loading="lazy" nativo para todas las imágenes debajo del pliegue
• Definición de dimensiones explícitas en cada etiqueta <img> para eliminar CLS de la carga de imágenes
• Implementación de placeholders blur-up usando Low Quality Image Placeholders (LQIP)

El pipeline de procesamiento de imágenes se automatizó con dos filtros de WordPress y WP-CLI:

// Salida AVIF para los tamaños de imagen generados (WordPress 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/avif';
    $formats['image/png'] = 'image/avif';
    return $formats;
});

// Calidad AVIF 75, el resto de formatos sin cambios
add_filter('wp_editor_set_quality', function ($quality, $mime_type) {
    return 'image/avif' === $mime_type ? 75 : $quality;
}, 10, 2);

wp media regenerate --yes

Impacto después de la Fase 4: El peso medio de la página bajo de 6,8 MB a 1,2 MB. El LCP mejoro de 5,1 segundos (después de la optimización del servidor) a 1,4 segundos.

#Fase 5: Auditoría JavaScript (días 16-19)

La auditoría JavaScript fue quirúrgica. Clasifiqué cada script en el sitio:

Para los scripts de análisis, implementé un patrón de carga diferida:

// Diferir scripts no críticos hasta la interaccion del usuario
const loadDeferredScripts = () => {
  const scripts = document.querySelectorAll('script[data-defer-src]');
  scripts.forEach(script => {
    const newScript = document.createElement('script');
    newScript.src = script.dataset.deferSrc;
    newScript.async = true;
    document.body.appendChild(newScript);
  });
};

['mouseover', 'touchstart', 'scroll', 'keydown'].forEach(event => {
  window.addEventListener(event, loadDeferredScripts, { once: true });
});

También eliminé CSS bloqueador de renderizacion incorporando estilos críticos y difiriendo la hoja de estilos completa:

<link rel="preload" href="/wp-content/themes/theme/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/theme/style.css"></noscript>

Impacto después de la Fase 5: INP bajo de 680ms a 62ms. El payload total de JavaScript se redujo en un 78 por ciento.

#Fase 6: Optimización del proceso de compra (días 20-23)

Un sitio rápido no significa nada si el checkout mata las conversiones. Reconstruí todo el flujo de checkout:

• Reducción de 5 pasos a 2 (envío + pago en una página, confirmación en la siguiente)
• Eliminación de 14 campos de formulario innecesarios (nombre de empresa, teléfono 2, fax, etc.)
• Adición de pago exprés (Apple Pay, Google Pay, Klarna)
• Implementación de autocompletado de dirección usando la API de Google Places
• Adición de validación de formulario en tiempo real para prevenir errores al enviar

// Eliminar campos de checkout WooCommerce innecesarios
add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_phone_2']);
    unset($fields['billing']['billing_fax']);
    unset($fields['order']['order_comments']);
    return $fields;
});

// Agregar soporte para pasarela de pago expres
add_action('woocommerce_review_order_before_payment', function () {
    if (class_exists('WC_Payment_Gateway')) {
        echo '<div id="express-checkout-buttons" class="express-payment-wrapper">';
        do_action('woocommerce_express_checkout_buttons');
        echo '</div>';
    }
});

Impacto después de la Fase 6: La tasa de abandono de carrito bajo un 34 por ciento. El tiempo medio de completar el checkout se redujo de 4 minutos 12 segundos a 1 minuto 38 segundos.

#Fase 7: CDN y edge caching (días 24-28)

La última capa de optimización aseguro que las ganancias de rendimiento fueran consistentes en todos los mercados europeos:

• Cloudflare Pro con reglas de página personalizadas para WooCommerce
• Edge caching para páginas de productos estáticas con TTL de 4 horas
• Encabezados de cache del navegador con cache-busting vía hashing de contenido
• Compresión Brotli habilitada en el edge para todos los recursos basados en texto
• Early Hints (103) para recursos críticos

# Reglas de página Cloudflare
URL: *example.com/product/*
Cache Level: Cache Everything
Edge Cache TTL: 4 hours
Browser Cache TTL: 1 hour

URL: *example.com/cart*
Cache Level: Bypass

URL: *example.com/checkout*
Cache Level: Bypass

Impacto después de la Fase 7: TTFB global bajo a menos de 100 milisegundos. Usuarios en Europa Occidental experimentaron cargas completas de página por debajo de 800ms.

#WooCommerce PageSpeed antes y después de la optimización

Después de cuatro semanas de optimización sistemática, la transformación fue dramática:

#Cómo interpretar las Core Web Vitals de una tienda WooCommerce

La columna de calificación de las tablas anteriores sigue los umbrales que Google publica en web.dev. Un Largest Contentful Paint bueno ocurre en los primeros 2,5 segundos desde que la página empieza a cargar, un Interaction to Next Paint bueno es de 200 milisegundos o menos y un Cumulative Layout Shift bueno es de 0,1 o menos. Google evalúa cada métrica en el percentil 75 de las cargas de página, separando móvil y escritorio, así que una página aprueba solo cuando tres de cada cuatro visitas cumplen el umbral.

Las puntuaciones PageSpeed de 40 y 98 son otro tipo de número. Son puntuaciones de laboratorio obtenidas con una carga simulada, útiles para comparar una versión del sitio con la siguiente durante un proyecto como este. La misma guía de web.dev indica que la medición en laboratorio no sustituye a la medición de campo, porque las Core Web Vitals son métricas de campo recogidas de visitantes reales. Después de un lanzamiento, los datos que hay que vigilar son los datos de campo de PageSpeed Insights y el informe de Core Web Vitals de Search Console, unas semanas más tarde, cuando ya se han registrado suficientes visitas reales.

#Cómo afecta la velocidad a la conversión en WooCommerce

Las métricas técnicas son satisfactorias, pero las métricas de negocio justifican la inversión:

• La tasa de conversión se duplicó aproximadamente
• Los ingresos móviles aumentaron - los usuarios móviles finalmente podían comprar sin frustración
• La tasa de rebote se redujo aproximadamente a la mitad - los visitantes se quedaban y navegaban en lugar de irse
• El proyecto se pago solo en semanas, no en trimestres
• El valor medio del pedido subió - la navegación más rápida de productos llevo a más artículos en el carrito
• El tráfico orgánico creció - los Core Web Vitals mejorados contribuyeron a mejores rankings de búsqueda en 8 semanas

#Lecciones sobre el rendimiento de WooCommerce

Cada proyecto de optimización me enseña algo nuevo. Estas son las conclusiones clave de este compromiso:

#1. ¿Cuánto influye el hosting en la velocidad de WooCommerce?

Ninguna cantidad de optimización de frontend puede compensar un servidor lento. La migración de hosting compartido a un VPS LiteSpeed optimizado represento el 35 por ciento de la mejora total de rendimiento.

#2. ¿Por qué limpiar la base de datos de WooCommerce con regularidad?

Las tiendas WooCommerce generan enormes cantidades de datos transientes. Sin limpieza regular, la tabla wp_options se convierte en un cuello de botella que afecta cada carga de página. La limpieza semanal automatizada debería ser estándar para cualquier tienda WooCommerce.

#3. ¿Cómo ralentizan los plugins una tienda WooCommerce?

De los 38 plugins instalados, 14 estaban sin uso, eran redundantes o reemplazables con fragmentos de código ligeros. Cada plugin agrega consultas a la base de datos, JavaScript y CSS - incluso cuando su funcionalidad no es necesaria en la página actual.

#4. ¿Cuánto reducen las imágenes AVIF el peso de la página?

La conversión a AVIF y la implementación de imágenes responsivas redujeron el peso de la página en más del 80 por ciento. Este único cambio, que puede automatizarse en gran medida, ofrece la mejora más visible para los usuarios finales.

#5. ¿Cómo afecta la UX del checkout a los ingresos?

El rediseño del checkout, aunque no es una optimización de “rendimiento” tradicional, tuvo el impacto más directo en los ingresos. Reducir la fricción en el proceso de compra es tan valioso como reducir los tiempos de carga.

#6. ¿Cómo medir el impacto de cada optimización?

Al implementar cambios en fases y medir después de cada una, pude cuantificar el impacto exacto de cada optimización. Este enfoque basado en datos previene esfuerzos desperdiciados y construye una narrativa clara para los stakeholders.

#Cuánto tarda optimizar una tienda WooCommerce

#Cómo aplicar estos métodos en WordPress y WooCommerce en 2026

Tres de los métodos anteriores dependen de funciones de WordPress, WooCommerce y Cloudflare que han cambiado desde que se escribieron muchos tutoriales. Así funciona cada uno según la documentación de los propios fabricantes.

#Cómo generar imágenes AVIF en WordPress

WordPress admite AVIF desde la versión 6.5, según el anuncio publicado en Make WordPress Core. El soporte depende de la biblioteca de imágenes del servidor: WordPress trabaja con Imagick y con GD, y la sección de gestión de medios de la información de salud del sitio muestra si AVIF está disponible. Para convertir los JPEG subidos en AVIF, el equipo de core documenta el filtro image_editor_output_format. El filtro wp_editor_set_quality fija la compresión entre 1 y 100 para un tipo MIME concreto. Según el anuncio, AVIF usa por defecto compresión con pérdida con calidad 82, y la calidad 100 lo pasa a modo sin pérdida.

wp media regenerate no tiene opciones de formato ni de calidad. Sus opciones son los ID de adjuntos, --image_size, --skip-delete, --only-missing, --delete-unknown, --update-attachment-refs (solo en versiones nightly) y --yes (documentación de WP-CLI). Los filtros deciden el formato y la calidad, y el comando reconstruye los tamaños de imagen, por eso el ejemplo de la Fase 4 usa ambos.

#Cómo borrar los transients caducados en WooCommerce

WP-CLI borra los transients caducados con wp transient delete --expired, y wp transient delete --all elimina todos (documentación de WP-CLI). Con una caché de objetos persistente como Redis, los transients pueden guardarse en esa caché en lugar de en la tabla wp_options, y el manual de la Transients API advierte que el código nunca debe suponer que un transient está en la base de datos. La función de core delete_expired_transients(), añadida en WordPress 4.9, no hace nada cuando hay una caché de objetos externa activa. Por eso las filas caducadas escritas antes de activar la caché de objetos se quedan en la tabla hasta que algo las borra directamente de la base de datos, que es el trabajo que hizo la Fase 3.

#Qué páginas y cookies de WooCommerce excluir de la caché

La documentación para desarrolladores de WooCommerce indica que hay que excluir de la caché de página el carrito, la cuenta del cliente y el checkout, porque muestran información propia del cliente actual y de su carrito. También enumera las cookies que se pueden indicar a la caché para que las ignore: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed y store_notice[notice id]. Las reglas de LiteSpeed de la Fase 2 excluyen las tres páginas, y el ejemplo de Cloudflare de la Fase 7 muestra el carrito y el checkout.

Cloudflare está sustituyendo las Page Rules por un conjunto de productos Rules dedicados y migra automáticamente las Page Rules existentes (guía de migración). Una configuración nueva expresa la misma lógica con Cache Rules: marcar la elegibilidad de caché como apta para caché sustituye a Cache Everything, los ajustes Edge TTL y Browser TTL recogen los valores de TTL, y una regla que detecta una cookie con la elegibilidad en modo bypass mantiene fuera de la caché compartida a los visitantes con una sesión de carrito activa.

#Auditoría gratuita de rendimiento WooCommerce

Si tu tienda puntúa por debajo de 70 en PageSpeed Insights, estas perdiendo clientes cada día. Mi servicio de optimización WooCommerce sigue la misma métodología probada descrita en este caso de estudio, adaptada a tu tienda e infraestructura específicas.

Ofrezco una auditoría de rendimiento inicial gratuita - un informe detallado que muestra exactamente donde tu tienda pierde velocidad y cuanto de ingresos te cuesta. Sin obligaciónes, sin discurso de ventas, solo datos.

Contacta a WPPoland para programar tu auditoría, o conoce mas sobre mis servicios de optimización de velocidad WordPress.

#Recursos relacionados

• Lograr 100/100 Core Web Vitals para WordPress en 2026
• Optimización de rendimiento WooCommerce
• Optimización de velocidad WordPress