¿La web cae solo unos minutos, o la lentitud vuelve a la misma hora cada día? En WordPress, esa diferencia cambia por completo el diagnóstico: puede ser un pico de tráfico, una tarea programada, un plugin mal optimizado o una limitación persistente en servidor o base de datos.
Resumen del proceso
- Comprueba si la lentitud dura minutos o se repite cada día.
- Revisa CPU, RAM, disco, red, TTFB y errores en el mismo intervalo.
- Correlaciona logs, alertas y tareas programadas de WordPress.
- Aísla la capa afectada: servidor, base de datos, aplicación o terceros.
- Aplica una corrección corta si es un pico. Escala o aligera si es un cuello persistente.
Si el sitio solo se ralentiza en horas concretas, piensa primero en carga temporal. Si la lentitud no afloja ni en horas valle, suele haber un límite fijo detrás.
Paso 1: confirma el patrón y separa pico de bloqueo
Un pico puntual se nota, molesta y luego baja. Un cuello de botella persiste, como una puerta estrecha por la que pasa demasiada gente.
Empieza mirando tres cosas: cuándo ocurre, cuánto dura y si se repite. Si la caída aparece solo durante copias de seguridad, envíos masivos o actualizaciones, el problema suele ser temporal.
Mira la ventana horaria
Abre la gráfica de rendimiento y marca el intervalo exacto. Busca si el problema coincide con cron de WordPress, imports, indexación o campañas.
Compara días parecidos
Revisa un día normal y otro con fallo. Si el salto solo aparece en una franja concreta, la pista apunta a pico.
Usa una frase guía
Si el problema aparece y desaparece, busca el disparador; si se queda, busca el límite.
Paso 2: cruza métricas, logs y alertas
Las métricas dicen qué pasó. Los logs dicen dónde empezó. Las alertas dicen cuándo cruzó la línea.
Revisa CPU, RAM y disco
Mira si la CPU se acerca al máximo durante el fallo. Comprueba también la RAM y el uso de disco.
Busca latencia y pérdida de paquetes
La red también cuenta. Una latencia alta o pérdida de paquetes puede parecer un problema de WordPress cuando en realidad es un transporte lento entre navegador, servidor y CDN.
Lee los logs en la misma franja
Abre los registros de servidor, PHP y WordPress en el mismo minuto del pico. Busca errores 500, timeouts, consultas largas o llamadas repetidas a una API externa.
Paso 3: aísla la capa que frena todo y detecta el cuello de botella
Cuando la evidencia está sobre la mesa, toca separar capas para identificar qué está ralentizando el sitio.
Servidor: CPU, RAM y disco
Si la CPU se satura, las peticiones esperan turno. Si la RAM se agota, el servidor empieza a pelear por memoria. Si el disco va lento, todo se vuelve pesado.
Base de datos: queries lentas
MySQL o MariaDB suelen delatarse por consultas que tardan más de lo normal. Aquí encajan la optimización de base de datos, la limpieza de tablas y la revisión de índices.
Aplicación: plugins y temas
Un plugin que consulta una API en cada carga puede frenar todo el sitio. Un tema pesado también puede sumar trabajo inútil a cada visita.
Terceros: CDN y APIs externas
La CDN acelera la entrega de contenido estático, como imágenes o archivos CSS. Si falla, el sitio puede seguir vivo, pero se vuelve torpe.
| Capa |
Señal típica |
Qué hacer primero |
| Servidor |
CPU alta, RAM al límite, disco lento |
Revisar recursos, procesos y estado del servidor |
| Base de datos |
Consultas lentas, bloqueos, tablas grandes |
Optimizar base de datos, limpiar tablas, revisar índices |
| Aplicación |
Plugins o temas pesados, llamadas innecesarias |
Desactivar lo sospechoso y medir impacto |
| Terceros |
CDN lenta, APIs externas con fallos |
Comprobar dependencias y tiempos de respuesta |
La clave es aislar primero la capa con síntomas más claros y actuar sobre ella antes de seguir con otras pruebas.
Paso 4: ordena acciones según impacto real
No todo merece tocarse al mismo tiempo.
Cuando el fallo es breve
Desactiva tareas pesadas en la franja crítica. Retrasa copias, reduce indexaciones y revisa cron de WordPress si dispara procesos innecesarios.
Cuando el fallo se repite
Sube recursos si la CPU o la RAM se quedan cortas una y otra vez. Revisa PHP, MySQL y el plan de hosting si la carga sostenida ya no cabe en el entorno.
Cuando el fallo mezcla causas
Empieza por lo que bloquea más visitas. Si una query lenta frena el checkout, arregla eso antes que cualquier ajuste menor de frontend.
La prioridad correcta casi nunca es “cambiar todo”, sino quitar primero el tapón que afecta a más usuarios.
Errores que arruinan el resultado
El primer error es mirar solo la velocidad de carga. Esa foto engaña, porque no muestra CPU, RAM, disco, red ni colas internas.
El segundo error es actuar sin patrón. Cambiar plugins al azar o tocar el tema por intuición suele ensuciar más la incidencia.
El tercer error es no guardar la hora exacta del fallo. Sin esa hora, no hay forma limpia de cruzar métricas con logs.
- Mirar solo el front: la web puede abrir y seguir cerca del colapso.
- No separar capas: servidor, base de datos y aplicación no fallan igual.
- Ignorar tareas programadas: cron, backups e indexación disparan picos muy reales.
- Tocar demasiado pronto: cada cambio extra complica ver la causa de verdad.
Cuándo no funciona este método / alternativas
Este método no aplica como prioridad si el sitio no muestra lentitud, error 500, timeouts, caída en horas concretas o alertas de infraestructura. Tampoco si el problema es solo de contenido, UX o SEO, sin relación con rendimiento técnico.
Si no hay síntomas técnicos, este diagnóstico aporta poco. En ese caso conviene revisar estructura de contenidos, conversión o posicionamiento, no el servidor.
Cuando el sitio crece mucho o recibe campañas puntuales, la solución suele ser combinar caché, CDN y escalado temporal. Una sola palanca rara vez aguanta sola.
Preguntas frecuentes
¿Cómo distinguir una subida puntual de una caída sostenida?
Una subida puntual baja sola en poco tiempo. Una degradación real se repite y deja rastro en CPU, RAM, disco o TTFB. Si el problema vuelve cada día a la misma hora, el patrón ya apunta a una causa estable. Si solo aparece con copias, imports o envíos, suena más a pico.
¿Qué métrica conviene mirar primero en WordPress?
La primera métrica útil suele ser el TTFB. Si sube mucho, el servidor o la aplicación están tardando en empezar a responder. Luego conviene revisar CPU, RAM y logs en la misma franja. Así se evita culpar al navegador o al tema sin pruebas.
¿Puede un plugin causar un cuello de botella?
Sí, y es más común de lo que parece. Un plugin puede abrir consultas lentas, hacer llamadas externas o cargar trabajo en cada visita. Cuando eso pasa, el problema no se ve solo en una página. Se nota en varias rutas y en horas de más uso.
¿La caché arregla cualquier problema de rendimiento?
No. La caché ayuda mucho con picos y tráfico repetido, pero no corrige una base de datos lenta ni un hosting saturado. Si el cuello está en PHP, MySQL o disco, la caché solo tapa una parte. Por eso primero se diagnostica y luego se decide.
¿Qué hago si la lentitud aparece solo en la compra?
Revisa primero carrito, checkout y filtros. Esas partes suelen cargar más consultas y más llamadas externas. Si la lentitud solo afecta a esas páginas, el cuello suele estar en la ruta de compra, no en toda la web.
¿Cuándo merece la pena subir recursos del servidor?
Merece la pena cuando la saturación se repite y ya no responde a ajustes menores. Si la CPU, la RAM o el disco van al límite en varios días, el sitio pide más margen. Si el fallo es corto y aislado, primero conviene buscar el disparador.
¿Se puede hacer este diagnóstico sin acceso al panel?
Sí, en parte. Con acceso a gráficas básicas, registros y horario del fallo ya se puede avanzar bastante. Si no hay panel, el proveedor o el equipo técnico puede sacar la hora exacta y revisar la capa afectada. Eso ahorra muchos cambios innecesarios.
Cierre práctico para decidir bien
La mejor decisión no es la más rápida. Es la que arregla la capa correcta sin romper las demás.
Si el sitio sufre picos, recorta el disparador. Si el problema persiste, alivia el límite. Y si el patrón no está claro, vuelve a medir antes de tocar nada más.
Un buen diagnóstico ahorra más tiempo que cualquier arreglo rápido.
text
Checklist final:
- Hora exacta del fallo
- Duración del problema
- CPU, RAM, disco y red
- TTFB y errores 500
- Logs de WordPress, PHP y servidor
- Tareas programadas y plugins implicados
- Base de datos, CDN y APIs externas
