Cómo mejorar velocidad WordPress por capas

Plan estructurado por capas —caché, assets, base de datos y mediciones— para mejorar la velocidad de WordPress sin romper el diseño ni la funcionalidad del sitio.

Por qué mejorar velocidad WordPress requiere un plan por capas

Mejorar velocidad WordPress no consiste en instalar un plugin de caché y cruzar los dedos. Lo he visto decenas de veces: alguien activa WP Rocket o LiteSpeed Cache, ve una puntuación alta en PageSpeed y asume que el trabajo está hecho. Dos semanas después, un formulario deja de funcionar, el checkout de WooCommerce da errores o el diseño se descuadra en móvil. El problema de fondo es que la optimización de rendimiento —lo que en el sector llamamos WPO— tiene múltiples capas, y saltarse el orden o mezclarlas produce más daño que beneficio.

Si ya has leído el artículo sobre WordPress lento: causas y pasos para acelerarlo, sabrás que el diagnóstico es el primer paso. Este artículo va un paso más allá: te da un plan de ejecución estructurado en cuatro capas, con el orden correcto y mediciones antes y después para que cada cambio sea verificable.

La lógica de capas: de dentro hacia fuera

Imagina tu sitio WordPress como una cebolla. Cada capa envuelve a la anterior, y optimizar la capa externa sin tocar la interna es como pintar una fachada agrietada: queda bien en la foto, pero el problema sigue ahí. El orden que funciona en la práctica es este:

1. Capa 1 — Base de datos: el núcleo donde se almacenan posts, opciones, transients y metadatos.
2. Capa 2 — Assets (CSS, JS, fuentes, imágenes): todo lo que el navegador descarga y renderiza.
3. Capa 3 — Caché: las diferentes capas de caché que evitan que el servidor repita trabajo.
4. Capa 4 — Medición y validación: comprobar que cada cambio mejora las métricas sin romper nada.

¿Por qué este orden y no al revés? Porque si tu base de datos tiene 200.000 filas de transients caducados, la caché servirá páginas generadas desde una consulta lenta. Y si tus assets pesan 4 MB sin comprimir, la caché servirá 4 MB comprimidos, pero el problema de peso sigue ahí. Trabajar de dentro hacia fuera asegura que cada capa se apoya en una base ya limpia.

Capa 1: optimización de la base de datos

Qué limpiar y por qué importa

La base de datos de WordPress acumula residuos con el tiempo. Estos son los principales culpables:

• Revisiones de posts: WordPress guarda cada borrador. Un post con 50 revisiones multiplica las filas en wp_posts y wp_postmeta.
• Transients caducados: datos temporales que plugins almacenan en wp_options y que muchas veces no se auto-eliminan.
• Tablas huérfanas: plugins desinstalados que dejaron sus tablas sin borrar.
• Autoloaded options: filas en wp_options marcadas como «autoload = yes» que se cargan en cada petición, incluso si el plugin que las creó ya no existe.

Según datos de Percona, una tabla wp_options con más de 1 MB de datos autoloaded puede añadir entre 200 y 500 ms al TTFB (Time to First Byte). Esos milisegundos se suman a cada petición no cacheada.

Acciones concretas

1. Limita las revisiones a 3-5 añadiendo define('WP_POST_REVISIONS', 5); en wp-config.php.
2. Elimina transients caducados con una consulta SQL directa o con herramientas como WP-CLI: wp transient delete --expired.
3. Revisa el peso de autoloaded options con SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';. Si supera 800 KB, investiga qué plugins están abusando.
4. Ejecuta OPTIMIZE TABLE en las tablas principales (wp_posts, wp_postmeta, wp_options) para recuperar espacio fragmentado.

Haz siempre una copia de seguridad antes de tocar la base de datos. Un error en una consulta DELETE puede borrar datos críticos.

Capa 2: assets — CSS, JavaScript, imágenes y fuentes

Reducir el peso sin romper el diseño

Esta es la capa donde más sitios se rompen al intentar mejorar la velocidad en WordPress. Minificar CSS y JS suena inofensivo, pero combinar archivos puede romper la secuencia de dependencias de un theme builder o de WooCommerce. Mi regla: minifica siempre, combina con precaución.

Un desglose típico del peso de assets en un sitio WordPress medio:

• Imágenes: 60-75% del peso total de la página.
• JavaScript: 15-25%.
• CSS: 5-10%.
• Fuentes: 2-5%.

Atacar las imágenes da el mayor retorno. Convertir a WebP o AVIF reduce el peso entre un 25% y un 50% respecto a JPEG, sin pérdida de calidad visible. Implementar lazy load en imágenes below-the-fold evita descargas innecesarias en el primer render.

JavaScript: defer, async y eliminación de lo innecesario

El JavaScript que bloquea el renderizado es el mayor enemigo del LCP (Largest Contentful Paint). Estas son las acciones de mayor impacto:

• Defer scripts no críticos: cualquier script que no participe en el renderizado del contenido visible debería cargarse con defer.
• Eliminar scripts de plugins inactivos: muchos plugins cargan sus scripts en todas las páginas, incluso donde no se usan. Herramientas como Asset CleanUp o Perfmatters permiten desactivar scripts por página o tipo de contenido.
• Delay de scripts de terceros: analytics, chat widgets, pixels de remarketing. Retrasar su carga 3-5 segundos o hasta la primera interacción del usuario mejora drásticamente las métricas de Core Web Vitals sin perder datos de seguimiento.

Fuentes: el detalle que nadie optimiza

Cargar Google Fonts desde el CDN de Google implica una conexión DNS adicional y un archivo CSS externo. Alojar las fuentes localmente con font-display: swap elimina esa dependencia y reduce el CLS (Cumulative Layout Shift). Un cambio que lleva 10 minutos y puede mejorar la puntuación de Core Web Vitals entre 5 y 15 puntos.

Capa 3: caché — el acelerador, no la solución

Tipos de caché y cuándo aplicar cada uno

La caché no acelera un sitio lento; acelera un sitio que ya genera páginas razonablemente rápido. Estos son los niveles de caché relevantes para mejorar velocidad WordPress:

• Object cache (Redis/Memcached): almacena consultas de base de datos en memoria RAM. Especialmente útil en WooCommerce, donde las páginas de producto hacen decenas de consultas por carga. Reduce el TTFB entre un 30% y un 60% en páginas no cacheables a nivel de página completa.
• Page cache: genera una copia HTML estática de cada página. Es lo que hacen WP Rocket, LiteSpeed Cache o W3 Total Cache. Ideal para páginas estáticas (home, blog, about). Problemático en páginas dinámicas (carrito, checkout, área de cliente).
• Browser cache: indica al navegador del visitante que almacene assets estáticos (imágenes, CSS, JS) durante un periodo determinado. Se configura con headers Cache-Control y Expires. Reduce las peticiones en visitas recurrentes.
• CDN cache: distribuye copias de tus assets (o de las páginas completas) en servidores geográficamente cercanos al visitante. Reduce la latencia, no el peso.

Errores frecuentes con la caché

He visto estos errores repetirse en proyectos reales:

1. Cachear el checkout de WooCommerce: rompe la sesión del usuario y provoca errores de pago. Las páginas transaccionales deben excluirse siempre del page cache.
2. Activar combinación agresiva de CSS/JS desde el plugin de caché: esto pertenece a la Capa 2 (assets), no a la Capa 3. El plugin de caché debería encargarse solo de servir y purgar la caché, no de reescribir tus assets.
3. No purgar la caché tras actualizaciones: si actualizas un plugin o un post y la caché no se purga, los visitantes ven contenido obsoleto. Configura la purga automática por eventos (update_post, save_post).
4. Dos plugins de caché activos simultáneamente: LiteSpeed Cache y WP Rocket activos a la vez generan conflictos de headers y duplican el almacenamiento de caché. Usa uno solo.

Capa 4: medición — mejorar velocidad WordPress con datos reales

Medir antes de cada cambio

Sin mediciones, optimizar es adivinar. El flujo correcto es:

1. Medir el estado actual con al menos dos herramientas: Google PageSpeed Insights (datos de campo + laboratorio) y GTmetrix o WebPageTest (cascada de peticiones).
2. Anotar las métricas clave: TTFB, LCP, INP (Interaction to Next Paint), CLS, tamaño total de la página, número de peticiones HTTP.
3. Aplicar UN cambio de la capa correspondiente.
4. Medir de nuevo con las mismas herramientas, misma localización, mismo dispositivo.
5. Comparar y decidir si el cambio se mantiene o se revierte.

Este enfoque de «un cambio, una medición» es más lento pero te permite saber exactamente qué mejoró y qué rompió algo. Cuando aplicas 10 cambios a la vez y la web se rompe, no sabes cuál fue el culpable.

Herramientas de medición y qué buscar en cada una

• Google PageSpeed Insights: la sección «Datos de campo» refleja la experiencia real de tus usuarios (basada en CrUX). La sección «Datos de laboratorio» es una simulación. Los datos de campo son más fiables pero necesitan tráfico mínimo para aparecer.
• GTmetrix: su cascada de peticiones (waterfall) te muestra exactamente qué recursos tardan más en cargarse y en qué orden. Ideal para detectar scripts bloqueantes y redirecciones innecesarias.
• Query Monitor (plugin): imprescindible para medir el impacto de la Capa 1. Te muestra las consultas SQL más lentas, los hooks que consumen más tiempo y la memoria PHP utilizada por cada plugin.

Métricas objetivo realistas

No persigas el 100 en PageSpeed. Es una puntuación de laboratorio que no refleja necesariamente la experiencia real del usuario. Estos son los umbrales que considero funcionales para un sitio WordPress con contenido real y funcionalidades activas:

• TTFB: < 600 ms (hosting compartido) o < 200 ms (VPS/dedicado).
• LCP: < 2.5 segundos.
• INP: < 200 ms.
• CLS: < 0.1.
• Peso total de la página: < 1.5 MB en home, < 2 MB en páginas de producto.

Ejemplo real: el orden importa más que la herramienta

Trabajé en un proyecto WooCommerce con 3.000 productos donde el TTFB superaba los 2 segundos. El cliente ya tenía WP Rocket instalado con todas las opciones activadas. La puntuación en PageSpeed era de 28 en móvil.

El diagnóstico reveló que wp_options tenía 4.2 MB de datos autoloaded, principalmente transients de un plugin de comparación de precios que ya no se usaba. Además, se cargaban 14 archivos JavaScript en la ficha de producto, 9 de ellos innecesarios en esa página.

El proceso siguió exactamente el orden de capas:

1. Base de datos: limpieza de transients y reducción de autoloaded options a 600 KB. TTFB bajó de 2.1s a 0.9s.
2. Assets: desactivación de scripts innecesarios por tipo de página, conversión de imágenes a WebP, lazy load. Peso de la página de producto bajó de 4.8 MB a 1.7 MB.
3. Caché: configuración correcta de WP Rocket (excluyendo carrito y checkout, activando preload solo en páginas clave). TTFB en páginas cacheadas: 180 ms.
4. Medición final: PageSpeed subió a 74 en móvil. LCP bajó a 2.1 segundos. INP se mantuvo en 160 ms.

El cambio más impactante fue la limpieza de base de datos, no la caché. Si el cliente hubiera seguido ajustando parámetros de WP Rocket sin tocar la base de datos, habría conseguido mejoras marginales.

Checklist para mejorar velocidad WordPress sin romper nada

Antes de aplicar cualquier cambio, asegúrate de cumplir estos requisitos:

• ✔ Tienes una copia de seguridad completa (base de datos + archivos) verificada.
• ✔ Tienes un entorno de staging donde probar los cambios antes de aplicarlos en producción.
• ✔ Has medido las métricas actuales y las has anotado.
• ✔ Aplicas un cambio por vez y mides después de cada uno.
• ✔ Compruebas que las funcionalidades críticas (formularios, checkout, login) siguen funcionando tras cada cambio.
• ✔ No tienes dos plugins de caché activos al mismo tiempo.
• ✔ Has excluido las páginas dinámicas del page cache.

Preguntas frecuentes

¿Puedo mejorar la velocidad de WordPress solo con un plugin de caché?

No. Un plugin de caché sirve copias estáticas de páginas que ya se han generado. Si la generación original es lenta por una base de datos hinchada o assets pesados, la primera carga seguirá siendo lenta. La caché es una capa, no la solución completa.

¿Cuánto tiempo lleva una optimización WPO completa?

Depende del tamaño del sitio y del número de plugins activos. Para un sitio con 20-30 páginas y 5-10 plugins, un proceso riguroso por capas lleva entre 4 y 8 horas de trabajo técnico. Un WooCommerce con miles de productos puede necesitar 15-25 horas.

¿La optimización de velocidad afecta al diseño?

Puede. La minificación agresiva de CSS puede romper layouts. La combinación de archivos JS puede alterar el orden de ejecución de scripts. Por eso es fundamental probar en staging y medir después de cada cambio individual.

¿Con qué frecuencia hay que repetir la optimización?

Revisa las métricas mensualmente. Cada actualización de WordPress, de plugins o la adición de nuevo contenido puede alterar el rendimiento. Una auditoría WPO completa cada 6-12 meses es razonable para la mayoría de sitios.

Si necesitas ayuda profesional para aplicar este plan por capas en tu sitio o tienda WooCommerce, puedes ver cómo trabajo la optimización WPO y SEO técnico y valorar si encaja con lo que necesitas.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →