Empieza tu prueba gratuita de 7 díasSin tarjeta de crédito

Plataformas

¿Por qué va lento mi WordPress? Causas y soluciones

Descubre qué frena de verdad a WordPress, del hosting y los plugins a las imágenes y la caché, y resuélvelo en el orden correcto.

9 min de lectura

Un WordPress lento casi siempre se debe a una de estas cuatro cosas: un servidor que tarda demasiado en generar cada página, la falta de caché de página, demasiado trabajo de los plugins y del tema, o imágenes y scripts pesados en el navegador. La solución pasa por averiguar cuál de ellas te está afectando de verdad y atacarlas en orden, empezando por la respuesta del servidor y terminando por los retoques del front-end.

Mide antes de cambiar nada

Ir a ciegas es la forma más cara de acelerar WordPress. Antes de desactivar plugins o cambiar de hosting, consigue una referencia con la que comparar después.

  • Datos de usuarios reales: pasa tu URL por corewebvitals.page. Si tu web tiene tráfico suficiente, verás datos de campo de usuarios reales de Chrome para LCP, INP y CLS. Son los que usa Google para la experiencia de página.
  • Datos de laboratorio: la sección de Lighthouse que aparece debajo es una única carga simulada. Sirve para detectar causas, pero la puntuación cambia de una ejecución a otra.
  • Respuesta del servidor: comprueba cuánto tarda el propio HTML.
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

Ejecútalo varias veces y con distintos tipos de página: la portada, un artículo del blog, un archivo de categoría. Si el primer byte ya tarda más de un segundo aproximadamente, el problema está en el servidor, y ningún plugin de imágenes lo va a solucionar. web.dev propone como referencia un TTFB de 0,8 segundos o menos (en inglés).

Si quieres profundizar en la diferencia entre datos de laboratorio y de campo, y en cómo hacer una prueba justa de antes y después, consulta cómo medir bien la velocidad de una web.

Hosting y tiempo de respuesta del servidor

Cada petición a WordPress sin caché arranca PHP, carga el núcleo de WordPress, todos los plugins activos y el tema, y lanza desde decenas hasta cientos de consultas a la base de datos. Lo rápido que ocurra todo eso depende mucho del servidor.

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

  • El TTFB es alto incluso en páginas sencillas con poco contenido.
  • La web se ralentiza claramente en las horas punta o durante el envío de una newsletter.
  • El área de wp-admin va lenta, aunque no tenga nada que ver con los recursos del front-end.
  • El panel de tu hosting muestra que se alcanzan los límites de CPU o de memoria.

Qué puedes hacer

  • Actualiza PHP. Las versiones más nuevas de PHP suelen ser más rápidas y siguen recibiendo parches de seguridad. Mira qué versión ofrece tu hosting y prueba tu web con la más reciente que admitan tus plugins.
  • Añade una caché de objetos persistente. Redis o Memcached guardan en memoria los resultados de las consultas repetidas a la base de datos. Muchos hostings gestionados lo ofrecen como una opción que se activa sin más; ayuda sobre todo en las páginas dinámicas y en wp-admin.
  • Sube de plan o cambia de hosting si el servidor se queda corto para tu tráfico. A veces esa es la respuesta correcta, y por mucho que ajustes plugins no sustituyes la falta de CPU.

Si tu principal problema es el tiempo de respuesta, la guía específica para reducir el TTFB explica paso a paso los ajustes en el servidor, en la aplicación y en el edge.

Caché de página

La caché de página es la palanca más potente para la mayoría de webs WordPress. En lugar de construir la misma página con PHP y MySQL para cada visitante, se sirve directamente una copia en caché del HTML ya terminado. El manual para desarrolladores de WordPress tiene un buen resumen de las distintas capas de caché (en inglés).

Tienes tres opciones habituales:

OpciónDónde está la cachéEncaja bien con
Plugin de cachéEn tu servidor, en archivos o en memoriaWebs pequeñas, hosting compartido
Caché del hostingEn el servidor web o proxy del proveedorHosting gestionado de WordPress
Caché en el edge / CDNEn servidores cercanos a tus visitantesVisitantes en varias regiones, picos de tráfico

Estas capas pueden trabajar juntas. Lo importante es que los visitantes anónimos reciban HTML en caché y que las páginas que deben seguir siendo personales queden excluidas.

Lo que no se debe cachear

  • Usuarios con sesión iniciada y wp-admin (WordPress pone cookies de login y la mayoría de cachés las usan para no cachear).
  • Vistas previas de comentarios y entradas protegidas con contraseña.
  • Carrito, checkout y páginas de cuenta si tienes una tienda. La guía para acelerar WooCommerce trata estas reglas en detalle.

Comprueba si la caché funciona

Mira las cabeceras de respuesta. La mayoría de cachés añaden una cabecera que indica un hit o un miss:

curl -sI https://example.com/ | grep -i -E "cache|age"

Si todas las peticiones dan miss, o no aparece ninguna cabecera de caché, algo se está saltando la caché. Los sospechosos habituales son un plugin que pone una cookie en cada visita, cabeceras Cache-Control: no-cache enviadas por un plugin de seguridad o los parámetros de URL de los enlaces de seguimiento.

Plugins y temas

El número de plugins importa menos que lo que hacen. Un solo plugin mal hecho puede cargar más el servidor que veinte pequeños.

Encuentra los que más cuestan

  • Instala Query Monitor en una copia de staging. Muestra por cada carga de página las consultas a la base de datos, las consultas lentas, las llamadas a la HTTP API y los hooks de cada plugin.
  • Busca plugins que hagan peticiones HTTP externas al cargar la página (comprobaciones de licencia, contadores sociales, fuentes remotas). Bloquean la página mientras esperan a otro servidor.
  • Desactiva los sospechosos de uno en uno en staging y vuelve a medir el TTFB. No lo hagas en una tienda en producción.

Patrones habituales que ralentizan una web

  • Maquetadores visuales que cargan todo su CSS y JavaScript en cada página, aunque no se usen en ella.
  • Sliders, pop-ups y widgets de chat que cargan varios scripts en la parte visible de la página.
  • Plugins de entradas relacionadas y de estadísticas que lanzan consultas pesadas en cada petición.
  • Varios plugins que hacen lo mismo (dos plugins de SEO, dos de caché).

Un tema más ligero suele ayudar más que cualquier plugin de optimización. Si tu tema trae un framework grande que apenas usas, ese código se ejecuta igualmente en cada página.

Imágenes y medios

Las imágenes suelen ser la parte que más pesa de una página WordPress, y la imagen principal es a menudo el elemento que decide tu LCP.

  • Sube tamaños razonables. Una foto de 4.000 píxeles hecha con el móvil no pinta nada en una columna de contenido de 800 píxeles. WordPress crea tamaños más pequeños y usa srcset, pero solo si el tema los muestra correctamente.
  • Usa formatos modernos. WebP y AVIF ocupan mucho menos que JPEG y PNG con una calidad parecida.
  • Aplica lazy loading debajo del pliegue, no encima. WordPress añade loading="lazy" automáticamente, pero cargar en diferido la imagen principal retrasa el LCP. Asegúrate de que la imagen principal se carga de inmediato.
  • Indica el ancho y el alto para que el navegador reserve el espacio y el diseño no dé saltos (CLS).

La guía para optimizar imágenes para la web explica con más detalle los formatos, los tamaños y la estrategia de carga.

Base de datos y tareas en segundo plano

Las webs WordPress con años acumulan basura que ralentiza cada petición sin caché.

  • Opciones con autoload: los plugins guardan sus ajustes en wp_options, y las entradas marcadas como autoload se leen en cada petición. Los plugins eliminados suelen dejar entradas grandes. La herramienta Salud del sitio de las versiones recientes de WordPress avisa cuando los datos con autoload crecen demasiado.
  • Transients caducados y revisiones de entradas inflan las tablas. Límpialos con un plugin de mantenimiento o con WP-CLI, después de hacer una copia de seguridad.
  • WP-Cron ejecuta por defecto las tareas programadas durante las visitas normales. En webs con mucho tráfico, desactívalo en wp-config.php y lánzalo con un cron real del servidor:
define( 'DISABLE_WP_CRON', true );
  • Heartbeat API: las pestañas del editor abiertas envían peticiones a admin-ajax.php a intervalos regulares. En un hosting flojo esto se acumula; algunos plugins de rendimiento te permiten reducir la frecuencia.

El orden correcto

Seguir el orden correcto ahorra tiempo, porque los primeros pasos a menudo hacen innecesarios los siguientes.

  1. Mide el TTFB y las Core Web Vitals en tus tipos de página más importantes.
  2. Arregla la respuesta del servidor: versión de PHP, caché de objetos, recursos suficientes.
  3. Activa la caché de página para visitantes anónimos y comprueba las cabeceras de caché.
  4. Elimina o sustituye los plugins pesados y recorta lo que carga el tema.
  5. Optimiza las imágenes: tamaño, formato y nada de lazy loading en la imagen principal.
  6. Limpia la base de datos y pasa WP-Cron a un cron del servidor.
  7. Vuelve a medir con las mismas herramientas y páginas, y compara.

Si tus visitantes llegan desde varios países, la distancia hasta tu servidor también añade latencia a cada petición, aunque la caché en el origen sea buena. Ahí es donde ayuda una caché en el edge.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting de WordPress actual. Mantienes tu proveedor y tu web; añades tu dominio en el panel y apuntas tus servidores de nombres a fast.site. A partir de ahí, fast.site gestiona tu DNS, así que asegúrate de que todos los registros existentes, incluidos los registros MX del correo, estén en la zona DNS de fast.site.

Las visitas anónimas se sirven entonces con Fast Edge Cache™ desde servidores edge cercanos a tus visitantes, en las regiones disponibles en tu plan. Un cache HIT nunca llega a tu origen, lo que quita carga al servidor en las horas punta. Las sesiones iniciadas y wp-admin deben saltarse la caché, y la cabecera de respuesta fs-cache muestra HIT, MISS o BYPASS para que puedas comprobar cada página tú mismo. Después de publicar, puedes vaciar la caché de URLs concretas en el panel o mediante la API, y un cache warmer mantiene precargadas las páginas clave.

En el front-end, fast.site puede convertir JPEG y PNG a WebP sobre la marcha (AVIF según el plan) y, de forma opcional, precargar la imagen principal y añadir las dimensiones que falten en las imágenes. Tienes los detalles en la página de WordPress y en la documentación de caché.

Mide tu web antes y después con las mismas pruebas. Puedes probarlo con una prueba gratuita de 7 días, sin tarjeta de crédito.

Preguntas frecuentes

¿Por qué mi WordPress solo va lento cuando inicio sesión?

La mayoría de cachés de página no se aplican a los usuarios con sesión iniciada, así que cada página que ves la genera PHP desde cero. La barra de administración y los scripts del editor añaden trabajo extra. Prueba en una ventana privada para ver lo que reciben de verdad tus visitantes.

¿Tener muchos plugins ralentiza WordPress?

El número importa menos que lo que hace cada plugin. Unos pocos plugins pesados que lanzan consultas lentas o llaman a servicios externos en cada petición cuestan más que muchos pequeños. Usa Query Monitor en una web de staging para encontrar los que más cuestan.

¿Basta con un plugin de caché?

Para una web pequeña con visitantes locales, un plugin de caché bien configurado en un hosting decente suele ser suficiente. Si tus visitantes están repartidos por varias regiones o tienes picos de tráfico, una caché en el edge delante del servidor recorta la distancia y quita carga al origen.

¿Por qué el panel de administración de WordPress va tan lento?

wp-admin nunca pasa por la caché de página, así que muestra la velocidad real de tu servidor, tus plugins y tu base de datos. Un panel lento suele indicar un hosting que se queda corto, la falta de caché de objetos, demasiadas opciones con autoload o un plugin que hace mucho trabajo en cada petición del panel.

Prueba fast.site con tu propia web

fast.site añade caché en el edge, optimización de imágenes y protección DDoS a tu hosting actual. Conecta tu dominio y mide la diferencia en tus propias páginas.

Dale 7 días a tu web. Que decidan los resultados.

Empieza con tu dominio, tu tráfico y una idea clara de lo que ocurre después.