Diagnosticando WordPress lento: una metodología completa

Por qué "instala un plugin de caché" es mal consejo

La mayoría de los consejos de rendimiento WordPress que encuentras online están en el orden equivocado. La gente te dice instala WP Rocket, cambia a Cloudflare, optimiza imágenes. Todo eso es valioso — pero si lo haces antes de medir, puedes estar escondiendo un problema estructural bajo una capa fina de caché que se rompe en el momento en que ocurren cache misses.

El trabajo real de rendimiento empieza con una pregunta: ¿dónde se está gastando realmente el tiempo? Hasta que respondas eso, cada "optimización" es una adivinanza.

Abajo está la metodología que aplicamos en cada auditoría pagada de rendimiento. Toma unos 90 minutos a un ingeniero con experiencia.

Paso 1 — Establece una baseline

No puedes mejorar lo que no mides. Antes de cambiar nada, captura tres números de sesiones reales de visitantes.

Los tres que necesitas

• TTFB (Time to First Byte) — cuánto desde que se envía la petición hasta que se recibe el primer byte. Objetivo: bajo 200ms para sitios rápidos, bajo 600ms para aceptables.
• LCP (Largest Contentful Paint) — cuándo el hero/contenido principal se vuelve visible. Objetivo: bajo 2.5s.
• INP (Interaction to Next Paint) — la nueva métrica de respuesta reemplazando FID. Objetivo: bajo 200ms.

Cómo capturarlos

PageSpeed Insights, WebPageTest o Chrome DevTools Lighthouse te dan una medición de laboratorio. Real User Monitoring (RUM) — vía Cloudflare Web Analytics, Vercel Speed Insights o Plausible self-hosted — te da datos de campo de visitantes reales. Siempre confía en los datos de campo sobre los de laboratorio.

Corremos la URL auditada por PSI tres veces en 5 minutos y promediamos. Las mediciones únicas son ruidosas.

Paso 2 — Identifica qué capa tiene el cuello de botella

La lentitud de WordPress vive en una de cuatro capas. Saber cuál te ahorra optimizar lo equivocado.

El diagnóstico: pega la misma URL desde la misma red con curl -w "%{time_starttransfer}n" -o /dev/null -s. Si TTFB es alto, el problema es del lado servidor. Si TTFB está bien pero el navegador es lento, es frontend.

Paso 3 — Análisis del lado servidor

Si TTFB es el problema, profundiza en el servidor.

Los primeros 5 comandos que siempre corremos en el servidor WordPress

# CPU/memoria en vivo
htop

# Qué está consumiendo I/O activamente
iotop -o

# Picos recientes de CPU
sar -u 5 12

# Estado del pool de workers PHP-FPM
curl http://localhost/fpm-status

# Conexiones MySQL abiertas
mysql -e "SHOW PROCESSLIST" | wc -l

Estos cinco comandos responden: ¿está el servidor falto (CPU, RAM, IO), está PHP-FPM saturado, está MySQL embotellado? Sin esto, cada "optimización WordPress" es adivinanza.

Banderas rojas

• CPU sostenido sobre 80% en todos los cores → el cuello es carga PHP o MySQL
• IOwait sobre 15% → el disco es el cuello (SSD lento, disco lleno, swap)
• Workers PHP-FPM al máximo → el tráfico excede capacidad o las peticiones individuales son lentas
• Conteo de conexiones MySQL cerca de max_connections → problema del lado DB

Paso 4 — Profiling de PHP

Una vez que los recursos del servidor se ven aceptables, baja al profiling a nivel PHP. Meta: encontrar qué plugin, función de tema, o query consume más tiempo por petición.

Herramientas que dan respuestas reales

• Query Monitor (plugin gratis) — muestra queries, hooks, llamadas http, scripts, styles. Siempre desactivar en producción tras auditar.
• New Relic APM — profiling por transacción de calidad producción. El tier gratis cubre sitios pequeños.
• Datadog APM o Atatus — alternativas si prefieres su pricing.
• Tideways — diseñado específicamente para profiling PHP, menos caro que New Relic.

En nuestra experiencia, el 80% de los casos "WordPress lento" se reducen a un solo plugin ofensor o una sola query que se dispara en cada página. El profiler lo nombra en menos de 5 minutos.

Hallazgos comunes

• Un plugin de "contador de shares sociales" haciendo una llamada HTTP saliente a Facebook en cada carga
• Un "contador de visitantes en tiempo real" corriendo un escaneo completo de wp_postmeta por pageview
• Un plugin SEO generando el sitemap en cada petición en lugar de cachearlo
• Un plugin de backup corriendo un walk mtime sobre wp-content cada 5 minutos

Paso 5 — Análisis de base de datos

Si el profiling apunta a MySQL, baja a la capa DB.

Tres queries que todo DBA de WordPress debería conocer

-- Encontrar bloat de opciones autoloaded (el asesino silencioso)
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options WHERE autoload = 'yes'
ORDER BY size_bytes DESC LIMIT 20;

-- Identificar queries escaneando muchas filas
EXPLAIN SELECT * FROM wp_postmeta WHERE meta_key = 'some_key';

-- Ver queries lentas actuales e históricas
SHOW VARIABLES LIKE 'slow_query%';

La trampa del autoload

Si las opciones autoloaded exceden 1MB, cada carga de página es innecesariamente lenta porque WordPress las carga todas en memoria al hacer bootstrap. Ofensores comunes: transients expirados, datos de "sesión" de plugins, respuestas cacheadas de APIs externas sin expiración.

Query de limpieza:

DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%';

(Siempre haz backup primero.)

Añadiendo índices

El schema por defecto de WordPress no incluye índices compuestos en wp_postmeta. Para sitios con queries pesadas de campos personalizados, añadir (post_id, meta_key) reduce el tiempo de query en 90%+. Este es uno de los cambios de DB con mayor ROI que puedes hacer.

Paso 6 — Optimización de frontend

Después de que el servidor devuelve el HTML rápido, el navegador todavía tiene que renderizarlo. Los cuellos de botella de frontend dominan cuando TTFB ya está bien.

El checklist de frontend

• Imagen hero pre-cargada con <link rel="preload" as="image">
• Todas las imágenes servidas como WebP o AVIF con sizing apropiado
• Critical path CSS inline (top 14KB como mínimo)
• JavaScript con defer o async (nunca bloqueando el parser)
• Scripts de terceros (analítica, chat, anuncios) cargados después del evento load
• Un CDN real sirviendo assets estáticos desde un edge geográficamente cercano

Asesinos de INP que siempre encontramos

• Event listeners pesados corriendo en scroll sin throttling
• Un plugin de "popup de newsletter" enganchándose a cada input
• Scripts de live chat (Tawk.to, Intercom) haciendo trabajo en el primer input
• Banners de consentimiento de cookies con llamadas síncronas a terceros

Paso 7 — Decide el caching al final

El caching es el último paso, no el primero. Una vez has hecho rápido el sitio subyacente, el caching lo hace instantáneo. Pero cachear sobre un sitio estructuralmente lento solo esconde el problema hasta que ocurren los cache misses.

El stack de caching que desplegamos

• Object cache (Redis o Memcached) — elimina queries repetidas a DB
• Page cache (Nginx microcache o WP Rocket) — sirve HTML en microsegundos
• CDN edge cache — Cloudflare o Bunny.net para assets estáticos
• Headers de browser cache — Cache-Control: public, max-age=31536000, immutable para assets versionados

El orden importa: object cache primero (reduce carga DB), después page cache (reduce carga PHP), después CDN (reduce peticiones al origen).

Errores diagnósticos comunes

• Confiar en resultados de laboratorio sobre datos de campo — Lighthouse en un laptop rápido dice que todo está bien; usuarios reales en 4G dicen lo contrario
• Optimizar solo la home — la home es la página más rápida en la mayoría de sitios WordPress; los cuellos viven en categorías, búsqueda, posts individuales con comentarios
• Cachear páginas de admin — nunca; admin debe ser sin caché para precisión
• Saltar el paso de rebuild — después de cambios, re-testea desde cero, no asumas

Cuándo llamar a un especialista

Si has gastado más de 4 horas en una auditoría de rendimiento y los números no se han movido, el problema es estructural — a nivel de código, de query o de infraestructura. Hacemos esto cada semana y encontramos la causa raíz en 90 minutos en promedio.

Recuperación de velocidad WordPress es el servicio correcto para sitios atascados en el rango de 3–10 segundos de TTFB. Para sitios con lentitudes intermitentes, soporte de emergencia es más rápido.