Qué hago realmente cuando un sitio WordPress va lento: mi checklist básico de velocidad para 2026

Cuando alguien dice “WordPress es lento”, casi nunca se trata de un solo problema.
Normalmente es una mezcla de tema, plugins, imágenes, fuentes, hosting y varias decisiones antiguas de las que nadie se acuerda.

En esta nota no voy a decirte “instala un plugin de caché y listo”.
En su lugar, voy a mostrar el checklist básico que utilizo cuando empiezo a trabajar con un sitio WordPress lento en 2026.

Paso 1. Medir antes de tocar nada

Antes de cambiar algo necesito ver números reales.

Suelo hacer lo siguiente:

• Abrir el sitio en Chrome y ejecutar Lighthouse / PageSpeed Insights.

• Revisar Core Web Vitals en Search Console (LCP, INP, CLS) con datos de usuarios reales.

• Mirar DevTools → Network para ver

  • cuánto pesa la página,

  • cuántas peticiones JS/CSS hace,

  • cuáles son las más lentas.

El objetivo no es conseguir “100/100”, sino entender:

• dónde se pierde el tiempo antes del contenido principal (LCP);

• si los bundles de JS son tan pesados que afectan la interacción (INP);

• si hay cambios bruscos de maquetación (CLS).

Sin esta foto, cualquier optimización es puro ensayo y error.

Paso 2. Tema: lo primero que reviso

Si los Core Web Vitals se ven mal, el primer sitio donde miro es el tema.

Reviso:

• Cuántos archivos CSS y JS carga el tema en una página típica.

  • Si hay uno o dos theme.js / vendor.js enormes en todas las vistas.

  • Si hay librerías antiguas que podrían eliminarse.

• Si hay animaciones, sliders o vídeos en el hero que pesen demasiado.

• Cómo están organizadas las plantillas:

  • si todos los scripts se cargan en todas las páginas,

  • o si se podrían limitar a ciertas plantillas.

En la práctica esto suele significar:

• Quitar scripts innecesarios con wp_dequeue_script donde no hacen falta.

• Sustituir un slider pesado en el hero por una sola imagen estática.

• Dividir un main.js gigante en partes más pequeñas y cargarlas de forma condicional.

Paso 3. Plugins: quién está frenando el sitio

La segunda fuente típica de problemas son los plugins.

Mi proceso:

1. Revisar la lista de plugins activos y marcar los sospechosos habituales: page builders grandes, sliders visuales, varios plugins de SEO o analítica.

2. En DevTools → Network, relacionar archivos JS/CSS con plugins concretos.

3. Ver si se puede:

   • cambiar un plugin “todo en uno” por alternativas más ligeras;

   • desactivar módulos que no se usan;

   • limitar la carga de scripts solo a las páginas que realmente necesitan esa funcionalidad.

Muchas veces basta con:

• eliminar uno o dos plugins pesados;

• quitar duplicados (dos plugins para el mismo problema);

• configurar carga condicional (por ejemplo, scripts de formularios solo en páginas con formulario).

Paso 4. Imágenes, fuentes y vídeo

Ni el mejor tema ni la mejor selección de plugins te van a salvar si:

• las imágenes del hero están subidas en 3000 px directamente desde el diseño;

• cada sección usa su propia imagen de fondo a pantalla completa “porque queda bonito”;

• la página carga 3 o 4 familias de fuentes con múltiples pesos.

Lo que hago aquí:

• Identificar las imágenes clave (hero, tarjetas, galerías) y optimizarlas:

  • ancho adecuado para el layout,

  • formato moderno (WebP / AVIF cuando se pueda),

  • width/height correctos y loading="lazy" donde tenga sentido.

• Revisar las fuentes:

  • cuántas familias y pesos se usan;

  • si se pueden reducir a 1–2 combinaciones bien pensadas.

• Si hay vídeo en el hero, moverlo más abajo o cambiarlo por una imagen/poster.

Aquí es fácil recuperar 0,5–1 segundo de LCP sin tocar la arquitectura a fondo.

Paso 5. Caché, hosting y “higiene básica”

Solo después de tema, plugins y medios, miro:

• Hosting – tiempo de respuesta del servidor, soporte de HTTP/2 o HTTP/3, si el plan compartido está claramente saturado.

• Caché – si hay un buen page cache / object cache, o si varios plugins de caché se pisan entre sí.

• Higiene básica de WordPress – revisiones excesivas, autosaves, demasiadas tareas de cron, etc.

Aquí tampoco hay magia: a veces la solución correcta es migrar a un hosting mejor o dejar un solo sistema de caché bien configurado en lugar de tres.

Mini caso: de 3–4 segundos a menos de 2

Para que no suene abstracto, un ejemplo real (sin nombres):

• Página: home corporativa en WordPress.

• Estado inicial:

  • LCP de ~3,5–4 s en móvil;

  • unas 130 peticiones;

  • slider pesado en el hero + varias animaciones;

  • más de 20 plugins activos.

Primeras acciones:

1. Tema

   • Eliminar el slider del hero y dejar una sola imagen optimizada.

   • Desactivar algunas animaciones decorativas sin impacto real en el contenido.

2. Plugins

   • Quitar un plugin grande “todo en uno” cuyos módulos se solapaban con el tema.

   • Cambiar un formulario desde un form‑builder pesado a una solución más ligera.

3. Medios y fuentes

   • Reexportar las imágenes clave en WebP con tamaños más razonables.

   • Reducir el número de familias de fuentes y pesos.

Resultado después de este primer repaso:

• LCP en móvil bajó a ~1,7–1,9 s;

• el número total de peticiones se redujo de forma notable;

• no fue necesario aplicar trucos agresivos ni hacks arriesgados.

Más tarde ajustamos la caché y algunos detalles, pero el mayor salto vino precisamente de este checklist.

Cuando el checklist se queda corto

A veces:

• el sitio lleva años sobre una arquitectura compleja;

• hay integraciones personalizadas, plugins propios, lógica poco habitual;

• los problemas de rendimiento vienen de consultas pesadas a la base de datos o de código PHP complejo.

En esos casos hay que ir más a fondo: perfilar consultas, auditar el código PHP y, en algunos proyectos, rediseñar partes de la arquitectura.

Aun así, casi siempre empiezo con este checklist básico.
Si lo recorres con honestidad, en la mayoría de los proyectos ya se nota la diferencia, tanto en los Core Web Vitals como “a ojo” cuando navegas por el sitio.