Tu sitio WordPress marca 35 en PageSpeed: qué está pasando
Abres PageSpeed Insights, introduces la URL de tu web WordPress y el resultado es un 35 en móvil. El LCP marca 4,8 segundos, el CLS salta a 0,32 y el INP registra 340 milisegundos. Conoces las métricas porque llevas meses viendo artículos sobre Core Web Vitals en cada newsletter de marketing digital. Lo que no sabes es por qué tu WordPress, con un tema premium y varios plugins de optimización instalados, sigue suspendiendo.
El problema no es WordPress en sí. WordPress alimenta el 43% de la web global, y según datos de HTTPArchive de 2025, aproximadamente un tercio de esos sitios aprueba los tres Core Web Vitals simultáneamente. La diferencia entre los que aprueban y los que no rara vez es una sola causa. Es una acumulación de decisiones técnicas: el tema elegido, los plugins activos, la configuración de caché, el tratamiento de imágenes, la calidad del hosting y la cantidad de JavaScript de terceros cargado en cada página.
Esta guía no va de instalar un plugin mágico. Va de entender qué componentes de tu stack WordPress están penalizando cada métrica y cómo intervenir en cada capa con precisión quirúrgica. El objetivo es pasar de ese 35 a verde en las tres métricas, y mantenerlo así cuando añadas contenido nuevo.
Por qué WordPress tiene problemas frecuentes con Core Web Vitals
WordPress no nació como un framework de rendimiento. Nació como un sistema de publicación de blogs en 2003 y ha evolucionado mediante un ecosistema de plugins y temas que prioriza la funcionalidad sobre la eficiencia. Esta arquitectura extensible es su mayor fortaleza comercial y, al mismo tiempo, su mayor debilidad técnica.
Un sitio WordPress típico de empresa mediana carga entre 15 y 40 plugins activos. Cada plugin puede inyectar sus propios archivos CSS y JavaScript en todas las páginas del sitio, incluso en aquellas donde no se usa. Un plugin de formularios de contacto carga su CSS en la página de inicio. Un plugin de sliders carga su JavaScript en la página de servicios donde no hay ningún slider. Un plugin de analytics añade un script de 45 KB que bloquea el renderizado. Según el WordPress Performance Team, el sitio WordPress medio carga 3,2 MB de recursos en la primera visita, cuando el presupuesto recomendado para un LCP inferior a 2,5 segundos es de 1,5 MB o menos.
El segundo factor estructural es el tema. Los temas multipropósito como Avada, Divi o BeTheme incluyen decenas de módulos precargados, hojas de estilo para componentes que el sitio nunca usa, y frameworks JavaScript completos embebidos. Un tema multipropósito típico genera un DOM de 2.000 a 4.000 nodos en la página de inicio, cuando Google recomienda un máximo de 1.500 nodos para un rendimiento óptimo. El WordPress Performance Team ha documentado que los temas nativos de bloques (Twenty Twenty-Four, Twenty Twenty-Five) generan entre 400 y 800 nodos para un layout equivalente.
El tercer factor es el hosting. La mayoría de sitios WordPress empresariales comienzan en hosting compartido donde un solo servidor físico atiende cientos de sitios simultáneamente. El resultado es un TTFB (Time to First Byte) de 400 a 800 milisegundos, que consume entre el 16% y el 32% del presupuesto total de LCP antes de que el navegador haya recibido siquiera el primer byte de HTML. Ningún plugin de caché puede compensar un servidor que tarda medio segundo en responder.
Plugins de caché: WP Rocket, LiteSpeed Cache, W3 Total Cache
La caché de página es la optimización con mayor retorno inmediato en WordPress. Sin caché, cada visita ejecuta PHP, consulta la base de datos MySQL y genera el HTML desde cero. Con caché, el servidor sirve un archivo HTML estático pregenerado, eliminando completamente el procesamiento dinámico para visitantes no autenticados.
WP Rocket es el plugin de caché más completo para Core Web Vitals. Su ventaja no es solo la caché de página (que cualquier plugin ofrece), sino las optimizaciones complementarias integradas: eliminación de CSS no utilizado (Remove Unused CSS), carga diferida de JavaScript (Delay JavaScript Execution), preload de enlaces cuando el usuario hace hover, optimización de la base de datos y generación automática de CSS crítico inline. Según la documentación oficial de WP Rocket, estas optimizaciones combinadas reducen el TTFB entre un 40% y un 60% en configuraciones típicas. El coste es de 59 dólares anuales para un sitio, una inversión que se recupera en días si el sitio genera negocio.
LiteSpeed Cache es la mejor alternativa gratuita, especialmente potente en servidores que ejecutan LiteSpeed Web Server (donde aprovecha la caché a nivel de servidor, no solo a nivel de aplicación). Incluye optimización de imágenes integrada a través del servicio QUIC.cloud, CDN propio y funcionalidades de optimización de CSS/JS comparables a WP Rocket. Su principal limitación es que en servidores Apache o Nginx pierde la ventaja de la caché a nivel de servidor y funciona como un plugin de caché convencional.
W3 Total Cache ofrece el mayor control granular: permite configurar la caché de página, de objetos, de base de datos y de navegador de forma independiente. Su complejidad es su fortaleza y su debilidad: una configuración incorrecta puede empeorar el rendimiento o causar conflictos con otros plugins. Es la opción recomendada para equipos técnicos que necesitan control total sobre cada capa de caché.
La configuración crítica que muchos olvidan: la caché debe purgarse automáticamente cuando se publica o actualiza contenido, y las páginas de carrito, checkout y área de cliente deben excluirse de la caché para evitar servir contenido de otro usuario. WP Rocket y LiteSpeed Cache gestionan estas exclusiones automáticamente; en W3 Total Cache requieren configuración manual.
Optimización de imágenes: ShortPixel, Imagify y conversión WebP
Las imágenes son la causa número uno de un LCP deficiente en WordPress. El elemento LCP en la mayoría de las páginas es una imagen hero, una imagen de producto o una imagen destacada del post. Si esa imagen pesa 800 KB en lugar de 200 KB, el LCP se retrasa proporcionalmente.
La estrategia de optimización de imágenes tiene tres capas: compresión, formato moderno y dimensionamiento correcto.
Compresión: ShortPixel y Imagify son los dos plugins líderes para compresión automática de imágenes en WordPress. Ambos procesan las imágenes al subirlas a la biblioteca de medios y ofrecen tres niveles de compresión: lossy (máxima reducción, pérdida de calidad imperceptible en la mayoría de casos), glossy (equilibrio entre tamaño y calidad) y lossless (sin pérdida de calidad, menor reducción). ShortPixel ofrece un plan gratuito de 100 créditos mensuales y planes de pago desde 3,99 dólares al mes. Imagify está integrado con WP Rocket y ofrece 20 MB gratuitos al mes.
Formato WebP: La conversión a WebP reduce el peso de las imágenes un 25-35% adicional respecto a JPEG optimizado, según los datos publicados por Google. Tanto ShortPixel como Imagify generan automáticamente versiones WebP de cada imagen y las sirven a navegadores compatibles (que ya son el 97% del tráfico global). La configuración requiere asegurarse de que el servidor sirve las versiones WebP mediante rewrite rules en .htaccess o configuración del plugin.
Dimensionamiento: WordPress genera múltiples tamaños de cada imagen subida (thumbnail, medium, large, full). El error más común es cargar la imagen en tamaño full (2.400 px de ancho) en un contenedor que solo ocupa 800 px. La solución es usar el atributo srcset —que WordPress genera automáticamente desde la versión 4.4— y verificar que el tema no está forzando tamaños de imagen incorrectos. Los page builders como Elementor a veces ignoran los tamaños registrados y cargan siempre la imagen original.
Una consideración técnica frecuentemente ignorada: las imágenes above-the-fold (la imagen hero, el logo, la primera imagen de producto) no deben tener lazy loading activado. El atributo loading="lazy" en la imagen LCP retrasa su carga porque el navegador espera hasta que el viewport se acerca al elemento. WordPress añade loading="lazy" automáticamente a todas las imágenes desde la versión 5.5, pero desde la 5.9 excluye automáticamente la primera imagen del contenido. Verifica que tu tema no está sobreescribiendo este comportamiento.
Minimización de CSS y JavaScript: Autoptimize y alternativas
El CSS y JavaScript no optimizado es el segundo factor más común en LCP deficientes en WordPress. Un sitio WordPress típico carga entre 8 y 20 archivos CSS y entre 10 y 30 archivos JavaScript, muchos de ellos render-blocking.
La técnica más efectiva para mejorar el LCP es extraer el CSS necesario para renderizar el contenido above-the-fold e inyectarlo directamente en el <head> del HTML, cargando el resto del CSS de forma asíncrona. WP Rocket genera CSS crítico automáticamente. Si no usas WP Rocket, Autoptimize combinado con el addon de CSS crítico de CriticalCSS.com ofrece una funcionalidad equivalente.
Según datos del equipo de rendimiento de WordPress, el sitio WordPress medio carga un 60-70% de CSS que no se utiliza en la página actual. WP Rocket incluye la función Remove Unused CSS que analiza cada página y sirve solo el CSS necesario. El plugin gratuito Asset CleanUp permite desactivar selectivamente CSS y JS de plugins específicos en páginas donde no se necesitan.
La minimización reduce el tamaño de los archivos JS eliminando espacios, comentarios y nombres de variables largos. La combinación reduce el número de peticiones HTTP agrupando varios archivos en uno. Autoptimize hace ambas cosas de forma gratuita. Dicho esto, la combinación de JavaScript puede causar conflictos si el orden de carga de los scripts importa (y en WordPress casi siempre importa). La recomendación actual es minimizar siempre pero combinar con precaución, probando exhaustivamente después de activar la combinación.
El mayor impacto en INP proviene de JavaScript de terceros que se ejecuta en el hilo principal durante la carga: scripts de analytics, píxeles de remarketing, widgets de chat, pop-ups de cookies. WP Rocket permite retrasar la ejecución de JavaScript hasta la primera interacción del usuario (Delay JavaScript Execution), eliminando el impacto de estos scripts en el LCP y reduciendo el INP. Flying Scripts es la alternativa gratuita más eficaz para esta función específica.
Temas WordPress optimizados para Core Web Vitals
El tema es la base de todo el frontend de WordPress. Un tema mal codificado impone un techo de rendimiento que ningún plugin puede superar. Los temas que consistentemente producen los mejores resultados en Core Web Vitals comparten tres características: generan un DOM reducido (menos de 1.000 nodos en la página de inicio), cargan el mínimo CSS y JS necesario, y no dependen de frameworks JavaScript pesados.
GeneratePress es el tema que más consistentemente produce buenos Core Web Vitals en auditorías independientes. Su versión gratuita genera menos de 10 KB de CSS y cero JavaScript en el frontend. La versión premium (GeneratePress Premium, 59 dólares con actualizaciones de por vida) añade módulos de diseño que se cargan solo cuando se activan. El DOM típico de una página GeneratePress tiene entre 300 y 600 nodos.
Kadence ofrece una experiencia visual más rica que GeneratePress sin sacrificar significativamente el rendimiento. Su header builder y footer builder generan código limpio, y el tema carga JavaScript solo cuando se usan componentes interactivos (menú móvil, acordeones). El DOM típico oscila entre 500 y 900 nodos, razonable para un tema con más opciones de diseño.
Temas basados en bloques nativos (Twenty Twenty-Four, Twenty Twenty-Five) son la apuesta oficial del WordPress Performance Team. Al no depender del Customizer clásico ni de frameworks de opciones de terceros, eliminan una capa completa de abstracción. Su rendimiento es excelente en métricas técnicas, pero su flexibilidad de diseño es limitada sin el editor de sitio completo (Full Site Editing), que todavía tiene una curva de aprendizaje pronunciada.
Migrar de tema es un proyecto significativo. Si el presupuesto o el calendario no lo permiten, las optimizaciones en las otras capas (caché, imágenes, JavaScript) pueden mejorar sustancialmente los Core Web Vitals incluso con un tema subóptimo. Pero si después de optimizar todo lo demás el LCP sigue por encima de 3 segundos y el DOM supera los 2.000 nodos, el tema es el cuello de botella y debe abordarse.
Hosting y TTFB: el factor que muchos ignoran
El TTFB (Time to First Byte) es el tiempo que tarda el servidor en enviar el primer byte de respuesta al navegador. Es el punto de partida absoluto de la cascada de carga: nada se renderiza hasta que el navegador recibe ese primer byte. Google recomienda un TTFB inferior a 200 milisegundos para contribuir a un LCP saludable.
El impacto del hosting en los Core Web Vitals está bien documentado. Los datos de CrUX muestran una correlación directa entre TTFB y LCP: sitios con TTFB inferior a 200 ms tienen un 73% de probabilidades de aprobar el umbral de LCP de 2,5 segundos, mientras que sitios con TTFB superior a 600 ms solo lo aprueban en un 18% de los casos.
Hosting compartido (Hostinger plan básico, SiteGround StartUp, GoDaddy Economy): TTFB típico de 400-800 ms. Un solo servidor físico atiende cientos de sitios, y los picos de tráfico de cualquiera de ellos pueden afectar al resto. Para un blog personal es aceptable; para un sitio empresarial que depende del tráfico orgánico, es un cuello de botella estructural.
VPS gestionado (Cloudways con DigitalOcean o Vultr): TTFB típico de 150-300 ms. El sitio tiene recursos dedicados (CPU, RAM) y el proveedor gestiona las actualizaciones del servidor. La relación coste-rendimiento es excelente: desde 14 dólares mensuales por un servidor con 2 GB de RAM suficiente para sitios con hasta 50.000 visitas mensuales.
Hosting WordPress gestionado (Kinsta, WP Engine, Rocket.net): TTFB típico de 100-200 ms. Incluyen CDN integrado, caché a nivel de servidor (no necesitan plugin de caché en muchos casos), staging environments y soporte especializado en WordPress. El coste es superior (desde 30-35 dólares mensuales) pero la infraestructura está optimizada específicamente para WordPress.
CDN (Content Delivery Network): Independientemente del hosting, un CDN reduce el TTFB para usuarios geográficamente distantes del servidor. Cloudflare (plan gratuito disponible) sirve el contenido cacheado desde el punto de presencia más cercano al usuario. Para un sitio con audiencia en España, un servidor en Europa combinado con Cloudflare garantiza un TTFB consistente inferior a 200 ms para la mayoría de visitantes.
Una medición que debes hacer hoy: abre Google Search Console, ve a Experiencia > Core Web Vitals y mira los datos de campo de tu sitio. Si el TTFB (visible en PageSpeed Insights, sección Diagnóstico) supera los 400 ms, la primera optimización debería ser el hosting, no los plugins. Consulta nuestra guía sobre velocidad web para un análisis completo de todos los factores que influyen en la velocidad de carga más allá de WordPress.
Checklist final: Core Web Vitals verde en WordPress
La optimización de Core Web Vitals en WordPress sigue un orden de prioridad basado en el impacto de cada acción. Implementar estas acciones en secuencia, midiendo después de cada paso, permite identificar exactamente qué cambio produjo cada mejora.
Semana 1 — Infraestructura base:
- Verificar el TTFB actual en PageSpeed Insights. Si supera 400 ms, evaluar migración de hosting.
- Instalar y configurar un plugin de caché (WP Rocket recomendado, LiteSpeed Cache como alternativa gratuita).
- Activar compresión Gzip/Brotli a nivel de servidor o mediante plugin.
- Configurar un CDN (Cloudflare plan gratuito como mínimo).
Semana 2 — Imágenes:
- Instalar ShortPixel o Imagify y procesar en lote todas las imágenes existentes.
- Activar conversión automática a WebP.
- Verificar que las imágenes above-the-fold no tienen
loading="lazy". - Revisar que el tema sirve imágenes con
srcsety tamaños apropiados.
Semana 3 — CSS y JavaScript:
- Activar Remove Unused CSS en WP Rocket o instalar Asset CleanUp para desactivar CSS/JS de plugins no utilizados en cada página.
- Activar Delay JavaScript Execution para scripts de terceros.
- Generar CSS crítico inline.
- Verificar que no hay archivos CSS o JS render-blocking en el
<head>que puedan diferirse.
Semana 4 — Tema y DOM:
- Auditar el DOM de la página de inicio con Chrome DevTools (Elements > Ctrl+F > buscar total de nodos).
- Si supera 1.500 nodos, identificar los componentes del tema que generan más nodos.
- Desactivar widgets y módulos del tema que no se utilicen.
- Si el tema es un page builder, evaluar el coste-beneficio de migrar frente a optimizar la configuración existente.
Validación continua:
- Monitorizar los datos de campo en Google Search Console cada semana durante los 28 días siguientes.
- Los datos CrUX se actualizan cada 28 días, así que los cambios tardan aproximadamente un mes en reflejarse en las métricas oficiales de Google.
- Repetir la auditoría de PageSpeed Insights después de cada cambio significativo (nuevo plugin, actualización de tema, nuevo contenido pesado).
El objetivo no es una puntuación perfecta de 100 en Lighthouse —es un número sintético que no refleja la experiencia real—. El objetivo es que los tres Core Web Vitals estén en verde en los datos de campo de Google Search Console: LCP inferior a 2,5 segundos, CLS inferior a 0,1 e INP inferior a 200 milisegundos para el percentil 75 de tus usuarios reales.