Respuesta directa
Casi todos los WordPress lentos lo son por una de cinco causas, y se pueden distinguir en media hora sin ser técnico: imágenes sin procesar, complementos que cargan en todas las páginas, fuentes que bloquean, caché mal configurada o un alojamiento que tarda en responder. La sexta causa, menos frecuente y más cara de arreglar, es una plantilla mal construida.
Antes de tocar nada, medir
La primera medición es la referencia de todo el trabajo. Sin ella no hay forma honesta de decir si algo ha servido.
Se mide en móvil, no solo en escritorio, y sobre las páginas que reciben tráfico real: la portada, la de servicios más visitada, una ficha o un artículo. Medir solo la portada es el error clásico, porque suele ser la página más cuidada.
Y conviene separar dos cosas que se confunden constantemente. Los datos de laboratorio simulan una carga en un dispositivo concreto: son reproducibles y sirven para comparar antes y después. Los datos de campo vienen de usuarios reales, con sus móviles y sus conexiones: son los que importan y los que Google considera.
Una web puede tener 95 en laboratorio y datos de campo malos porque sus visitantes entran desde móviles antiguos con cobertura irregular.
Causa 1: las imágenes
Es la primera en frecuencia y la más fácil de comprobar. Si tu portada pesa más de dos megabytes, ahí está el problema.
Las tres cosas que suelen faltar: generar varios tamaños para que el navegador elija según la pantalla, servir formatos modernos como AVIF o WebP, y declarar ancho y alto para que la página no dé saltos mientras carga.
Cómo comprobarlo sin herramientas: abre la web en el móvil con datos, no con wifi. Si las imágenes aparecen por partes o tardan visiblemente, es esto.
Causa 2: los complementos
El patrón habitual: veinte o treinta complementos instalados, y una parte carga su CSS y su JavaScript en todas las páginas aunque solo se use en una. Un plugin de formularios cargando en la portada, un carrusel cargando en el aviso legal.
También pesan los que ya no usas pero siguen activos, y los que duplican funciones entre sí.
Cómo comprobarlo: revisa cuántos hay activos y cuántos recuerdas para qué son. Si no sabes qué hace uno, ese es candidato.
Causa 3: las fuentes
Fuentes cargadas desde un servicio externo bloquean el renderizado del texto. El visitante ve un hueco en blanco donde debería haber contenido, aunque el HTML ya haya llegado.
La solución habitual es servirlas desde tu propio dominio, limitar los pesos a los que de verdad usas y declarar un comportamiento de intercambio para que el texto aparezca con una fuente de sistema mientras carga la definitiva.
Causa 4: la caché
Sin caché, WordPress reconstruye cada página en cada visita consultando la base de datos. Con caché bien configurada, sirve un HTML ya generado.
Es de lo primero que hay que revisar y de lo que da más resultado por menos esfuerzo. Pero es entrega, no origen: no arregla un peso excesivo ni un servidor lento, solo evita repetir trabajo.
Causa 5: el alojamiento
La que nadie quiere oír. Si el servidor tarda un segundo en empezar a responder, has perdido un segundo antes de que exista la posibilidad de optimizar nada.
Es especialmente común en alojamiento compartido muy barato, donde tu web comparte recursos con cientos de otras y el rendimiento depende de lo que hagan las demás.
Cuando la medición apunta aquí, la recomendación honesta es cambiar de alojamiento antes de pagar por una optimización que va a rendir poco. Es lo que hago en estos casos, aunque signifique no facturar el trabajo de optimización.
La base de datos, y lo que no suele ser
Si la web lleva años, la base de datos puede arrastrar revisiones de entradas, datos de complementos desinstalados y tablas huérfanas. Limpiarla ayuda, siempre con copia previa. Pero rara vez es la causa principal, y hay bastante gente vendiendo esto como la solución mágica.
Cuándo optimizar no es la respuesta
Si el objetivo solo se alcanza cambiando la plantilla o el constructor, la vía es otra: una migración de Elementor a Bricks o un rediseño. Optimizar sobre una base mal construida tiene un techo bajo.
Y una advertencia que ya desarrollé en por qué una web rápida no es suficiente: arreglar la velocidad quita fricción, pero no genera demanda. Si tu web recibe treinta visitas al mes, el problema no es que tarde tres segundos.
Siguiente paso
Puedes ver cómo trabajo esto en optimización de velocidad, con medición antes y después bajo los mismos criterios. Si prefieres un diagnóstico más amplio que incluya indexación y arquitectura, eso es una auditoría SEO técnica.
Y si no tienes claro cuál de las cinco causas es la tuya, cuéntame cómo está la web en el estudio de proyecto y te digo por dónde empezaría.