Respuesta directa: mide antes de optimizar
Un WordPress lento no se arregla de forma segura acumulando optimizadores. Primero hay que medir y separar las capas: DNS y red, tiempo hasta el primer byte (TTFB), page cache, ejecución de PHP y base de datos, plugins y tema, tareas programadas y trabajo del navegador. Después se cambia una sola variable, se repite la misma prueba y se conserva una ruta de vuelta.
Esta guía propone 12 comprobaciones reales en ese orden lógico. No presupone que el hosting, un plugin o WordPress sean culpables. Tampoco promete una cifra universal: un catálogo, una tienda WooCommerce y un área privada tienen cargas y límites distintos. La documentación oficial de rendimiento de WordPress también plantea la optimización como un trabajo sobre varias capas.
Qué significa realmente que WordPress esté lento
La palabra lento puede describir problemas diferentes. Un TTFB alto indica que la respuesta inicial tarda en llegar, pero todavía hay que distinguir red, cola de PHP, consultas y caché. Un Largest Contentful Paint (LCP) malo puede proceder de la imagen principal, fuentes, CSS o JavaScript aunque el HTML llegue pronto; por sí solo no demuestra que el hosting sea lento. Si solo falla wp-admin, la page cache pública casi nunca explica el problema, porque las sesiones autenticadas suelen evitarla. Si la lentitud coincide con importaciones, copias o picos de tráfico, hay que mirar recursos y concurrencia.
La experiencia de página combina señales técnicas y utilidad; Google recomienda no reducirla a una sola métrica ni crear contenido solo para buscadores en sus guías de experiencia de página y contenido útil. Aquí usaremos las métricas para localizar una capa, no como un fin aislado.
Antes de tocar nada: recuperación y línea base
Confirma que existe una copia verificable de archivos y base de datos, preferentemente fuera del servidor, y que sabes restaurarla. Una copia creada dentro de la raíz pública no es un respaldo externo completo y puede exponer datos. Para pruebas de plugins, tema o configuración utiliza staging. Si no existe, reserva una ventana controlada, registra el estado inicial y define quién ejecutará el rollback.
Construye una línea base con dos o tres URL representativas: portada o landing cacheable, una entrada y una vista dinámica relevante. En WooCommerce añade producto, carrito o cuenta sin realizar operaciones reales. Usa la misma región, dispositivo, sesión y condiciones; repite varias veces. Registra fecha, URL, estado autenticado, código HTTP, DNS, conexión, TTFB, tiempo total y resultado visual. La primera visita puede encontrar cachés frías; las siguientes, cachés calientes. Compararlas es más informativo que elegir el mejor intento.
Los comandos de esta guía están documentados, pero no se ejecutaron en el VPS del lector. Adapta dominio, rutas, permisos y entorno; no pegues comandos sin entenderlos. Esta medición con curl descarga la respuesta y descarta el cuerpo. Una sola ejecución no basta:
curl -o /dev/null -sS -w 'HTTP %{http_code}\nDNS completado %{time_namelookup}s\nTCP conectado %{time_connect}s\nPrimer byte %{time_starttransfer}s\nTotal %{time_total}s\n' https://example.com/pagina-de-prueba/Del síntoma a la siguiente prueba
| Síntoma | Capa probable | Prueba siguiente |
|---|---|---|
| TTFB alto tanto en frío como en caliente | Origen, PHP, base de datos o cola de workers | Comparar caché, logs, recursos y una URL estática |
| Primera visita lenta; repeticiones rápidas | Caché fría o generación dinámica | Revisar cabeceras y política de page cache |
| TTFB razonable; LCP tardío | Imagen, fuente, CSS o JavaScript | Inspeccionar cascada y elemento LCP |
Solo wp-admin es lento | Plugins, consultas, cron o API externa | Staging, logs y tareas programadas |
| Lentitud durante copias o importaciones | CPU, memoria, disco/I/O o procesos externos | Correlacionar horario con métricas del servidor |
| Una región falla y otra no | Ruta de red, DNS o CDN | Repetir desde regiones y comparar origen/edge |
Las 12 comprobaciones
Comprobación 1. Mide TTFB y tiempo total de forma repetible
Ejecuta la línea base varias veces por URL y conserva todos los resultados, no solo el más rápido. time_namelookup, time_connect, time_starttransfer y time_total son hitos acumulados desde el inicio de la petición: indican cuándo terminó la resolución DNS, cuándo se estableció TCP, cuándo llegó el primer byte y cuándo terminó la transferencia. No los interpretes como fases aisladas sin calcular sus diferencias. Compáralos con una URL estática del mismo origen: si la estática es rápida y el HTML dinámico no, la red deja de ser la única sospechosa.
Prueba como visitante y, por separado, como usuario autenticado. Mantén región y protocolo. Un TTFB variable puede señalar cola, tareas intermitentes o caché; un TTFB estable no explica necesariamente el renderizado. La guía oficial de optimización de WordPress ayuda a situar servidor, base de datos y recursos del navegador en el mismo diagnóstico.
Comprobación 2. Revisa Site Health, versiones y estado antes de añadir herramientas
En Herramientas → Salud del sitio, anota incidencias críticas y recomendaciones, versiones de WordPress y PHP, módulos, límites y directorios. Usa la información como señal, no como veredicto: resuelve primero errores claros y confirma compatibilidad antes de actualizar. El núcleo implementa estas pruebas mediante WP_Site_Health.
Si dispones de WP-CLI, crea un inventario reproducible. Estos comandos oficiales de WP-CLI son de lectura y sirven para capturar el inventario y las próximas tareas sin ejecutar eventos vencidos:
wp core version
wp plugin list --status=active
wp theme list --status=active
wp cron event list --fields=hook,next_run_relative,recurrence
wp db size --tables --human-readableGuarda la salida con el ticket o registro de cambios, sin publicar rutas, usuarios ni datos del servidor.
Comprobación 3. Distingue caché fría, caché caliente y page cache
Haz una petición tras purgar únicamente la capa que controlas y varias repeticiones sin purgar. Revisa cabeceras como Age, Cache-Control o la cabecera específica del proveedor, pero no asumas que todos usan los mismos nombres. Una mejora grande después de la primera carga sugiere caché caliente; resultados siempre dinámicos pueden revelar una exclusión intencional, una cookie o una configuración incompleta.
La page cache guarda la respuesta HTML completa y puede evitar trabajo repetido de PHP y base de datos. No es lo mismo que object cache. WordPress documenta ambas en su guía de caché, y Site Health dispone de una prueba específica de page cache. Mantén un solo responsable de page cache y una política de purga clara; apilar plugins o capas sin conocer su orden provoca inconsistencias. Carrito, pago, cuenta y otras vistas personalizadas deben conservar sus exclusiones.
Comprobación 4. Aísla plugins activos con una prueba controlada
Usa el inventario de plugins para localizar los que actúan en cada petición: seguridad, redirecciones, analítica, constructores, búsqueda, traducción o llamadas a APIs. Revisa también mu-plugins y extensiones del proveedor. Una correlación no basta; hay que observar qué cambia al retirar una variable.
Hazlo solo en staging o, si no hay alternativa, durante una ventana controlada con copia, modo de mantenimiento apropiado, lista exacta de plugins activos y rollback preparado. Desactiva uno cada vez o grupos razonados, repite las mismas URL y comprueba funciones críticas. Si no hay mejora reproducible, reactiva inmediatamente el conjunto original. No pruebes a ciegas en producción ni dejes una tienda sin pagos, seguridad o copias. Si aparece una vulnerabilidad, sigue una guía de respuesta específica, como la nota de Teramont sobre WP2Shell y WordPress, en vez de convertir el diagnóstico de velocidad en una limpieza improvisada.
Comprobación 5. Compara el tema, el child theme y sus assets
Un tema puede añadir consultas, plantillas complejas, fuentes, sliders y paquetes de scripts. En staging, registra el tema y child theme activos, crea una captura visual y prueba temporalmente un tema oficial compatible. Repite la línea base, incluido móvil y plantillas clave. Si mejora, no concluyas que todo el tema es defectuoso: compara plantilla, funciones del child theme y assets para acotar la causa.
El rollback consiste en reactivar el tema y child theme originales, restaurar sus ajustes y purgar únicamente las cachés necesarias. No cambies tema y plugins a la vez; perderías la atribución y podrías alterar widgets, menús o estilos.
Comprobación 6. Inspecciona imágenes, fuentes, CSS, JavaScript y el LCP
Identifica el elemento LCP y observa la cascada del navegador. Si el HTML llega pronto pero la imagen principal empieza tarde, pesa demasiado o compite con scripts, el cuello está en el frontend. Dimensiona imágenes para su uso real, sirve formatos adecuados cuando sean compatibles, evita cargar variantes innecesarias y no apliques lazy loading al elemento que debe aparecer de inmediato sin medir el efecto.
Reduce fuentes y pesos no utilizados, revisa CSS que bloquea el renderizado y JavaScript de terceros. Haz una modificación por despliegue y comprueba diseño, consentimiento, analítica y accesibilidad. Un plugin de minificación puede ayudar en un caso concreto, pero también duplicar lo que ya hace el hosting o romper el orden de ejecución. El objetivo es una cascada más simple y un LCP reproduciblemente mejor, no una puntuación aislada.
Comprobación 7. Detecta tareas WP-Cron largas, atrasadas o solapadas
WP-Cron se comprueba con las visitas, por lo que tareas de copias, feeds, correos, sincronizaciones o limpiezas pueden ejecutarse en momentos inoportunos o retrasarse si no hay tráfico. wp cron event list permite revisar hooks, próxima ejecución y recurrencia sin dispararlos. Evita usar runners de diagnóstico en producción sin una ventana controlada, porque pueden ejecutar eventos vencidos; después revisa con el proveedor o el propietario del plugin qué tarea consume tiempo y con qué frecuencia. La referencia oficial explica el funcionamiento de WP-Cron.
No desactives WP-Cron sin configurar y validar un sustituto del sistema. Si mueves la ejecución a cron real, documenta frecuencia, usuario, ruta y alertas; evita solapamientos y prueba correos, renovaciones y publicaciones programadas. El rollback debe restaurar el disparador anterior si aparecen tareas perdidas.
Comprobación 8. Mide base de datos y autoload sin borrar a ciegas
Empieza por el tamaño por tablas con el inventario de WP-CLI y compáralo en el tiempo. Revisa qué plugin es propietario de tablas grandes, revisiones, sesiones o colas. Para medir realmente autoload, agrupa las filas de la tabla de opciones por su valor de autoload; WordPress moderno puede usar más estados que yes y no. Esta consulta es de lectura y el tamaño resultante es orientativo, no una lista de filas seguras para borrar:
¿Tu WordPress necesita un entorno más estable?
Explora hosting web con soporte para WordPress y recursos pensados para sitios que necesitan crecer.
wp db query "SELECT autoload, COUNT(*) AS row_count, ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mib FROM $(wp db prefix)options GROUP BY autoload ORDER BY mib DESC;"Las opciones con autoload se cargan en muchas solicitudes; un conjunto excesivo puede añadir memoria y trabajo, pero el total no identifica qué fila se puede eliminar. La API oficial de opciones explica el papel del autoload.
Antes de cualquier cambio de datos, crea previamente un directorio privado fuera del document root, propiedad del usuario que ejecuta WP-CLI, y exporta allí la base; adapta la ruta y no la crees dentro de public_html, htdocs ni www. Este archivo local no sustituye una copia externa verificada:
wp db export /srv/wordpress-private-backups/backup-before-performance-changes.sql
chmod 600 /srv/wordpress-private-backups/backup-before-performance-changes.sqlNo borres options, transients, tablas ni filas por nombre parecido. Identifica propietario y dependencia, prueba en staging y valida restauración. Tampoco ejecutes OPTIMIZE TABLE o reparación como rutina: requieren necesidad demostrada, copia y ventana controlada.
Comprobación 9. Decide si una object cache persistente aporta
La object cache almacena resultados y objetos reutilizables; una implementación persistente puede conservarlos entre solicitudes. Redis o Memcached pueden reducir trabajo repetido en sitios dinámicos con consultas recurrentes, pero no corrigen JavaScript pesado, imágenes grandes, consultas únicas ni un origen sin recursos. Exigen soporte del hosting, extensión, drop-in compatible, memoria, política de expulsión y observabilidad.
Primero confirma una carga de base de datos repetitiva y revisa la prueba oficial de caché de objetos persistente. Activa una sola implementación en staging, mide aciertos, errores y memoria con las herramientas del proveedor, y prueba invalidaciones tras editar contenido. Si empeora, retira el drop-in/configuración y restaura la capa previa; no presentes Redis como requisito universal.
Comprobación 10. Revisa PHP workers, memoria y errores sin exponerlos
Las respuestas dinámicas ocupan workers de PHP. Cuando todos están ocupados, las solicitudes esperan aunque la CPU media parezca moderada. Correlaciona concurrencia, colas, timeouts y reinicios con las horas lentas. El límite de memoria de PHP es por proceso y no equivale a la RAM total; aumentarlo sin conocer workers y consumo puede agravar la presión. No hay un valor universal: depende del código, tráfico y límites del plan.
Consulta primero los logs privados del servidor y de PHP. Si necesitas el log de WordPress, habilítalo solo temporalmente en staging o durante una ventana vigilada. La documentación de wp-config.php define estas constantes:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY=false evita mostrar errores en la página. Crea antes la ruta de log fuera del document root con propietario y permisos mínimos para el proceso PHP; el archivo aún puede contener rutas, consultas o datos sensibles. Al terminar, desactiva el debug y elimina o archiva de forma segura el log. Nunca lo dejes público.
Comprobación 11. Correlaciona CPU, RAM, disco/I/O y procesos externos
Consulta las gráficas del panel o pide al proveedor métricas del mismo intervalo de la línea base: CPU, memoria, espera de I/O, uso de disco, procesos, límites alcanzados y reinicios. Mira percentiles o series, no solo una media diaria que oculte picos. Relaciona cada pico con logs y trabajos: copia de seguridad, escáner, importación, generación de miniaturas, búsqueda, correo o vecino ruidoso en un entorno compartido.
Pausa o reprograma un proceso únicamente si conoces su función y mantienes su cobertura. Una copia que satura I/O puede moverse de horario, pero eliminar copias no es una optimización aceptable. Si el sitio alcanza de forma sostenida límites del plan después de corregir código y configuración, ya existe evidencia para hablar de capacidad.
Comprobación 12. Separa CDN, DNS y ruta de red del origen
Repite las URL desde más de una región y compara DNS, conexión, TTFB y total. Comprueba resolución, TLS, cabeceras de caché y si la respuesta viene del edge o del origen. Después compara, de forma autorizada, una ruta directa al origen manteniendo el mismo Host y seguridad; el proveedor puede ayudar sin exponer la IP pública.
Una CDN puede acercar assets y, si está bien configurada, páginas públicas cacheables. No arregla por sí sola wp-admin, PHP, consultas lentas ni endpoints personalizados; una regla errónea incluso puede servir contenido privado o obsoleto. DNS influye sobre todo al resolver y la red puede variar por región. Cambia una sola regla, conserva TTL y configuración anterior, y valida purga, cookies, sesión y contenido. CDN y VPS son decisiones de arquitectura, no botones mágicos.
Orden seguro para corregir sin perder la causa
- Guarda la línea base, el inventario, la copia verificable y el procedimiento de restauración.
- Corrige errores reproducibles y compatibilidad; vuelve a medir antes de añadir una capa.
- Configura un solo sistema de page cache y sus exclusiones, si la página puede cachearse.
- Optimiza el elemento LCP y los assets identificados, no todos a la vez.
- Aísla plugin o tema en staging y restaura el estado inicial después de cada prueba.
- Ordena cron y datos solo con propietario, necesidad y rollback claros.
- Añade object cache o capacidad únicamente cuando la evidencia apunte a consultas o saturación.
- Ajusta CDN y red al final del diagnóstico del origen y vuelve a probar regiones.
En cada paso registra hipótesis, cambio, responsable, hora, resultado y reversión. Si una mejora no se repite bajo las mismas condiciones, todavía no es una conclusión.
Cuándo optimizar, cambiar de plan o migrar
| Decisión | Señal suficiente | Qué validar |
|---|---|---|
| Seguir optimizando | Hay margen de recursos y el cuello se atribuye a assets, consultas, plugin, tema o configuración | La corrección mejora la misma prueba sin regresiones |
| Cambiar de plan | Workers, memoria o I/O alcanzan límites de forma sostenida tras optimizar | Qué límite aumenta, observabilidad, coste y rollback |
| Migrar de plataforma | La carga necesita aislamiento, control o arquitectura que el entorno actual no ofrece | Staging, DNS, correo, copias, ventana, prueba funcional y vuelta atrás |
Quédate en hosting compartido si cumple la carga, las cachés funcionan y existe margen. Un plan superior puede resolver capacidad, no código ineficiente. Un VPS aporta aislamiento y control, pero también administración; no es automáticamente más rápido. Si necesitas contexto, consulta qué es un VPS y para qué sirve. Para una opción administrable orientada a sitios WordPress, revisa el Web Hosting de Teramont y contrasta sus características actuales con tu diagnóstico.
Verificación final y rollback
Repite las mismas URL, regiones, dispositivo y estado de sesión. Mide varias pasadas frías y calientes; comprueba código HTTP, TTFB, total, LCP y errores. Recorre login, edición, formularios, búsqueda y, si aplica, producto, carrito, pago, cuenta, webhooks y correos. Revisa logs y métricas durante un intervalo comparable, no solo inmediatamente después del despliegue.
Define el éxito antes del cambio: menor demora en la capa objetivo, comportamiento correcto y ausencia de nuevos errores. Si el resultado empeora, se vuelve variable o rompe una función, ejecuta el rollback previsto: revierte exactamente ese cambio, restaura configuración o snapshot cuando corresponda, purga solo las capas afectadas y repite la línea base. Conserva el registro incluso si la hipótesis fue falsa.
Preguntas frecuentes
¿Qué plugin de caché debo instalar?
El compatible con tu hosting y con una responsabilidad clara. Comprueba primero si el servidor ya proporciona page cache. No apiles plugins que minifican, cachean o purgan lo mismo; configura uno, documenta exclusiones y mide.
¿Por qué WooCommerce exige más cuidado?
Carrito, pago, cuenta, sesiones, stock y webhooks son dinámicos. Exclúyelos de page cache según la integración, prueba compras en staging y verifica invalidación. Una portada rápida no demuestra que el flujo transaccional esté sano.
¿Por qué wp-admin sigue lento si la web pública está rápida?
La parte pública puede servirse desde page cache, mientras el admin ejecuta PHP, consultas, permisos y llamadas externas en cada solicitud. Revisa plugins, cron, logs, base de datos y workers con una sesión de prueba.
¿Una CDN o un VPS acelerarán WordPress?
Solo si resuelven la capa medida. La CDN ayuda con distancia y contenido cacheable; el VPS con aislamiento o control cuando está bien dimensionado y administrado. Ninguno sustituye corregir consultas, plugins o frontend.
Conclusión
Empieza hoy con una URL pública y una dinámica: guarda copia, ejecuta varias mediciones, compara frío y caliente y usa la tabla para elegir la siguiente capa. Continúa con una sola de las 12 comprobaciones cada vez. Esa disciplina convierte “WordPress está lento” en una hipótesis verificable, una corrección reversible y una decisión de hosting basada en evidencia.
