Por qué tu sitio WordPress es lento: guía de optimización de rendimiento

#Por qué tu WordPress va lento si no es culpa del hosting

Descubre más sobre optimización de velocidad WordPress en WPPoland.

Cuando un sitio WordPress empieza a arrastrarse, la reacción instintiva es mejorar el plan de hosting. Aunque un mejor servidor ayuda, a menudo enmascara problemas arquitectónicos subyacentes. Gastar dinero en hosting antes de optimizar la capa de aplicación es una solución temporal para un problema permanente.

#Qué ralentiza WordPress además del hosting

Un servidor más rápido rendirá mejor, pero si tu sitio está sobrecargado por recursos sin optimizar, solo estás ejecutando código ineficiente en una CPU más rápida. Estos son los cuellos de botella más comunes que realmente consumen tu rendimiento:

• Sobrecarga de plugins y deuda de consultas: Cada plugin activo no es solo un archivo; es una serie potencial de consultas a la base de datos y dependencias externas. Muchas de esas consultas son redundantes: piden los mismos datos en cada petición cuando podrían haberse guardado en caché una vez.
• Recursos de imagen no gestionados: Las imágenes de alta resolución sin formatos modernos (como AVIF o WebP) son la causa número 1 de LCP lento. Una foto hero exportada directamente de la cámara o de un banco de imágenes suele pesar varias veces más que la misma imagen codificada en AVIF al tamaño al que realmente se muestra.
• Falta de caché de objetos: Las constantes consultas a la base de datos para datos estáticos fuerzan al servidor a realizar trabajo redundante. Datos como las opciones del sitio, los menús de navegación y la configuración de los widgets se consultan en cada carga de página, aunque raramente cambian.
• Latencia de scripts de terceros: Los rastreadores externos, fuentes y embeds a menudo bloquean el hilo principal y arruinan tus Core Web Vitals. Las fuentes web cargadas desde un host externo, los píxeles de seguimiento de redes sociales y los widgets de chat en vivo son los infractores habituales.

#Cómo leer los datos de campo de PageSpeed Insights en un sitio WordPress

PageSpeed Insights muestra dos tipos de números distintos en la misma pantalla, y confundirlos es un motivo habitual por el que un arreglo en WordPress parece no servir de nada. La sección de campo procede del Chrome User Experience Report (CrUX): usuarios reales de Chrome que han dado su consentimiento, agregados durante el periodo de recogida de los 28 días anteriores y presentados en el percentil 75 (documentación de PageSpeed Insights). La sección de laboratorio es una única carga simulada en un solo dispositivo con condiciones de red fijas, así que los dos conjuntos de valores pueden diferir.

Tres consecuencias para el diagnóstico:

• Comprueba a qué nivel corresponden los datos. Cuando una URL no tiene datos suficientes propios, PSI recurre a los datos del origen. En una entrada de blog con poco tráfico, el LCP de campo puede describir todo el dominio y no esa página.
• Prioriza con datos de campo, depura con datos de laboratorio. web.dev recomienda que, cuando existen ambos, uses los datos de campo para priorizar y los de laboratorio para depurar (web.dev: por qué difieren los datos de laboratorio y de campo). Las pruebas de laboratorio cargan la página con la caché vacía y no pueden predecir cuándo hará clic un visitante real, por eso el Total Blocking Time es solo un indicador aproximado de INP en laboratorio, no un sustituto. Nuestra guía de optimización de INP explica qué hacer cuando los datos de campo señalan ahí.
• Cuenta con un retraso. Como la ventana es de 28 días, un arreglo publicado hoy solo se refleja por completo en los datos de campo unas cuatro semanas después. Una puntuación de laboratorio que mejora de un día para otro es buena señal, no una prueba.

#Cómo saber si el TTFB apunta al servidor

El TTFB es donde la pregunta de si la culpa es del hosting recibe una respuesta medible. web.dev define el TTFB como la suma del tiempo de redirección, el arranque del service worker, la consulta DNS, la conexión y negociación TLS, y la petición hasta el primer byte de la respuesta. Considera 0,8 segundos o menos como referencia orientativa de un buen valor, y más de 1,8 segundos como un valor deficiente (web.dev: optimizar el Time to First Byte).

Ese desglose importa en WordPress porque no todo es PHP. Un visitante que llega a http://, es redirigido a https:// y después al host con www paga cada salto antes de que WordPress empiece a trabajar. El panel Network de DevTools muestra cada redirección como una petición aparte, y su arreglo está en la configuración del servidor o del CDN, no en la base de datos. En campo, el TTFB se obtiene de CrUX o de la librería JavaScript web-vitals; en laboratorio, del panel Network de DevTools o de WebPageTest.

La cifra de 200 ms que aparece en otras partes de este artículo es un objetivo de trabajo más estricto para una página WordPress servida desde la caché de página. Un valor entre 200 ms y 0,8 s no suspende según la guía de Google. Es una razón para comprobar si la caché de página se está usando de verdad.

#Cómo usar Salud del sitio para detectar problemas de velocidad en WordPress

WordPress incluye comprobaciones propias en Herramientas, Salud del sitio, y algunas tratan sobre la velocidad. Desde WordPress 6.1, Salud del sitio comprueba si existe una caché de página completa y si el tiempo de respuesta del servidor es aceptable, con 600 ms como umbral por defecto que los proveedores de hosting pueden cambiar con el filtro site_status_good_response_time_threshold. También recomienda una caché de objetos persistente cuando los datos del sitio superan unos umbrales que el hosting puede sobrescribir con site_status_persistent_object_cache_thresholds (Make WordPress Core, comprobaciones de caché en 6.1). Ambas comprobaciones solo se ejecutan en producción, así que una copia de staging no las mostrará.

WordPress 6.6 añadió una comprobación de opciones con carga automática: avisa cuando las opciones que se cargan en cada petición suman más de 800 KB. La misma versión dejó de cargar automáticamente cualquier opción individual mayor de 150.000 bytes salvo que el código lo pida de forma explícita, un límite ajustable con el filtro wp_max_autoloaded_option_size (Make WordPress Core, cambios de autoload en 6.6). Un aviso de autoload suele llevar a las opciones huérfanas de plugins que se describen en la sección de base de datos más abajo.

#Cómo encontrar el plugin lento con Query Monitor

Query Monitor convierte “WordPress va lento” en un componente con nombre. Su panel de base de datos marca las consultas lentas, duplicadas y fallidas, y las agrupa por tipo de consulta, componente o función que las llama, de modo que una consulta que un plugin repite en cada petición aparece bajo el nombre de ese plugin (Query Monitor en GitHub). Hay otros dos paneles que es fácil pasar por alto:

• Llamadas a la HTTP API: cada petición del lado del servidor hecha mediante la HTTP API de WordPress, con las peticiones fallidas y las respuestas distintas de 200 resaltadas. Un plugin que contacta con un servidor remoto mientras se genera la página suma ese viaje de ida y vuelta al TTFB.
• Hooks y acciones: cada hook disparado durante la petición con sus callbacks, prioridades y componentes, lo que muestra dónde se engancha un plugin en páginas donde no tiene ninguna función visible.

Ejecútalo en una copia de staging siempre que puedas. Query Monitor muestra su información a los administradores con sesión iniciada, y esas peticiones suelen saltarse la caché de página, así que los números describen el caso sin caché: el trabajo que hace el servidor para cada visitante al que la caché no cubre.

#Cómo acelerar un WordPress lento

El flujo completo de optimización está en nuestra guía de optimización de velocidad de WordPress. Los pasos siguientes son los que un diagnóstico señala con más frecuencia.

#1. Implementar caché selectiva de objetos

En lugar de bombardear la base de datos con consultas comunes, usa la API Transients o una caché persistente de objetos (como Redis). Esto es crucial para sitios dinámicos donde la caché de página no siempre es posible.

La API Transients funciona con un patrón de comprobar y guardar. WordPress busca primero el valor bajo una clave con nombre. Si está ahí y no ha caducado, lo devuelve de inmediato sin tocar la tabla de entradas. Si no, tu código ejecuta la consulta, guarda el resultado con un tiempo de caducidad y lo devuelve.

function get_performance_optimized_posts() {
    // Intentar obtener de la caché primero
    $posts = get_transient('featured_posts_query');

    if (false === $posts) {
        $posts = new WP_Query([
            'posts_per_page' => 5,
            'no_found_rows'  => true, // Omitir sobrecarga si no se necesita paginación
            'post_status'    => 'publish',
        ]);

        // Cachear durante 12 horas
        set_transient('featured_posts_query', $posts, 12 * HOUR_IN_SECONDS);
    }

    return $posts;
}

El parámetro no_found_rows es especialmente importante. Por defecto, WP_Query ejecuta una consulta adicional SQL_CALC_FOUND_ROWS para contar el total de resultados para la paginación. Un widget de “últimas cinco entradas” nunca pagina, así que ese recuento es puro trabajo extra, y desactivarlo lo elimina de cada petición que ejecuta el widget.

Cuándo usar Redis vs Transients:

• Transients: Para caché de consultas con tiempo de expiración definido. Los datos se almacenan en la tabla wp_options (o en Redis si está disponible)
• Redis/Memcached: Para caché persistente de objetos que sobrevive entre peticiones HTTP. Compensa en sitios con mucho tráfico, tiendas WooCommerce y sitios de membresía, donde muchas páginas no pueden servirse desde una caché de página completa porque el visitante ha iniciado sesión o tiene un carrito

#2. Ir más allá de la simple compresión de imágenes

“Comprimir” imágenes es solo la mitad de la batalla. Debes aspirar al soporte AVIF y dimensionamiento responsive para asegurar que los usuarios móviles no descarguen recursos del tamaño de escritorio.

Estrategia de optimización de imágenes en capas:

1. Formato: Sirve AVIF como primera opción, WebP como respaldo, JPEG/PNG como último recurso
2. Dimensiones: Usa el atributo srcset para servir diferentes tamaños según el ancho de pantalla
3. Carga diferida: Aplica loading="lazy" a las imágenes que no están en el viewport inicial, y nunca a la imagen LCP, que debe cargarse lo antes posible
4. CDN de imágenes: Servicios como Cloudinary o imgix pueden transformar imágenes sobre la marcha

<!-- Ejemplo de implementación óptima de imagen -->
<picture>
  <source type="image/avif" srcset="imagen-400.avif 400w, imagen-800.avif 800w, imagen-1200.avif 1200w">
  <source type="image/webp" srcset="imagen-400.webp 400w, imagen-800.webp 800w, imagen-1200.webp 1200w">
  <img src="imagen-800.jpg" alt="Descripción" loading="lazy" width="800" height="450"
       srcset="imagen-400.jpg 400w, imagen-800.jpg 800w, imagen-1200.jpg 1200w"
       sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px">
</picture>

Los atributos explícitos width y height importan tanto como el formato. Permiten al navegador reservar el espacio antes de que llegue el archivo, y eso es lo que mantiene bajo el CLS.

#3. Optimizar el buffer de salida

Si no estás usando un plugin de caché dedicado, puedes implementar compresión Gzip a nivel de PHP, aunque hacerlo vía .htaccess o configuración de Nginx es generalmente más eficiente.

// Lógica de compresión básica si la configuración a nivel de servidor no está disponible
add_action('init', function() {
    if (!ob_start("ob_gzhandler")) ob_start();
});

#4. Auditoría de plugins: el mayor impacto con menor esfuerzo

La auditoría de plugins es frecuentemente la acción de mayor impacto que puedes tomar para mejorar el rendimiento de WordPress. Muchos sitios acumulan plugins con el tiempo sin evaluar su impacto en el rendimiento.

Proceso de auditoría de plugins:

1. Instala Query Monitor: Este plugin de desarrollo muestra exactamente cuántas consultas de base de datos genera cada plugin, cuánta memoria consume y cuánto tiempo añade a la carga de la página
2. Identifica los pesados: Ordena por número de consultas y tiempo, y busca plugins que trabajan mucho en páginas donde no tienen ninguna función visible
3. Evalúa alternativas: Para cada plugin pesado, investiga si existe una alternativa más ligera o si su funcionalidad puede implementarse con código personalizado
4. Desactiva lo innecesario: Plugins de seguridad redundantes, constructores de formularios no usados, plugins de sliders que solo se usan en una página

Plugins típicamente problemáticos para el rendimiento:

• Constructores de páginas (Elementor, Divi) en páginas que no los necesitan
• Plugins de redes sociales que cargan scripts en cada página
• Plugins de SEO con funcionalidades infladas
• Plugins de estadísticas que rastrean cada visita en la base de datos

#5. Optimización de la base de datos

Con el tiempo, la base de datos de WordPress acumula datos innecesarios que ralentizan las consultas:

• Revisiones de entradas: WordPress guarda una revisión cada vez que guardas, así que una entrada editada muchas veces arrastra una larga cola de copias antiguas
• Transients expirados: Los transients que ya expiraron permanecen en la base de datos hasta que algo los limpia
• Opciones huérfanas: Los plugins desinstalados a menudo dejan sus ajustes en wp_options, a veces con autoload activado, de modo que se cargan en cada petición
• Metadatos huérfanos: Datos de meta asociados a posts, usuarios o comentarios eliminados

// Limitar revisiones de posts en wp-config.php
define('WP_POST_REVISIONS', 5);

// O desactivar completamente (no recomendado para sitios con múltiples editores)
define('WP_POST_REVISIONS', false);

Herramientas de optimización de base de datos:

• WP-Optimize: Limpieza automatizada de revisiones, transients y datos huérfanos
• phpMyAdmin: Para consultas manuales de limpieza
• WP-CLI: wp transient delete --expired y wp db optimize desde la línea de comandos, la opción más segura en sitios con tablas grandes

Haz una copia de seguridad de la base de datos antes de cualquier limpieza. Una consulta equivocada contra wp_postmeta no se arregla con un botón de deshacer.

#6. Implementación de CDN

Un CDN (Content Delivery Network) distribuye los recursos estáticos de tu sitio a través de servidores en todo el mundo, asegurando que los visitantes descarguen archivos desde el servidor más cercano a su ubicación geográfica.

Beneficios de un CDN para WordPress:

• Reducción del TTFB: Los recursos se sirven desde el edge más cercano
• Menor carga del servidor: Los archivos estáticos no tocan tu servidor de origen
• Protección DDoS: La mayoría de los CDN incluyen protección contra ataques
• Certificado SSL gratuito: Cloudflare y otros ofrecen SSL gratuito
• Compresión automática: Brotli/Gzip aplicados automáticamente

Configuración recomendada de Cloudflare para WordPress:

1. Configura SSL/TLS en “Full (strict)” para que el tráfico vaya cifrado hasta tu servidor.
2. Añade reglas de caché para los recursos estáticos y omite la caché en /wp-admin/, para usuarios con sesión iniciada y en las páginas de carrito y pago de WooCommerce.
3. Mantén activada la compresión Brotli.
4. En los planes de pago, valora Polish para optimizar imágenes automáticamente, o sigue haciéndolo en WordPress si ya generas AVIF.

#Cómo monitorizar el rendimiento de WordPress

La optimización del rendimiento no es una tarea de una sola vez. Los sitios WordPress evolucionan constantemente con nuevo contenido, plugins actualizados y cambios de configuración. Sin monitoreo continuo, el rendimiento se degrada gradualmente. Para alertas y configuraciones a largo plazo en sitios grandes, consulta nuestra guía de monitorización del rendimiento de WordPress.

Herramientas de monitoreo recomendadas:

• Google PageSpeed Insights: Para verificaciones puntuales de Core Web Vitals
• Google Search Console: Para datos reales de Core Web Vitals de tus usuarios
• GTmetrix: Para análisis detallado de cascada de recursos
• Query Monitor: Para depuración de consultas de base de datos en desarrollo
• New Relic / Datadog: Para monitoreo de aplicación a nivel de servidor

Los scripts de terceros merecen una comprobación aparte. En la UE, la Directiva sobre la privacidad y las comunicaciones electrónicas (2002/58/CE, artículo 5, apartado 3) exige consentimiento antes de almacenar cookies no esenciales (texto en EUR-Lex), así que los scripts de seguimiento solo deberían cargarse cuando el visitante los acepta. Bien hecho, eso también los mantiene fuera de la primera carga para todos los que aún no han pulsado el banner.

Métricas clave a monitorear:

Los umbrales de LCP, INP y CLS son los valores “buenos” publicados por Google, medidos en el percentil 75 de las cargas de página (web.dev: Web Vitals). INP sustituyó a FID como Core Web Vital en marzo de 2024, así que cualquier informe que aún muestre FID está desactualizado. La cifra de TTFB es el umbral de trabajo propio de este artículo para decidir cuándo mirar el servidor, no un Core Web Vital de Google.

#Lista de comprobación para un WordPress lento

Si tu sitio es lento, no adivines, mide. Usa Query Monitor para encontrar consultas de base de datos costosas y PageSpeed Insights para identificar scripts que bloquean el renderizado.

• Verifica el conteo de consultas: ¿Estás haciendo más de 100 consultas para una sola carga de página?
• Audita tu sección hero: ¿La imagen principal se sirve en un formato de nueva generación?
• Prueba tu TTFB: Si supera los 200ms, entonces considera tu hosting u optimización de base de datos.
• Revisa los scripts de terceros: ¿Cuántos scripts externos se cargan y cuánto bloquean?

La causa suele ser ese “plugin sencillo” que nadie recordó desactivar.

Descubre más sobre desarrollo WordPress profesional y auditoría de seguridad WordPress en WPPoland.

En el lado de entrega mantenemos este tema bajo auditoría Core Web Vitals.