WordPress lento se detecta con un diagnóstico de velocidad en orden, no instalando otro complemento. Un sitio que tarda más de tres segundos en el teléfono pierde lectores antes del primer párrafo. La causa casi nunca es una sola: es una cadena, y cada eslabón se revisa en su turno.
El error más caro es empezar por el final. Muchos dueños cambian el tema, pagan un plan mayor o instalan un optimizador antes de medir nada. Gastan dos veces. Medir primero cuesta minutos: una prueba de carga con el teléfono, en datos móviles, dice más que diez opiniones de foro.
El tiempo que importa tiene nombre técnico: TTFB, el tiempo hasta el primer byte, es decir, lo que el servidor tarda en empezar a responder. Si ese primer paso ya supera un segundo, el problema vive en el alojamiento o en el propio WordPress, no en el diseño visible.
Primero el alojamiento y el tema, después los plugins
El alojamiento compartido barato reparte el mismo procesador entre decenas de sitios. A las horas de más visitas, cada página compite por ese recurso y la respuesta se arrastra. Una señal clara: el sitio vuela a las tres de la mañana y se frena al mediodía, con el mismo contenido.
El tema manda en segundo lugar. Un tema cargado de animaciones, deslizadores y constructores visuales añade hojas de estilo y scripts a cada página, se usen o no. Cambiar a la portada de un tema básico del repositorio oficial, en una copia de prueba, revela en minutos cuánto peso aporta el diseño.
Los plugins llegan terceros en este diagnóstico de velocidad, y con método. Se desactivan en la copia de prueba, nunca en el sitio vivo, y se reactivan de uno en uno midiendo tras cada paso. El culpable habitual no es el número total: un solo plugin mal hecho frena más que veinte ligeros.
Esa revisión ordenada tiene historia en el archivo propio: la guía de seis plugins gratuitos para acelerar un sitio de WordPress, publicada en 2014, ya separaba los complementos de caché y de imágenes del resto. Doce años después la lista cambió; el criterio de medir antes de instalar sigue intacto.
Hay plugins que cargan recursos en todo el sitio aunque solo se usen en una página. Un formulario de contacto que añade su código a la portada, o una tienda que despierta en un blog sin ventas, pagan peaje en cada visita. Restringir cada complemento a su página recorta segundos reales.
Imágenes, base de datos y el mantenimiento que nadie ve
Las imágenes pesan más que todo el texto junto. Una foto de portada de 4.000 píxeles subida tal cual desde el teléfono puede pasar de 3 MB; convertida a WebP y recortada a 1.600 píxeles de ancho baja a una fracción, con la misma apariencia en pantalla. Ese cambio solo ya acelera la portada.
La base de datos guarda peso muerto con los años. Cada borrador crea revisiones, cada desinstalación deja tablas huérfanas y los comentarios de spam se acumulan por miles. Limitar las revisiones guardadas a cinco por artículo y vaciar la papelera de comentarios una vez al mes mantiene las consultas rápidas sin tocar contenido.
Las tareas programadas también frenan. WordPress ejecuta trabajos internos, el cron, cuando llega una visita; en sitios con poco tráfico esos trabajos se amontonan y la primera visita del día paga la cuenta completa. Programar esa ejecución en el servidor, cada cinco minutos, reparte el trabajo y nivela la respuesta.
La versión de PHP, el lenguaje en el que corre WordPress, mueve la aguja sin tocar el diseño. Cada versión mayor reciente procesa más peticiones por segundo con el mismo servidor, y los alojamientos permiten cambiarla desde el panel en minutos. Actualizarla con la copia de prueba abierta evita sorpresas con temas viejos.
¿Cómo saber si el problema es el alojamiento? Si el panel de administración también responde lento, con el tema básico activo y los plugins apagados en la copia de prueba, el servidor quedó chico. Ningún ajuste de caché compensa un procesador saturado por decenas de vecinos.
¿Cuántos plugins son demasiados en un WordPress lento? No existe una cifra mágica: existe el peso medido de cada uno. Un sitio con treinta complementos ligeros y bien escritos carga más rápido que otro con doce donde dos inyectan scripts en cada página. La medición manda sobre el conteo.
¿La caché sustituye al diagnóstico de velocidad? No. La caché entrega copias listas de páginas ya armadas y disimula casi todo, hasta que un lector llega a una página sin copia o entra al panel. Arreglar la causa primero y cachear después deja un sitio rápido también para quien publica.
El orden completo cabe en una tarde: medir el TTFB, probar el tema básico, apagar plugins de uno en uno, comprimir las imágenes grandes y limpiar la base de datos. Cada paso deja un número anotado. Ese registro, y no una impresión, dice qué arreglo devolvió los segundos perdidos.
