WPO en WordPress: cómo aprobar las Core Web Vitals paso a paso

El WPO en WordPress es el trabajo para que tus páginas carguen y respondan rápido a usuarios reales: LCP de 2,5 s o menos, INP de 200 ms o menos y CLS de 0,1 o menos, en el percentil 75. Se consigue midiendo primero, con caché de página, una imagen principal sin carga diferida y menos JavaScript de plugins.

Para comprobarlo en tu web: Auditoría SEO

WPO (Web Performance Optimization) es el conjunto de cambios que reducen lo que tarda una página en pintarse, en responder y en quedarse quieta. En WordPress, una parte la resuelve el propio núcleo y otra depende de lo que tú eliges: el alojamiento, el tema, el constructor visual y cada plugin que activas. Esta guía separa lo que ya viene hecho de lo que tienes que hacer tú, con las versiones exactas y las fuentes oficiales. La versión actual de WordPress es la 7.1 (7.1.3, publicada el 06-10-2026)1.

Mide antes de tocar nada

Las Core Web Vitals son tres métricas de experiencia de usuario: LCP (cuánto tarda en pintarse el elemento principal), INP (cuánto tarda la página en responder a un clic o una pulsación; sustituyó a FID en marzo de 2024) y CLS (cuánto se mueve el contenido mientras carga).

Hay dos tipos de datos y conviene no mezclarlos:

• Datos de campo. PageSpeed Insights muestra la experiencia de usuarios reales de Chrome durante los 28 días anteriores2. Es lo que cuenta para Google. Si la URL no tiene visitas suficientes, enseña los datos de todo el dominio, y si tampoco hay, no enseña nada2.
• Datos de laboratorio. Lighthouse simula una carga en condiciones fijas. Sirve para depurar y para comparar antes y después de un cambio, pero no es la nota que ve Google.

El informe de Core Web Vitals de Search Console usa esos mismos datos de campo, agrupa las URL que tienen una experiencia parecida y separa móvil de ordenador3. En WordPress eso es muy útil: si falla un grupo de entradas del blog, el problema suele estar en la plantilla de entrada, no en cada artículo.

Mide tres plantillas, no una página suelta: la portada, una entrada y una página de servicio o de producto. Apunta los valores de campo de cada una antes de cambiar nada.

¿Qué hace WordPress de serie para la velocidad?

Antes de instalar nada, conviene saber qué ya hace el núcleo. Esta tabla resume lo que publica el equipo de WordPress en make.wordpress.org/core:

Tres matices que cambian decisiones:

1. La carga diferida automática necesita dimensiones. WordPress solo añade loading="lazy" a las imágenes con width y height4, y desde la 6.3 deja sin diferir las tres primeras por defecto7. Lo que pinta un constructor visual con su propio HTML, o una imagen de fondo en CSS, puede quedar fuera de esa lógica.
2. Ni WebP ni AVIF convierten tus imágenes viejas. La 6.5 admite subir AVIF, pero no transforma las existentes; para generarlas al subir hace falta un filtro o un plugin9.
3. La carga especulativa tiene límites. Viene activada para visitantes sin sesión iniciada y con enlaces permanentes «bonitos», usa prefetch con impaciencia conservadora y excluye las URL con parámetros10.

Performance Lab: el plugin del equipo de rendimiento

Performance Lab es el plugin oficial del equipo de rendimiento de WordPress. Reúne funciones que están en prueba y que, en su mayoría, deberían acabar en el núcleo11. Su versión actual exige WordPress 6.9 o superior11.

Desde él puedes activar módulos sueltos, cada uno como su propio plugin. Entre los que lista su página oficial están Image Prioritizer, Modern Image Formats, Enhanced Responsive Images, Embed Optimizer, Optimization Detective, Speculative Loading y View Transitions (experimental)11. Dos reglas para usarlo bien:

• Activa de uno en uno y mide entre cambio y cambio. Son funciones en prueba: si algo falla, sabrás cuál ha sido.
• No dupliques funciones. Si tu plugin de caché o de imágenes ya convierte a WebP o difiere scripts, no actives el módulo equivalente.

Caché de página: plugin o servidor

La caché de página guarda el HTML ya generado de cada URL y lo entrega sin ejecutar PHP ni consultar la base de datos. La documentación de WordPress la presenta como «el mayor beneficio con la menor molestia» y explica que los plugins de caché guardan las entradas y páginas como ficheros estáticos12.

Tienes tres sitios donde ponerla, y basta con uno:

1. En el alojamiento. Muchos proveedores de WordPress gestionado la traen activada en el servidor. Pregunta antes de instalar un plugin.
2. En el servidor web o un proxy. La documentación de WordPress cita Varnish como ejemplo de caché del lado del servidor12. Si administras tú el servidor, las guías de compresión y caché en Apache y de gzip, Brotli y caché en Nginx cubren esa capa.
3. Con un plugin de caché. Hay varios gratuitos en el directorio de WordPress. No hay uno «mejor» en abstracto: elige el que tu alojamiento recomiende o no desaconseje.

Para saber si ya tienes caché, abre Herramientas > Salud del sitio. Desde la 6.1, WordPress detecta la caché de página por las cabeceras de respuesta y considera aceptable una respuesta del servidor por debajo de 600 ms6.

Arregla la métrica que falla

Arregla primero la métrica que está en rojo en los datos de campo, y en la plantilla donde falla. Esta tabla resume las causas que más se repiten en WordPress y su arreglo según la documentación de web.dev:

LCP: la imagen principal

En la mayoría de páginas de WordPress el elemento LCP es una imagen: la destacada de la entrada o la cabecera de la portada. web.dev pide tres cosas: que no tenga carga diferida, que esté en el HTML inicial para que el navegador la encuentre pronto y que lleve fetchpriority="high"13. WordPress hace las dos últimas con sus funciones de imagen7, pero un tema o un plugin de «optimización» pueden deshacerlo. Mira el código fuente de la página y busca la etiqueta de esa imagen.

INP: el JavaScript de plugins y terceros

El INP empeora cuando el hilo principal está ocupado con tareas largas, y durante la carga cada script que se evalúa añade retraso a la primera interacción15. En un WordPress, ese JavaScript viene sobre todo de plugins que cargan sus ficheros en todas las páginas aunque solo se usen en una, y de servicios de terceros. web.dev propone un orden: quitar lo que no aporta un valor claro y diferir el resto14.

CLS: dimensiones, fuentes y avisos

El CLS en WordPress casi siempre tiene nombre propio: una imagen sin dimensiones en un bloque personalizado, un banner de consentimiento que aparece arriba y empuja la página, o una fuente web que cambia el tamaño del texto al cargarse. Las tres se arreglan reservando el espacio antes de que llegue el contenido16.

Qué no tocar

Algunas recomendaciones que circulan para WordPress no se sostienen hoy, o solo valen en ciertos casos:

• Combinar todos los CSS y JS en un fichero. La documentación de WordPress lo recomienda solo «cuando todavía usas HTTP/1.x»12. Con HTTP/2 o HTTP/3 no te lo pide; actívalo solo si una medición antes y después te da la razón.
• Diferir todas las imágenes. La imagen principal nunca debe llevar carga diferida13. Revisa que tu plugin de optimización no la incluya.
• Dos plugins de caché a la vez. Duplican trabajo y complican saber qué versión de la página se sirve. Uno, y comprobado en la Salud del sitio.
• Perseguir el 100 de Lighthouse. Es una prueba de laboratorio. Google evalúa con datos de campo en el percentil 753.

Cómo comprobarlo

1. Pasa la portada, una entrada y una página de servicio por PageSpeed Insights y apunta los datos de campo.
2. Revisa el informe Core Web Vitals de Search Console, por separado en móvil y en ordenador.
3. Abre Herramientas > Salud del sitio y comprueba los avisos de caché de página y de tiempo de respuesta.
4. Tras cada cambio, compara el laboratorio de inmediato. El campo tarda: PageSpeed Insights resume los 28 días anteriores2, así que una mejora tarda semanas en notarse del todo.

Qué hace SmoothSeen con esto

SmoothSeen mide la velocidad de la página que le das con las Core Web Vitals de usuarios reales que publica PageSpeed Insights y los umbrales de Google; si la página no tiene datos de campo suficientes, usa la prueba de laboratorio de Lighthouse. Lo incluye en la nota de Posicionamiento web junto a la compresión de texto, el HTTPS y el resto de comprobaciones, y lo traduce en tareas de un plan de acción priorizado.

Qué hacer esta semana

Mide tus tres plantillas principales en PageSpeed Insights y anota qué métrica falla en cada una. Arregla primero la imagen principal de la plantilla que falla en LCP y confirma en la Salud del sitio que tienes caché de página. Si quieres ver esas mediciones junto a las de tus competidores, analiza tu web con SmoothSeen.

Preguntas frecuentes

¿Qué plugin de caché es mejor para WordPress?

No hay uno mejor para todos los casos. Lo primero es saber si tu alojamiento ya hace caché de página en el servidor, porque entonces sobra un plugin. Si no la hace, cualquier plugin de caché del directorio oficial que funcione bien con tu tema sirve. Juzga el resultado en la Salud del sitio y con los datos de campo de PageSpeed Insights, no por la fama del plugin.

¿Por qué PageSpeed Insights me da una nota distinta cada vez?

La nota de rendimiento que aparece arriba sale de la prueba de laboratorio de Lighthouse, que varía con la red y la carga del servidor en ese momento. Los datos de campo, en cambio, resumen 28 días de visitas reales y apenas cambian de un día para otro. Para decidir si tu WordPress aprueba, fíjate en los datos de campo y en sus tres métricas.

¿Elementor u otros constructores visuales hacen lenta una web?

Un constructor visual no condena una web, pero añade HTML, CSS y JavaScript que una plantilla hecha a mano no necesita. El riesgo está en el INP, porque un DOM muy grande encarece cada actualización de la pantalla, y en el LCP cuando la imagen principal se pone como fondo CSS. Mide la plantilla con datos de campo antes de decidir si cambiarlo.

¿Tengo que convertir todas mis imágenes a WebP o AVIF?

No es obligatorio. WordPress acepta subir WebP desde la 5.8 y AVIF desde la 6.5, pero no convierte las imágenes que ya tienes. Empieza por las que son el elemento LCP de tus plantillas principales, porque ahí es donde un fichero más ligero mejora la métrica que cuenta. El resto puede esperar a un plugin que las genere al subirlas.