¿Tu WordPress va lento por los plugins? Medimos 331 webs

Cuando un WordPress va lento, el diagnóstico llega antes que la medición: «tienes demasiados plugins». Lo dicen desarrolladores, foros y hostings, y suena razonable. Así que lo medimos. Pasamos por nuestro rastreador 623 webs de empresas reales; respondieron 554, y 331 eran WordPress. En cada una contamos los plugins que cargan algo en la portada, pesamos todos sus archivos CSS y JavaScript y medimos el tiempo de respuesta del servidor.

El resultado desmiente la mitad del tópico. El número de plugins no tiene ninguna relación con lo que tarda el servidor en responder: una web con dos plugins y otra con quince tardan, de mediana, prácticamente lo mismo. Lo que separa una web rápida de una lenta en ese primer tramo es otra cosa, bastante más barata de arreglar. La otra mitad del tópico sí se cumple, pero no donde casi todo el mundo la busca.

En resumen

• Ninguna portada cargaba 47 plugins. La mediana es de 5 plugins visibles en portada y el máximo, 17. El problema no suele ser la cantidad.
• El número de plugins no predice el tiempo de respuesta. Webs con 0-2 plugins: 740 ms. Webs con 12 o más: 770 ms. Correlación: −0,02.
• La caché de página sí lo predice. Las webs que servían la portada desde caché respondían en 440 ms de mediana; las que no, en 1.090 ms. El 68 % de las segundas superaba los 800 ms que Google considera aceptables; de las primeras, el 6 %.
• Donde los plugins sí pesan es en la descarga. De 336 KB de CSS y JavaScript con 0-2 plugins a 822 KB con 12 o más. Los plugins aportan, de mediana, 25 archivos y el 42 % de ese peso.
• El culpable habitual no es un plugin raro, son los de siempre cargando donde no hacen falta. De 133 portadas que cargaban Contact Form 7, 75 no tenían ningún formulario.
• Tener el motor de caché no es usarlo. 46 de 80 webs en servidores LiteSpeed y 31 de 39 detrás de Cloudflare no servían la página desde caché.

Cómo lo medimos

La muestra son webs corporativas de pymes industriales y de servicios de Argentina, Colombia, Perú y República Dominicana: fabricantes y distribuidores de compresores, calderas, ascensores, sistemas contra incendios, tratamiento de aguas, energía. Webs en producción, de negocios que facturan, no proyectos abandonados. De las 554 que respondieron, el 60 % era WordPress.

Sobre cada portada, el 24 de septiembre de 2026:

• Plugins visibles: los que dejan rastro en el HTML de la portada, es decir, los que cargan archivos desde /wp-content/plugins/. Es la cifra que importa para el visitante, pero es un mínimo: los plugins que solo trabajan en el panel (copias de seguridad, seguridad, a veces el SEO) no aparecen. El número real de plugins instalados es mayor.
• Peso: descargamos cada archivo CSS y JavaScript enlazado y sumamos los bytes transferidos, comprimidos, tal como viajan por la red.
• Tiempo de respuesta (TTFB): con curl, tres peticiones por web, con poca concurrencia, quedándonos con la mediana. Medimos desde España, así que los valores absolutos incluyen el viaje transatlántico; lo que se compara son unas webs con otras dentro de la misma muestra, todas en las mismas condiciones.
• Caché: una web cuenta como «servida desde caché» si su respuesta lo declara en las cabeceras (x-litespeed-cache: hit, cf-cache-status: HIT, x-cache: HIT y equivalentes). Algunas cachés no se anuncian, así que la cifra real es algo mayor que la que damos.

No publicamos qué web es cada una. Lo que interesa es el patrón, no señalar a nadie.

Primero: ninguna portada carga 47 plugins

La imagen de la web con cincuenta plugins existe, pero en la portada no se ve. Así se reparten las 331 webs:

La mediana es 5 y el máximo, 17. Aunque el número instalado sea mayor, lo que el visitante paga es lo que se carga en la página que está viendo. Y eso rara vez pasa de diez.

Esto ya cambia la pregunta. «¿Cuántos plugins tienes?» es la pregunta equivocada. La buena es: ¿qué carga cada uno, y en qué páginas?

El número de plugins no predice el tiempo de respuesta

El TTFB (time to first byte) es lo que tarda el servidor en empezar a enviar la página. Es el suelo de todo lo demás: ninguna optimización de imágenes o de JavaScript recupera el tiempo perdido antes de que llegue el primer byte. Google recomienda mantenerlo por debajo de 800 ms. Si quieres el detalle de qué mide y cómo, lo explicamos en nuestro caso real de TTFB.

Si los plugins fueran lo que hace lento a WordPress, el TTFB debería subir con el número de plugins. No sube:

La correlación de rangos entre número de plugins y TTFB es de −0,02: ninguna. Las webs con más plugins no responden más despacio que las que casi no tienen.

No significa que un plugin no pueda hundir un servidor. Uno mal escrito, que lance cientos de consultas a la base de datos en cada página, lo hace sin problema, y se detecta con herramientas como Query Monitor. Lo que dicen los datos es que la cantidad no es lo que explica la diferencia. Hay algo que pesa muchísimo más.

Lo que sí lo predice: la caché de página

Sin caché de página, cada visita obliga a WordPress a arrancar PHP, cargar todos los plugins, consultar la base de datos y montar el HTML desde cero. Con caché, el servidor entrega una copia ya hecha. La diferencia en la muestra:

El «tiempo de servidor» es el TTFB menos la conexión y el handshake TLS: se acerca a lo que el servidor tarda de verdad en preparar la respuesta. Con caché, 130 ms. Sin caché, 730 ms: más de cinco veces más. Y las webs con caché no tenían menos plugins: su mediana era de 6, frente a 5 en las que no la tenían. Mismo WordPress, mismos plugins, otro resultado.

Lo más llamativo es cuántas webs tenían la caché al alcance de la mano y no la usaban:

• LiteSpeed sin caché. 80 webs estaban alojadas en servidores LiteSpeed, que traen un motor de caché de página integrado y gratuito que se activa con el plugin oficial LiteSpeed Cache. Solo 34 servían la portada desde caché, y respondían en 400 ms de mediana. Las otras 46, en 1.060 ms.
• Cloudflare sin caché. 39 webs tenían Cloudflare delante, y 31 respondían con cf-cache-status: DYNAMIC: Cloudflare no estaba guardando la página. Es su comportamiento por defecto, porque solo cachea imágenes, CSS y JavaScript, no el HTML. Tener Cloudflare no es tener caché de página.

Es el patrón de siempre: el problema no se ve navegando. La web carga, nadie se queja, y cada visita paga medio segundo largo que no debería pagar.

Donde los plugins sí pesan: lo que descarga el visitante

Si los plugins no explican el tiempo de respuesta, ¿dónde está su coste? En lo que viene después: los archivos que el navegador tiene que descargar, interpretar y ejecutar antes de que la página funcione.

Aquí la relación sí existe: correlación de 0,49 y el peso se multiplica por 2,4 entre el primer grupo y el último. La portada WordPress mediana de la muestra carga 48 archivos CSS y JavaScript, de los que 25 vienen de plugins, y los plugins aportan el 42 % del peso. Son bytes comprimidos: el navegador descomprime bastante más y tiene que procesarlo todo en un móvil de gama media.

Esto afecta a lo que Google mide como experiencia real, el LCP (cuándo aparece lo principal de la pantalla) y el INP (cuánto tarda la página en reaccionar a un toque), mucho más que al TTFB. Y afecta sobre todo en móvil, que es donde está la mayoría de visitas.

Cuatro patrones que se repiten

Más que un plugin raro, lo que encontramos son los mismos plugins de siempre, cargando donde no hacen falta.

1. El formulario que carga en páginas sin formulario

Contact Form 7 es el segundo plugin más frecuente de la muestra: 133 portadas cargaban sus archivos. En 75 de ellas no había ningún formulario. Contact Form 7 carga su CSS y su JavaScript en todas las páginas por defecto, por si acaso. El propio plugin documenta cómo evitarlo, con dos filtros (wpcf7_load_js y wpcf7_load_css) para cargar sus archivos solo donde hay un formulario. Además, 7 webs tenían dos plugins de formularios distintos cargando a la vez.

2. El constructor y su colección de complementos

Elementor está en 171 de las 331 webs, más de la mitad. Las webs con Elementor tenían una mediana de 7 plugins visibles; las que no usaban ningún constructor visual, 2. Y 40 de las 171 cargaban dos o más paquetes de complementos para Elementor (Essential Addons, ElementsKit, Premium Addons, Happy Addons…), casi siempre para usar uno o dos widgets de cada uno. Cada paquete trae su propia hoja de estilos y sus propios scripts. Las webs con constructor cargaban 555 KB de CSS y JavaScript de mediana; las que no lo usaban, 338 KB.

El constructor en sí no es el problema. Lo es ir añadiendo un paquete de complementos cada vez que se necesita un widget que el anterior no tenía.

3. El slider de la portada

Slider Revolution está en 84 portadas, una de cada cuatro. Es uno de los plugins más pesados que se pueden cargar arriba del todo, justo en la zona que determina el LCP. En 11 de esas portadas ni siquiera había un slider. En el resto, la pregunta que hay que hacerse es si ese carrusel vende algo o solo se mueve.

4. Un plugin para un botón

129 webs usaban un plugin para mostrar el botón de WhatsApp o un chat, y en 117 de ellas ese plugin cargaba JavaScript. Un botón de WhatsApp es un enlace a https://wa.me/ seguido del número, con un icono y cuatro líneas de CSS: no necesita un script en cada página. Y el 94 % de las webs seguía cargando jQuery, casi siempre porque algún plugin o el tema lo pide.

Qué hacer, en este orden

1. Activa la caché de página y comprueba que funciona. Es la mejora con más retorno de toda la lista y la que menos se hace. Si tu hosting es LiteSpeed, el plugin LiteSpeed Cache. Si no, la caché del propio hosting o un plugin como WP Rocket. Después, compruébalo con el curl de más abajo: activar no es lo mismo que funcionar.
2. Mira qué carga cada página, no cuántos plugins tienes. Abre la portada, pulsa Ctrl+U (ver código fuente) y busca /wp-content/plugins/. Cada nombre que aparezca después de esa ruta es un plugin que tu visitante está descargando. Pregúntate si esa página lo usa.
3. Carga cada plugin solo donde se usa. El formulario, en la página de contacto. El slider, donde haya slider. Algunos plugins lo permiten de serie; para el resto existen gestores de scripts (Perfmatters, Asset CleanUp) que desactivan archivos página por página.
4. Consolida los complementos del constructor. Si tienes tres paquetes de widgets para Elementor, probablemente puedas quedarte con uno. Revisa también las opciones de rendimiento del propio constructor, que en las versiones recientes cargan solo el CSS de los widgets usados.
5. Sustituye plugins por código cuando la función es trivial. Un botón, un icono, un fragmento de seguimiento. Cuatro líneas en el tema pesan menos que un plugin con su panel, sus scripts y sus actualizaciones.
6. Y solo entonces, mira el hosting. Si con la caché bien puesta el servidor sigue por encima de 300-400 ms, el problema ya no es WordPress: es dónde está alojado.

Cómo comprobarlo en tu web en dos minutos

Para saber si tu portada se sirve desde caché, desde un terminal:

curl -s -D - -o /dev/null https://tudominio.com/ | grep -i -E "cache|age:|server:"

Lánzalo dos o tres veces seguidas: la primera puede fallar la caché porque la estás calentando tú. Busca una cabecera de caché con HIT (x-litespeed-cache: hit, cf-cache-status: HIT, x-cache: HIT, según el hosting). Si solo ves MISS, DYNAMIC o ninguna cabecera de caché, tu servidor está generando la página en cada visita.

Para medir el tiempo de respuesta separando la conexión:

curl -s -o /dev/null -w "ttfb=%{time_starttransfer}s conexion=%{time_appconnect}s\n" https://tudominio.com/

La diferencia entre los dos números es, aproximadamente, lo que tarda tu servidor. Con caché debería estar muy por debajo de 200 ms. Si ronda el medio segundo o más, estás en el grupo de los 250.

Y para el peso, PageSpeed Insights en la pestaña de móvil: el diagnóstico de JavaScript sin usar te dice qué archivos se descargan y no se usan, con el nombre del plugin en la ruta.

Errores frecuentes

• Borrar plugins a ciegas. Desinstalar cinco plugins que no cargaban nada en el frontal no cambia la velocidad que nota el visitante. Hay que empezar por los que cargan archivos, en las páginas donde no se usan.
• Instalar un plugin de caché y no comprobarlo. Un plugin activo con la caché mal configurada, o anulada por una cookie que se emite en cada página, es lo mismo que no tenerlo. La cabecera de respuesta es la única prueba.
• Creer que Cloudflare ya cachea la web. Por defecto no guarda el HTML. Hace falta una regla de caché para las páginas, con cuidado de excluir carrito, cuenta y panel.
• Apilar un plugin de optimización sobre otro. Dos plugins de caché o dos que minifican el mismo CSS se pisan y pueden romper la web sin mejorar nada.
• Medir desde tu propio ordenador y una sola vez. Tu navegador tiene media web guardada. Mide en frío, varias veces y desde el país de tus clientes.

Preguntas frecuentes

¿Cuántos plugins son demasiados en WordPress?

No hay un número. En nuestra muestra, webs con 2 y con 15 plugins visibles respondían en tiempos parecidos. Lo que importa es qué carga cada uno y dónde: un solo plugin que añade 300 KB de JavaScript a todas las páginas pesa más que diez que solo trabajan en el panel.

¿WordPress es lento de por sí?

No. Con caché de página, las webs WordPress de la muestra tenían un tiempo de servidor de 130 ms de mediana, perfectamente competitivo. WordPress es lento cuando genera cada página desde cero en cada visita, y eso tiene solución en la configuración, no en cambiar de plataforma.

¿Elementor hace lenta la web?

Añade peso: las webs con constructor cargaban 555 KB de CSS y JavaScript frente a 338 KB sin él. Pero buena parte de ese peso viene de los paquetes de complementos que se acumulan alrededor del constructor, no del constructor en sí. Consolidar complementos y usar sus opciones de carga optimizada recupera buena parte.

¿Qué plugin de caché es mejor?

El que encaje con tu servidor. En un hosting LiteSpeed, LiteSpeed Cache, porque usa el motor del propio servidor. En otros, la caché que ofrezca el hosting o WP Rocket. Más que la marca, importa comprobar después con la cabecera de respuesta que la página sale de caché.

¿Por qué mi web va rápida a mí y lenta en PageSpeed?

Porque tu navegador ya tiene guardados los archivos de la web y la conexión abierta. PageSpeed simula una visita nueva desde un móvil de gama media con una conexión normal, que es como llega la mayoría de tus clientes.

¿Tengo que rehacer la web para que vaya rápida?

Casi nunca como primer paso. En la mayoría de las webs de la muestra, activar y verificar la caché, y quitar de cada página lo que no usa, habría resuelto la mayor parte del problema sin tocar el diseño. Rehacer tiene sentido cuando la web está construida sobre un tema y un constructor tan cargados que limpiar cuesta más que empezar de nuevo.

En una frase

Tu WordPress no va lento por tener muchos plugins: va lento porque genera cada página desde cero en cada visita y porque sus plugins cargan en todas las páginas cosas que solo hacen falta en una. Lo primero se arregla con una caché que funcione de verdad; lo segundo, mirando qué carga cada página, no contando cuántos plugins hay instalados.

Lanza los dos curl de este artículo contra tu portada. Si no ves un HIT, ya sabes por dónde empezar. Y si prefieres que lo miremos nosotros, en desarrollo WordPress hacemos exactamente este diagnóstico, o cuéntanos qué tienes y te decimos qué arreglaríamos primero y qué esperar de cada cosa.

Fuentes

• web.dev — Time to First Byte (TTFB), definición de la métrica y umbral de 800 ms.
• Contact Form 7 — Loading JavaScript and stylesheet only when it is necessary, filtros wpcf7_load_js y wpcf7_load_css.
• Cloudflare — Default cache behavior, por qué el HTML no se cachea por defecto.
• LiteSpeed — LSCache for WordPress, caché de página integrada en servidores LiteSpeed.
• Medidas propias: rastreo de 623 webs corporativas (554 respondieron, 331 WordPress) de Argentina, Colombia, Perú y República Dominicana, el 24 de septiembre de 2026. Plugins y peso medidos sobre el HTML de la portada; TTFB con curl desde España, mediana de tres peticiones por web.