Cómo Optimizar el Rendimiento de tu WordPress

Optimizar WordPress no es instalar un plugin de caché y cruzar los dedos. Es entender qué parte de tu web está frenando qué métrica, y actuar ahí primero. En Avantys hemos auditado cientos de sitios WordPress, y casi siempre el patrón se repite: se ataca el síntoma (la web “va lenta”) sin diagnosticar la causa real, y el resultado son horas invertidas en optimizaciones que no mueven la aguja.

Esta guía cubre las seis áreas que de verdad determinan la velocidad de un WordPress (hosting, caché, base de datos, plugins, imágenes y Core Web Vitals) con la profundidad técnica para que puedas diagnosticar y actuar tú mismo. Si ya sabes que quieres profundizar en un punto concreto, cada sección enlaza al artículo dedicado del clúster.

Si vienes de Por Qué WordPress Va Lento (y Cómo Gestionarlo Bien) y quieres entender las causas generales antes de entrar en materia técnica, empieza por ahí. Si ya sabes que el problema es de rendimiento y quieres actuar, sigue leyendo.

Antes de tocar nada: diagnostica primero

El error más común es “optimizar a ciegas”: instalar tres plugins de caché, activar minificación agresiva y desactivar plugins al azar, sin medir antes y después. Sin una línea base, no sabes si tus cambios ayudan, empeoran o simplemente no hacen nada.

Las métricas que importan

Google mide tu web con tres Core Web Vitals desde marzo 2024:

Métrica	Qué mide	Objetivo	% de sitios que lo cumple (2026)
LCP (Largest Contentful Paint)	Cuánto tarda en aparecer el contenido principal	< 2,5s	53%
INP (Interaction to Next Paint)	Cuánto tarda la web en responder a una interacción	< 200ms	74% en móvil
CLS (Cumulative Layout Shift)	Estabilidad visual (elementos que “saltan”)	< 0,1	72%

A estas dos añade el TTFB (Time to First Byte), que no es oficialmente un Core Web Vital pero explica gran parte del LCP: el tiempo que tarda el servidor en responder antes de que el navegador empiece siquiera a pintar la página.

Cómo interpretar los resultados

TTFB > 600ms de forma consistente: el problema está en el servidor o el backend (hosting, PHP, base de datos).
LCP alto con TTFB bajo: el problema está en el frontend, imágenes, tema o scripts pesados.
INP alto: JavaScript bloqueante o un DOM excesivo (típico de page builders mal configurados).
CLS alto: elementos sin dimensiones definidas, imágenes o anuncios que “empujan” el contenido al cargar.

Herramientas para medir

Herramienta	Qué mide	Cuándo usarla
PageSpeed Insights	Core Web Vitals de campo y de laboratorio	Primer diagnóstico
GTmetrix	Waterfall detallado, petición por petición	Análisis profundo
Query Monitor	Consultas SQL, hooks y tiempos por plugin	Debugging técnico en WordPress
WebPageTest	Pruebas desde distintas ubicaciones geográficas	Comparativas para público internacional

Mide siempre en modo incógnito, con caché de navegador desactivada, y repite la prueba 3 veces para descartar picos puntuales. Guarda capturas de cada ronda: sin un “antes”, no puedes demostrar el “después”.

Hosting: la base que decide el TTFB

El hosting es responsable directo del TTFB, que a su vez representa hasta el 40% del LCP. Si el servidor tarda en responder, todo lo que viene después arranca con retraso.

Por qué el hosting compartido barato se queda corto

En un hosting compartido tradicional compartes CPU, RAM y I/O de disco con cientos de sitios en el mismo servidor. Si otro sitio del servidor recibe un pico de tráfico o ejecuta código mal optimizado, tu web nota la diferencia aunque no tenga nada que ver contigo.

Tipo de hosting	TTFB promedio	Tecnología típica
Compartido barato	~790ms	Apache, HDD/SSD básico
Compartido optimizado	~450ms	Apache/Nginx, SSD
Hosting WordPress administrado	~380ms	LiteSpeed, NVMe, OPcache, Redis

Las diferencias clave de un hosting pensado para WordPress:

LiteSpeed en lugar de Apache: hasta 6 veces más rápido sirviendo WordPress, y compatible con LSCache, su sistema de caché a nivel de servidor.
Almacenamiento NVMe: velocidades de lectura hasta 7 veces superiores a un SSD tradicional.
Object cache con Redis o Memcached: reduce las consultas repetidas a la base de datos.
PHP con OPcache: evita recompilar el mismo código PHP en cada petición.

Señales de que el hosting es el cuello de botella

TTFB superior a 600ms de forma sostenida, no solo en picos.
Errores 503 o timeouts frecuentes en horas de más tráfico.
CPU al límite constantemente en el panel de control.
El propio wp-admin va lento, no solo la web pública.

Si necesitas comparar opciones concretas de hosting antes de decidir, en Cómo Elegir Hosting para que WordPress no Vaya Lento entramos en el detalle de qué mirar y qué preguntar a un proveedor.

Checklist antes de contratar o cambiar de hosting

Antes de firmar con un proveedor, pide respuesta clara a estas preguntas, si el proveedor no las responde con datos concretos, es una señal de alerta:

¿Los servidores usan LiteSpeed, Apache o Nginx? ¿Incluye LSCache o un sistema de caché a nivel de servidor?
¿El almacenamiento es NVMe, SSD o todavía HDD?
¿Ofrecen object cache (Redis/Memcached) o hay que contratarlo aparte?
¿Qué versiones de PHP soportan y cuál es la que viene activa por defecto?
¿Dónde están físicamente los servidores? (relevante tanto para latencia como para RGPD si tu público es europeo)
¿Qué SLA de uptime garantizan por contrato, no solo en el marketing?

Cómo se ve una auditoría de rendimiento real

Para que esto no se quede en teoría, así es como auditamos un WordPress en Avantys cuando llega un cliente diciendo “va lento”:

Medición inicial: PageSpeed Insights y GTmetrix en las 5 páginas con más tráfico (home, una categoría, un producto o servicio destacado, contacto y checkout si hay tienda). Guardamos capturas de TTFB, LCP, INP y CLS de cada una.
Diagnóstico de servidor: comprobamos versión de PHP, si hay OPcache activo, si el hosting usa LiteSpeed o Apache, y el TTFB con la caché de página desactivada temporalmente.
Auditoría de plugins: instalamos Query Monitor en un entorno de staging y revisamos qué plugins generan más consultas y más tiempo de ejecución por página.
Revisión de frontend: Chrome DevTools Coverage para detectar CSS/JS no utilizado, y comprobación manual del peso de las imágenes más pesadas.
Base de datos: tamaño total, número de revisiones acumuladas y tablas huérfanas de plugins ya desinstalados.

Con ese diagnóstico priorizamos: casi siempre el 80% de la mejora sale de dos o tres cambios (activar caché correctamente, optimizar imágenes y resolver un plugin concreto mal optimizado), no de tocar veinte cosas a la vez.

Caché: la optimización con mejor retorno

Sin caché, cada visita obliga a WordPress a ejecutar PHP, consultar la base de datos y generar el HTML desde cero. Con caché bien configurada, sirves una copia ya generada y ese proceso desaparece para la mayoría de visitas.

Los tres niveles de caché

Caché de página: guarda el HTML final de cada página. Es la que más impacto tiene y la más fácil de activar.
Caché de objetos (Redis/Memcached): guarda resultados de consultas repetidas a la base de datos, útil sobre todo en sitios con usuarios registrados o WooCommerce.
Caché de borde / CDN: sirve contenido estático (imágenes, CSS, JS) desde el servidor más cercano al visitante.

Ejemplo de configuración típica de exclusión de caché de página (para no cachear el carrito o el checkout en una tienda), en un archivo de configuración de LiteSpeed Cache:

; wp-config.php - definir constantes antes de cachear
define('WP_CACHE', true);
define('LSCWP_CONTENT_DIR', WP_CONTENT_DIR);

Y una regla típica para excluir del caché las páginas de carrito y checkout en WooCommerce (a añadir vía el panel del plugin de caché, no directamente en código):

Excluir de caché:
/carrito/*
/finalizar-compra/*
/mi-cuenta/*

Errores comunes al configurar caché

Cachear páginas con contenido dinámico por usuario (carrito, área de cliente), esto puede llegar a mostrarle a un usuario el carrito de otro.
No purgar la caché tras publicar o editar contenido, dejando versiones desactualizadas visibles.
Activar minificación agresiva de JS sin probar antes, puede romper scripts que dependen de un orden de carga concreto.

Cabeceras de caché de navegador

Además de la caché de página en el servidor, conviene indicar al navegador durante cuánto tiempo puede guardar en local los archivos estáticos (imágenes, CSS, JS) para no volver a descargarlos en visitas repetidas. Ejemplo de configuración en un servidor Apache (.htaccess):

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

En servidores con Nginx, el equivalente se define directamente en el bloque server:

location ~* \.(webp|jpg|jpeg|png|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

Si tu hosting usa LiteSpeed, la mayoría de estas reglas ya vienen preconfiguradas en el propio plugin LiteSpeed Cache, sin necesidad de tocar archivos de configuración a mano.

Fuentes web y scripts de terceros

Un punto que casi siempre se pasa por alto: cada fuente de Google Fonts, cada píxel de analítica, cada widget de chat en directo es una petición adicional a un servidor externo, y cada una de esas peticiones puede bloquear el renderizado si no se carga de forma diferida.

Buenas prácticas rápidas:

Aloja las fuentes en tu propio servidor en lugar de cargarlas desde Google Fonts, y usa font-display: swap para que el texto no quede invisible mientras la fuente carga.
Limita el número de pesos y familias tipográficas, dos pesos de una sola familia suelen ser suficientes para la mayoría de webs corporativas.
Carga los scripts de chat, mapas o vídeos incrustados de forma diferida, activándolos solo tras la primera interacción del usuario o cuando el elemento entra en la pantalla.
Revisa periódicamente qué scripts de terceros siguen activos, es habitual acumular píxeles de campañas ya terminadas que nadie desactiva.

Si quieres entender qué tipo de caché te conviene según tu tipo de web, lo desarrollamos en Caché en WordPress: Tipos y Cuál Elegir.

Base de datos: el cuello de botella que no se ve

Cada post, comentario, revisión y transient se guarda en tu base de datos MySQL. Sin mantenimiento, las tablas acumulan datos que nadie necesita y las consultas se vuelven más lentas con el tiempo.

Los problemas más frecuentes

Revisiones acumuladas: WordPress guarda cada versión de cada entrada. Un post editado 50 veces tiene 50 revisiones ocupando espacio.
Transients expirados: datos temporales que deberían autoeliminarse y muchas veces no lo hacen.
Tablas huérfanas: plugins desinstalados que dejan tablas completas sin usar en la base de datos.
Tablas MyISAM en lugar de InnoDB: MyISAM bloquea toda la tabla al escribir; InnoDB solo bloquea la fila afectada, lo que mejora mucho el rendimiento en sitios con tráfico.

Cómo limpiar la base de datos

Consulta para eliminar revisiones acumuladas (haz backup antes de ejecutar cualquier consulta directa en producción):

DELETE FROM wp_posts WHERE post_type = 'revision';

Para limitar las revisiones futuras, añade esto a tu wp-config.php:

define('WP_POST_REVISIONS', 3);

Para limpiar transients expirados de forma segura, es preferible usar un plugin como WP-Optimize antes que borrar tablas a mano, algunos transients activos son necesarios para el funcionamiento de plugins concretos.

Si tu web tiene mucho volumen de contenido o es una tienda WooCommerce con muchos pedidos, dedicamos un artículo completo a este tema en Cómo Optimizar la Base de Datos de WordPress.

Plugins: el enemigo silencioso

No es raro encontrar sitios con 40 o más plugins activos preguntándose por qué van lentos. Pero el problema real no es la cantidad, es la calidad y el mantenimiento de cada uno.

Cómo identificar qué plugin te está frenando

Método 1, Query Monitor: instala este plugin temporalmente (solo en staging o fuera de horas punta) y revisa la pestaña “Queries by Component”, que muestra el tiempo de consulta SQL agrupado por plugin. Los que aparecen arriba en tiempo son tus principales sospechosos.

Método 2, Desactivación selectiva: desactiva todos los plugins, mide la velocidad base, y ve activándolos uno a uno, midiendo después de cada activación. El primero que empeore notablemente el tiempo de carga es tu candidato a sustituir o eliminar.

Método 3, Chrome DevTools Coverage: abre las herramientas de desarrollo (F12), pestaña Coverage, recarga la página, e identifica qué archivos CSS/JS cargan código que nunca se llega a usar.

Categorías de plugins que más suelen pesar

Categoría	Ejemplos típicos	Por qué pesan
Page builders	Elementor, Divi	DOM excesivo, CSS/JS voluminoso
Seguridad con escaneo activo	Wordfence en modo escaneo continuo	Alto consumo de CPU
Estadísticas propias	Plugins de analítica alojada en el propio servidor	Consultas pesadas por visita
Sliders y carruseles	Revolution Slider, Layer Slider	Scripts adicionales, DOM inflado

Un único plugin mal optimizado puede pesar más que diez bien hechos juntos. La auditoría periódica de plugins, no solo su instalación inicial, es la parte que casi nadie mantiene en el tiempo, y es justo el tipo de tarea que cubrimos en Cómo Reducir el Impacto de los Plugins en WordPress y que, si prefieres no llevar tú mismo mes a mes, forma parte de lo que gestionamos en Gestión WordPress.

Page builders: el debate de siempre

Elementor, Divi y builders similares facilitan mucho el diseño, pero tienen un coste de rendimiento real.

Builder	Puntuación móvil típica	Tamaño de página	Peticiones
Sin builder (Gutenberg)	95-100	~150KB	15-20
Elementor Pro	74/100	~450KB	35-45
Divi	64/100	~520KB	40-50

El problema no es solo el peso: los page builders envuelven cada elemento en múltiples <div> anidados, lo que infla el DOM y ralentiza tanto el renderizado como la respuesta a interacciones (INP). Si ya usas uno de estos builders, no hace falta abandonarlo, activar la salida de DOM optimizado, usar iconos en línea en vez de librerías completas, y aplicar carga diferida en fondos ayuda de forma notable sin rehacer el diseño.

Imágenes: la victoria más rápida

Las imágenes representan típicamente entre el 50% y el 80% del peso total de una página. Es, con diferencia, la optimización con mejor relación esfuerzo-resultado.

Formato	Reducción de peso vs JPEG	Soporte en navegadores
WebP	25-35%	97%+
AVIF	50%+	92%+
JPEG (fallback)	Referencia	100%

Pasos recomendados: comprime antes de subir, sirve en formato moderno con fallback automático a JPEG, activa el lazy loading nativo (WordPress lo incluye desde la versión 5.5), y no subas nunca una imagen de 4.000px para mostrarla en un espacio de 800px, el navegador la descarga entera igualmente. El detalle paso a paso, con ejemplos de configuración por plugin, está en Cómo Optimizar Imágenes en WordPress sin Perder Calidad.

CDN: cuándo lo necesitas de verdad

Si tu público es local (España, un idioma), el impacto de un CDN es limitado, tu servidor ya está cerca. Si tienes visitantes internacionales, un CDN sirve el contenido estático desde el punto de presencia más cercano a cada visitante, reduciendo notablemente los tiempos de carga fuera de tu región. Cloudflare en su plan gratuito ya cubre caché de estáticos y protección básica frente a ataques DDoS; entramos en cuándo compensa dar el salto a opciones de pago en CDN para WordPress: Cuándo lo Necesitas de Verdad.

Rendimiento en móvil: no es lo mismo que en escritorio

Google mide y prioriza la versión móvil de tu web (mobile-first indexing), y en móvil los problemas de rendimiento se notan más: procesadores más limitados, conexiones más variables y pantallas donde cada elemento pesado se percibe con mayor lentitud.

Puntos específicos a revisar en móvil:

Imágenes responsive: usa srcset y sizes para que el navegador descargue una versión de la imagen adecuada al tamaño real de pantalla, no la misma imagen de escritorio reducida por CSS.
Menús y sliders táctiles: los menús con muchos submenús anidados o los sliders con animaciones pesadas afectan más al INP en móvil que en escritorio.
Anuncios y banners: si insertas banners de terceros (incluido el propio banner de cookies), resérvales un espacio fijo en el diseño para evitar que el contenido “salte” al cargar (esto es lo que mide el CLS).
Prueba en una conexión real, no solo en Wi-Fi de oficina: las herramientas de PageSpeed Insights y WebPageTest permiten simular conexiones 4G, que reflejan mejor la experiencia real de buena parte de tus visitantes.

Plan de acción: por dónde empezar

Si tienes que priorizar, este orden da el mejor retorno con el menor esfuerzo:

Semana 1: activa caché de página, optimiza las imágenes existentes, actualiza PHP a una versión reciente.
Semana 2: minifica CSS/JS, aplica lazy loading, revisa fuentes web externas.
Semana 3: limpia la base de datos, audita plugins con Query Monitor.
Semana 4: evalúa CDN y, si el TTFB sigue alto pese a todo lo anterior, valora cambiar de hosting.

Preguntas Frecuentes

¿Por dónde empiezo si no sé cuál es mi problema de velocidad? Mide primero con PageSpeed Insights. Si el TTFB es alto, mira el hosting. Si el LCP es alto con TTFB bajo, mira imágenes y frontend.

¿Merece la pena un plugin de caché de pago frente a uno gratuito? Para la mayoría de sitios no es imprescindible: LiteSpeed Cache (gratuito) es tan potente como los de pago si tu hosting usa servidores LiteSpeed. Un plugin de pago simplifica configuraciones que, si no, requerirían varios plugins gratuitos combinados.

¿Cuántos plugins es “demasiados”? No hay un número fijo. Lo que importa es que cada plugin esté bien mantenido y justifique su presencia, hemos visto sitios rápidos con 40 plugins y lentos con 10.

¿Debería abandonar Elementor si quiero un sitio rápido? No necesariamente. Con la salida de DOM optimizada activada y sin acumular addons innecesarios, Elementor puede rendir razonablemente bien.

¿Cada cuánto debo optimizar la base de datos? Mensualmente para sitios con actividad moderada; semanalmente si tienes mucho contenido nuevo, comentarios o es una tienda WooCommerce activa.

¿Los plugins desactivados afectan a la velocidad? No cargan código en el frontend, pero conviene eliminarlos igualmente para mantener el panel ordenado y reducir superficie de ataque.

¿Qué versión de PHP debería usar? La más reciente compatible con tus plugins, cada versión trae mejoras de rendimiento notables sobre la anterior. Verifica compatibilidad antes de actualizar.

¿Un CDN gratuito como Cloudflare ayuda de verdad? Sí, especialmente si tienes visitantes fuera de tu región. Para público 100% local el impacto es menor.

¿Cómo sé si el problema es el hosting o los plugins? Mide el TTFB con la caché desactivada. Si supera 1 segundo de forma consistente, sospecha del hosting antes que de los plugins.

¿Optimizar el rendimiento mejora el SEO? Sí, de forma directa: los Core Web Vitals son factor de posicionamiento desde 2022, y de forma indirecta, porque una web rápida reduce el abandono y mejora el tiempo en página.

Conclusión

El rendimiento de WordPress no se arregla con un solo cambio, es la suma de decisiones correctas en hosting, caché, base de datos, plugins e imágenes. La buena noticia es que, priorizado bien, el 80% de la mejora sale del 20% del esfuerzo: caché, imágenes y un hosting adecuado.

Si prefieres no dedicar tiempo cada mes a medir, auditar y ajustar todo esto, en Avantys nos encargamos de la optimización continua dentro de Gestión WordPress, no es una revisión puntual, es supervisión constante para que la velocidad no se degrade con el tiempo.