¿WordPress funciona lento? 9 causas y cómo solucionarlas

Tu sitio web de WordPress tarda en cargar cuatro o cinco segundos, el panel de administración se ralentiza y tu cliente te escribe que «le va lento». Este es uno de los problemas más comunes con los que nos llegan los propietarios de sitios web. La buena noticia es que, en nueve de cada diez casos, la causa es una de las varias bien conocidas y se puede encontrar en una hora.

A continuación, tienes nueve razones por las que WordPress funciona lento, en orden de frecuencia. Para cada una, te explicamos cómo reconocerla y cómo solucionarla por tu cuenta.

Tabla de Contenidos

1. ¿Cómo saber si WordPress funciona realmente lento?
2. ¿La causa es el hosting compartido?
3. ¿Tienes demasiados plugins?
4. ¿Las imágenes son demasiado pesadas?
5. ¿La página tiene el caché activado?
6. ¿Qué versión de PHP utiliza la página?
7. ¿La base de datos no está saturada?
8. ¿El tema o el page builder no son demasiado pesados?
9. ¿Los scripts externos no bloquean la carga?
10. ¿wp-cron no está consumiendo recursos?
11. ¿Por dónde empezar la reparación?
12. FAQ

¿Cómo saber si WordPress funciona realmente lento?

Antes de cambiar nada, mide. Sin una medición, no sabes si la corrección ayudó, y «me parece más rápido» no es un resultado.

Tres herramientas son suficientes:

• PageSpeed Insights (pagespeed.web.dev) muestra la puntuación de Google para móvil y ordenador, así como las métricas de Core Web Vitals. El más importante es el LCP, es decir, el tiempo que tarda en aparecer el elemento más grande de la página. Un buen resultado es por debajo de 2,5 segundos.
• GTmetrix o WebPageTest desglosan la carga en un gráfico de cascada. Muestra qué archivo tarda más en cargarse.
• TTFB (Time To First Byte), es decir, el tiempo hasta el primer byte de respuesta del servidor. Puedes comprobarlo con ambas herramientas o en la pestaña Red del navegador (F12). Si el TTFB supera los 600 ms, el problema reside en el servidor o en PHP. Si el TTFB es bajo, pero la página sigue tardando mucho en cargarse, los culpables son los archivos del lado del navegador: imágenes, scripts, fuentes.

Esta división es clave. Un TTFB alto indica hosting, falta de caché, PHP antiguo, una base de datos sobrecargada o wp-cron. Un TTFB bajo con una carga lenta indica imágenes, un tema pesado y scripts externos. Los plugins pueden estropear ambas cosas.

Mide la página principal y una subpágina, por ejemplo, una entrada o una ficha de producto. Guarda los resultados, volverás a ellos después de cada cambio.

¿La culpa es del alojamiento compartido?

Esta es la razón número uno que el propietario de un sitio web rara vez sospecha, porque "después de todo, estoy pagando por el alojamiento".

En el alojamiento compartido clásico, tu sitio web se encuentra en un servidor junto con cientos de otros. El procesador, la memoria y el disco son compartidos. Cuando un vecino tiene un pico de tráfico, envía un boletín o alguien ataca su sitio, tu WordPress también se ralentiza. A esto se suman los límites de procesos PHP. Cuando varias personas ingresan a la tienda al mismo tiempo, las solicitudes adicionales esperan en una cola.

Cómo reconocerlo: El TTFB salta. Por la mañana, 300 ms; por la noche, 2 segundos, sin ningún cambio en el sitio. En el panel de alojamiento, ves mensajes sobre el exceso de límites de recursos (a menudo llamados "resource limit reached" o "508").

Cómo solucionarlo: La optimización del sitio ayudará solo parcialmente. Si el servidor está sobrecargado por otros, debes cambiar a un alojamiento donde los recursos te sean asignados. En Saplo, cada Box es un contenedor separado con su propia RAM y disco. Box S tiene 1 GB de RAM, Box M 2 GB, Box L 6 GB, y nadie de fuera consume esa memoria. Los detalles de los planes están en la lista de precios.

¿Tienes demasiados plugins?

La cantidad de plugins en sí misma no es un problema. Un sitio con cuarenta plugins ligeros puede funcionar más rápido que uno con diez plugins pesados. El problema son los plugins que, cada vez que se accede al sitio, realizan muchas consultas a la base de datos o cargan sus scripts en cada subpágina, incluso donde no son necesarios.

Los culpables más comunes son los plugins de estadísticas robustos que se calculan en el servidor, los plugins de seguridad «todo en uno» que escanean archivos durante el tráfico, y los plugins de entradas relacionadas, sliders y formularios que se cargan globalmente.

Cómo identificarlo: instala el plugin gratuito Query Monitor. En la barra de administración, mostrará el tiempo de generación de la página, el número de consultas a la base de datos y qué plugin envía cuántas. Una página que tarda más de 0,5 segundos en generarse o que tiene varios cientos de consultas tiene un problema.

Cómo solucionarlo:

1. Haz una copia de seguridad del sitio.
2. Desactiva los plugins que no hayas usado en meses. Elimínalos, no solo los desactives.
3. Busca una alternativa más ligera para los plugins pesados.
4. Utiliza un plugin como Asset CleanUp o Perfmatters para desactivar la carga de scripts de un determinado plugin donde sea innecesario (por ejemplo, los scripts de un formulario de contacto solo en la página de Contacto).
5. Vuelve a medir.

¿Son tus imágenes demasiado pesadas?

Una foto directamente de la cámara o el teléfono pesa de 4 a 8 MB y tiene un ancho de 4000 píxeles. En la página web se muestra a 800 píxeles de ancho, pero el navegador sigue teniendo que descargar el archivo completo. Tres imágenes como estas en la página de inicio y el LCP (Largest Contentful Paint) aumenta a varios segundos, especialmente en el teléfono.

Cómo identificarlo: En PageSpeed Insights aparecen las recomendaciones "Sirve imágenes en formatos de próxima generación" y "Ajusta el tamaño de las imágenes". En el gráfico en cascada, las barras más largas son archivos JPG o PNG.

Cómo solucionarlo:

• Antes de subir las imágenes, redúcelas a un ancho razonable, generalmente de 1600 a 2000 píxeles para imágenes de ancho completo.
• Habilita la conversión a formato WebP o AVIF. Esto lo hacen plugins como Converter for Media, EWWW Image Optimizer o ShortPixel.
• Asegúrate de que la carga diferida (lazy loading) esté activada. WordPress lo añade automáticamente desde la versión 5.5, pero algunos temas lo deshabilitan.
• La imagen visible en la parte superior de la página (por ejemplo, una imagen en el encabezado) no debe cargarse de forma diferida. Esta es la que decide el LCP.

¿Tiene la página web la caché habilitada?

Sin caché, WordPress lanza PHP con cada visita, se conecta a la base de datos, crea la página con decenas de consultas y solo entonces la envía al navegador. Con diez visitantes a la vez, el servidor hace el mismo trabajo diez veces.

Hay dos tipos de caché que conviene distinguir:

• La caché de páginas guarda el HTML listo y se lo sirve a los siguientes visitantes sin lanzar PHP. Esto lo ofrecen los plugins WP Super Cache, W3 Total Cache, LiteSpeed Cache (solo en servidores LiteSpeed) o WP Rocket (de pago).
• La caché de objetos (object cache) almacena los resultados de las consultas a la base de datos en la memoria, generalmente en Redis. Ayuda donde la caché de páginas no funciona: en el panel de administración, en el carrito y en la cuenta de cliente de la tienda WooCommerce.

Cómo detectarlo: en Query Monitor, comprueba si la caché de objetos está activa. El TTFB de una página que actualizas por segunda vez debería disminuir notablemente. Si no disminuye, la caché de páginas no funciona.

Cómo solucionarlo: instala un plugin de caché de páginas (no dos a la vez, porque entran en conflicto) y activa la caché de objetos si el hosting ofrece Redis. En Saplo, la instalación de WordPress desde el catálogo conecta automáticamente un Redis local en el Box y activa el plugin Redis Object Cache, con un prefijo y una base de datos separados para cada página. No es necesario configurar nada manualmente.

¿Qué versión de PHP usa el sitio?

WordPress está escrito en PHP, y cada versión de PHP es más rápida que la anterior. La diferencia entre PHP 7.4 y PHP 8.3 en la misma página puede ser notable, especialmente en el panel de administración y en tiendas grandes. Además, PHP 7.4 ya no recibe actualizaciones de seguridad.

Cómo identificarlo: En el panel de WordPress, ve a Herramientas, luego a Salud del sitio, después a Información, y finalmente a la sección Servidor. Ahí verás la versión de PHP y el límite de memoria.

Cómo solucionarlo:

1. Haz una copia de seguridad.
2. Actualiza WordPress, el tema y los plugins a sus últimas versiones. Los plugins antiguos suelen ser incompatibles con las nuevas versiones de PHP.
3. Cambia la versión de PHP en el panel de tu hosting a 8.2 o 8.3.
4. Comprueba la página de inicio, el formulario, el carrito y el panel. Si algo falla, vuelve a la versión anterior y busca qué plugin es incompatible.

En Saplo, cuando instalas WordPress, eliges la versión de PHP de una lista que va desde 7.4 hasta 8.5. Por defecto, instalamos la 8.3, porque es compatible con prácticamente todos los plugins actuales.

¿No está saturada la base de datos?

La base de datos de WordPress se hincha con el tiempo. Acumula revisiones de publicaciones (cada guardado crea una nueva copia), publicaciones en la papelera, spam en los comentarios, datos temporales caducados (transients) y opciones de plugins que eliminaste hace mucho tiempo. La tabla wp_options es especialmente peligrosa. WordPress carga algunas de sus filas cada vez que se accede a la página (opciones con la bandera de autocarga). Cuando crece a varios megabytes, ralentiza cada acceso.

Cómo identificarlo: En el estado del sitio de WordPress, a partir de la versión 6.6, te avisa si tienes opciones de autocarga demasiado grandes. En Query Monitor, puedes ver las consultas lentas a la base de datos.

Cómo solucionarlo:

• Limita el número de revisiones añadiendo la línea wp-config.php al archivo define('WP_POST_REVISIONS', 5);.
• Limpia la base de datos con el plugin WP-Optimize o Advanced Database Cleaner: revisiones, papelera, spam, transients caducados.
• Elimina las opciones de los plugins desinstalados. Advanced Database Cleaner muestra a qué plugin pertenece cada opción.
• Siempre haz una copia de seguridad de la base de datos antes de limpiarla.

¿Tu tema o page builder no es demasiado pesado?

Los temas "multifuncionales" que se venden con un centenar de diseños listos para usar cargan scripts y estilos para todas sus funciones en cada página, incluso aquellas que no utilizas. Los page builders (Elementor, Divi, WPBakery) añaden a esto código HTML profundamente anidado y sus propios archivos CSS y JS.

Esto no significa que debas deshacerte del builder. Significa que debes configurarlo.

Cómo identificarlo: en PageSpeed Insights, las recomendaciones "Reduce el JavaScript no utilizado" y "Reduce el CSS no utilizado" apuntan a los archivos del tema o del builder. La página tiene varios megabytes de scripts.

Cómo solucionarlo:

• En Elementor, activa las funciones de rendimiento en la configuración (carga optimizada de recursos, carga de CSS en un archivo en lugar de inline).
• Desactiva los módulos del tema que no utilizas (sliders, iconos, animaciones).
• Al construir una nueva página, considera un tema ligero, por ejemplo, GeneratePress, Kadence o Astra, y un editor de bloques en lugar de un builder pesado.

¿Los scripts externos no bloquean la carga?

Un chat en la web, el píxel de Facebook, Google Analytics, Tag Manager con diez etiquetas, un mapa de Google, un vídeo incrustado de YouTube, un widget de reseñas, fuentes de Google Fonts. Cada uno de ellos es una conexión separada con un servidor diferente y unos cuantos kilobytes adicionales de scripts sobre los que no tienes control.

Cómo identificarlo: En el diagrama de cascada, ves muchos archivos de dominios de terceros. PageSpeed Insights muestra la recomendación "Reducir el impacto del código de terceros".

Cómo solucionarlo:

• Revisa Tag Manager y elimina las etiquetas de campañas antiguas.
• Carga el chat solo después de la interacción del usuario o después de unos segundos.
• Incrusta los vídeos de YouTube como una miniatura que carga el reproductor solo después de hacer clic (esto lo hace, por ejemplo, WP YouTube Lyte).
• Descarga las fuentes a tu propio servidor en lugar de cargarlas desde Google Fonts. De paso, resuelves el problema del GDPR.

¿wp-cron devora recursos?

WordPress tiene un programador de tareas integrado, wp-cron. No funciona como un cron de sistema real, sino que se ejecuta cuando llegan los visitantes. En una web con mucho tráfico, se activa con demasiada frecuencia, y en una web con poco tráfico, las tareas (publicación de entradas programadas, copias de seguridad, envío de correos electrónicos desde la tienda) se ejecutan con retraso y pueden ralentizar una entrada aleatoria que justo las activó.

Cómo identificarlo: las entradas individuales son notablemente más lentas que el resto sin una razón aparente. El plugin WP Crontrol muestra una lista de tareas y a menudo tareas de plugins eliminados que llevan años colgadas.

Cómo solucionarlo:

1. En WP Crontrol, elimina las tareas de los plugins que ya no tengas.
2. Deshabilita la ejecución de wp-cron por parte de los visitantes, añadiendo la línea define('DISABLE_WP_CRON', true); a wp-config.php.
3. Configura un cron de sistema real que cada 5 minutos llame a wp cron event run --due-now o a la dirección wp-cron.php. En Saplo, desde un Box M (65 €/año) tienes acceso SSH con sudo completo, así que lo configurarás en una sola línea de crontab.

¿Por dónde empezar a arreglarlo?

Si no sabes por dónde empezar, sigue este orden, porque los cambios de arriba son los más baratos y los que tienen mayor efecto:

1. Mide la página en PageSpeed Insights y anota el TTFB y el LCP.
2. Haz una copia de seguridad de toda la página y la base de datos.
3. Actualiza WordPress, los plugins y PHP a 8.2 o 8.3.
4. Activa la caché de páginas y, si puedes, la caché de objetos en Redis.
5. Optimiza las imágenes y conviértelas a WebP.
6. Revisa los plugins en Query Monitor y elimina los innecesarios.
7. Limpia la base de datos y limita las revisiones.
8. Aligera los scripts externos y configura el tema.
9. Mide de nuevo. Si el TTFB sigue fluctuando según la hora del día, el problema está en el hosting, no en la página.

En este último caso, ningún plugin te ayudará. Debes trasladar la página a un lugar donde los recursos del servidor sean solo tuyos. Si estás considerando Saplo, nosotros trasladaremos tu WordPress por ti: la migración es gratuita, junto con la base de datos y el correo electrónico, sin interrupción del servicio. Encontrarás más información sobre cómo funciona WordPress en Saplo en la página de WordPress en el catálogo de aplicaciones y en la página de hosting de WordPress.

Preguntas Frecuentes

¿Cuántos plugins son demasiados en WordPress?

No hay un límite único. Lo que importa es lo que hacen los plugins, no su número. Un sitio con treinta plugins ligeros puede funcionar rápido, mientras que un solo plugin mal escrito puede bloquearlo. Comprueba el tiempo de generación de la página y el número de consultas en Query Monitor, no el número de elementos en la lista.

¿Es suficiente un plugin de caché para acelerar WordPress?

A menudo, proporciona el mayor impulso de una sola vez, pero no lo resuelve todo. La caché de página no funciona en el panel de administración, en el carrito de compras ni para los clientes de la tienda que han iniciado sesión. En esos casos, ayuda la caché de objetos en Redis, una versión actualizada de PHP y tener los plugins en orden. La caché tampoco solucionará imágenes pesadas o un servidor sobrecargado.

¿Por qué el panel de administración de WordPress es lento, pero la página rápida?

Porque los visitantes obtienen páginas ya hechas del caché, y el panel de administración siempre se genera en tiempo real a través de PHP y la base de datos. Un panel lento suele ser señal de plugins pesados, una tabla de wp_options llena, PHP antiguo o falta de caché de objetos. Empieza por el Query Monitor abierto en el panel.

¿Qué es un buen resultado en PageSpeed Insights?

Una puntuación de 90 o superior es muy buena; entre 50 y 89, requiere mejoras. Más importantes que el número en sí son las métricas de Core Web Vitals: LCP por debajo de 2,5 segundos, INP por debajo de 200 ms y CLS por debajo de 0,1. Estas son las que influyen en la clasificación de tu sitio en Google.

¿Un cambio de hosting acelerará WordPress?

Sí, si la causa es el servidor, es decir, un TTFB alto e inestable y mensajes sobre límites de recursos. No, si el sitio tiene imágenes pesadas y decenas de scripts innecesarios, porque los mismos archivos tendrán que descargarse del nuevo servidor. Primero mide, luego decide.