Volver al blog
8 min de lectura
Rendimiento WordPress

Por qué tu sitio WordPress es lento: las 7 causas más frecuentes

Del diagnóstico a la corrección — con cifras. Antes de gastar en un CDN o plugin premium, identifica la causa real.

Puntos Clave
  • El 80 % de los sitios WordPress lentos comparten las mismas 7 causas — identificar la correcta evita gastos innecesarios
  • El alojamiento es la causa n°1 más subestimada: un TTFB superior a 800 ms no puede compensarse con optimizaciones front-end
  • Cada causa tiene una solución específica — Orilyt detecta automáticamente las causas 1, 2 y 5 mediante los tests #01, #02 y #07
80%
des sites lents partagent les mêmes causes
800ms
TTFB critique — au-delà, l'hébergement est en cause
50-70%
du poids de page = images non optimisées

Tu sitio WordPress es lento — ¿pero por qué? Esa es la pregunta que se hacen miles de propietarios de sitios cada día. Y ahí es donde empiezan los errores: se instala un plugin de caché, se compra un CDN, se cambia de tema... sin jamás diagnosticar la causa real.

La realidad es que el 80 % de los sitios WordPress lentos sufren los mismos 7 problemas. Estos problemas están bien documentados, son medibles y — buena noticia — la mayoría se corrigen sin grandes presupuestos.

En este artículo, repasaremos cada causa con datos concretos, explicaremos su impacto real en la experiencia del usuario y el SEO, y te daremos la solución precisa a aplicar. Del diagnóstico a la corrección, paso a paso.

Las 7 causas de un WordPress lento: alojamiento, imágenes, plugins, caché, JavaScript, base de datos, tema

Causa n°1: Alojamiento compartido saturado

Esta es con diferencia la causa más frecuente — y la más subestimada. En un alojamiento compartido barato, tu sitio comparte los recursos del servidor (CPU, RAM, E/S) con cientos de otros sitios. Cuando los vecinos están activos, tú sufres.

El indicador clave es el TTFB (Time to First Byte): el tiempo entre el envío de la solicitud y la recepción del primer byte de respuesta. Un alojamiento sano responde en menos de 200 ms. Por encima de 800 ms es crítico — y ninguna optimización front-end podrá compensarlo.

Fix : La solución: pasar a un alojamiento WordPress gestionado (Kinsta, WP Engine, Cloudways) o como mínimo un VPS. La mejora es inmediata y a menudo espectacular. Orilyt mide tu TTFB con el test #01 y te alerta si tu servidor responde demasiado lentamente.

Causa n°2: Imágenes sin optimizar

Las imágenes representan en promedio entre el 50 y el 70 % del peso de una página web. En un sitio WordPress típico, suelen subirse en su formato original (JPEG o PNG de alta resolución), sin conversión a WebP, sin compresión y sin dimensiones declaradas.

El resultado: una página que descarga 3 MB de imágenes cuando podría descargar 800 KB con los mismos visuales. En WebP, las imágenes son entre un 25 y un 35 % más ligeras que en JPEG. El lazy loading evita cargar imágenes fuera de pantalla en la primera carga.

Fix : La solución: instalar un plugin como Imagify, ShortPixel o Smush para la conversión a WebP y la compresión automática. Añadir loading="lazy" en todas las imágenes fuera del viewport. Declarar width y height en cada etiqueta img para evitar el CLS. Orilyt verifica estos puntos con el test #09.

Causa n°3: Demasiados plugins activos

WordPress es extensible por naturaleza — y esa es su fortaleza. Pero cada plugin activo tiene un coste: añade peticiones HTTP, carga CSS y JavaScript adicionales, y ejecuta consultas a la base de datos en cada carga de página.

Con más de 30 plugins, la probabilidad de conflictos y ralentizaciones significativas aumenta considerablemente. Un solo plugin mal desarrollado puede multiplicar por 10 las consultas SQL. Los plugins de seguimiento, SEO, seguridad y formularios son los más voraces.

Fix : La solución: auditar los plugins con la extensión Query Monitor. Desactivar y eliminar todos los plugins inactivos. Reemplazar varios plugins pequeños por uno solo más completo. Verificar que ningún plugin cargue sus assets en todas las páginas (un plugin de WooCommerce no debería cargar en los artículos del blog).

Causa n°4: Ausencia de caché

Sin caché, cada visita a tu sitio desencadena un ciclo completo: PHP ejecutado, base de datos consultada, HTML generado, respuesta enviada. Este ciclo lleva tiempo — de 200 ms a más de un segundo según la complejidad de la página y la potencia del servidor.

Con caché de páginas, la primera visita genera el HTML estático que se sirve directamente para todas las visitas posteriores. Sin PHP, sin SQL, solo un archivo estático. La mejora de rendimiento puede alcanzar el 90 %.

Fix : La solución: activar un plugin de caché como WP Rocket, W3 Total Cache o LiteSpeed Cache (si tu alojamiento soporta LiteSpeed). Añadir una caché de objetos (Redis o Memcached) para las consultas repetitivas. Configurar cabeceras de caché del navegador para los recursos estáticos (CSS, JS, imágenes).

Causa n°5: JavaScript que bloquea el renderizado

El navegador lee el HTML de arriba abajo. Cuando encuentra una etiqueta script sin atributo defer o async, lo detiene todo, descarga el script, lo ejecuta y luego continúa. Durante ese tiempo, el usuario ve una página en blanco.

Este es el problema del "JavaScript bloqueante". En un sitio WordPress medio, hay a menudo entre 5 y 15 scripts cargados de esta forma: Google Analytics, Hotjar, Facebook Pixel, el script jQuery del tema, widgets... Cada uno añade decenas o cientos de milisegundos.

Fix : La solución: añadir el atributo defer en todos los scripts no críticos. Usar async para scripts independientes (analytics). Cargar las fuentes de Google con font-display: swap. Retrasar los scripts de seguimiento hasta la primera interacción del usuario. Orilyt detecta los recursos bloqueantes con el test #07.

Causa n°6: Base de datos sin optimizar

Con el tiempo, la base de datos de WordPress acumula datos innecesarios que ralentizan las consultas SQL: revisiones de entradas (WordPress conserva 10 por defecto), datos transientes expirados, metadatos huérfanos de plugins desinstalados, comentarios spam y tablas fragmentadas.

En un sitio de 3 años, la tabla wp_posts puede contener 10 veces más revisiones que entradas publicadas. La tabla wp_options puede pesar varios MB por los transientes acumulados. Cada consulta SQL tarda más en ejecutarse.

Fix : La solución: instalar WP-Optimize o Advanced DB Cleaner para limpiar regularmente la base de datos. Limitar las revisiones en wp-config.php con define('WP_POST_REVISIONS', 3). Añadir un índice en wp_postmeta(meta_key, meta_value) si usas consultas de metadatos complejas. Programar un OPTIMIZE TABLE mensual.

Causa n°7: Tema pesado y constructores de páginas

Algunos temas WordPress "todo en uno" incluyen docenas de funcionalidades que solo usas en un 10 %: sliders, animaciones, shortcodes, constructores visuales... Cada uno añade CSS y JavaScript cargados en todas las páginas, incluso en las que no lo necesitan.

Los constructores de páginas (Elementor, Divi, WPBakery) son especialmente problemáticos. Generan HTML anidado y pesado, cargan múltiples archivos CSS y JavaScript, y producen a menudo CSS inline no minificable. Un tema Elementor puede cargar fácilmente 500 KB de CSS adicionales.

Fix : La solución: elegir un tema ligero y rápido (Astra, GeneratePress, Kadence) con menos de 50 KB de CSS. Si usas un constructor de páginas, activar la carga condicional de assets (Elementor lo ofrece). Desactivar las funcionalidades no utilizadas del tema a través de las opciones del panel de control.
Un sitio WordPress lento no es una fatalidad. Es un diagnóstico de 7 puntos — y 5 de ellos se corrigen en una tarde.

Cómo diagnosticar rápidamente

Antes de corregir, hay que medir. Aquí están los 3 pasos de un diagnóstico rápido:

  1. Medir el TTFB: utiliza Chrome DevTools (pestaña Network, busca "Waiting for server response") o GTmetrix. Si el TTFB supera los 800 ms, empieza por el alojamiento.
  2. Analizar el peso de la página: en GTmetrix o WebPageTest, identifica los recursos más pesados. ¿Más del 60 % son imágenes? Empieza por la causa n°2. ¿Mucho JS/CSS? Causas 3, 5 o 7.
  3. Probar con y sin plugins: desactiva todos los plugins, prueba la velocidad, reactívalos uno a uno. Es laborioso pero decisivo para identificar al culpable.

Orilyt automatiza los pasos 1 y 2: el test #01 (TTFB), el test #02 (peso de página) y el test #07 (recursos bloqueantes) te dan una visión inmediata de las causas 1, 2 y 5 sin manipulación técnica.

¿Por dónde empezar?

Si tu sitio es lento y no sabes por dónde empezar, sigue este orden de prioridad: alojamiento primero (causa n°1), imágenes después (causa n°2), caché (causa n°4), JavaScript (causa n°5). Estas 4 correcciones cubren el 80 % de los casos.

Las causas n°3, 6 y 7 requieren más trabajo pero tienen un impacto significativo en los sitios maduros. Planifícalas para una segunda fase, una vez capturadas las mejoras inmediatas.

Para freelancers y agencias, saber diagnosticar estas causas es una competencia clave. Orilyt genera el informe de rendimiento en 2 minutos y produce recomendaciones FIA (Hecho, Impacto, Acción) listas para presentar a tus clientes — sin tener que bucear en Lighthouse tú mismo.

Diagnostica la lentitud de cualquier sitio WordPress
Lanza una auditoría gratuita y obtén el diagnóstico completo: TTFB, peso de página, recursos bloqueantes y 53 verificaciones más.
Lanzar una auditoría gratis
Anterior Badge « Audité par Orilyt » : prouvez la qualité du site à vos visiteurs Siguiente Ttfb