Core Web Vitals Gutenberg: guía 2026 para WordPress

Para mejorar los Core Web Vitals en Gutenberg, medí con datos de campo, dejá que WordPress priorice la imagen principal con fetchpriority=»high», definí ancho y alto en cada bloque y recortá JavaScript. Metas de Google: LCP de 2,5 s, INP de 200 ms, CLS de 0,1.

Los Core Web Vitals son tres métricas de Google que miden la experiencia real de una página: LCP (carga), INP (respuesta a la interacción) y CLS (estabilidad visual). Gutenberg es el editor de bloques de WordPress, y sus bloques nativos (Imagen, Portada, Encabezado, Video) generan el HTML que mide el navegador. Esta guía vincula cada métrica con el bloque que suele romperla y el ajuste que la corrige.

¿Cómo hacer una auditoría de Core Web Vitals en WordPress?

Auditar es medir el percentil 75 de las cargas reales de tus URLs con más tráfico, primero en móvil, y anotar qué métrica falla y qué elemento la causa. Según web.dev, una página pasa cuando cumple los tres umbrales (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) en ese percentil, segmentado por móvil y escritorio.

La distinción que más confunde es campo contra laboratorio. Los datos de campo vienen de visitantes reales (el Chrome User Experience Report, o CrUX, alimenta Search Console, PageSpeed Insights y DevTools). Los de laboratorio son una simulación controlada que sirve para probar cambios antes de publicar.

Herramienta	Tipo de dato	LCP	INP	CLS
Informe de Core Web Vitals (Search Console)	Campo	Sí	Sí	Sí
Chrome User Experience Report (CrUX)	Campo	Sí	Sí	Sí
PageSpeed Insights	Campo (CrUX) y laboratorio (Lighthouse)	Sí	Sí	Sí
Chrome DevTools	Laboratorio y campo	Sí	Sí	Sí
Lighthouse	Laboratorio	Sí	No (usá TBT)	Sí

El paso a paso que yo seguiría:

1. Elegí las URLs que traen tráfico. La home, la nota más leída, la ficha de producto que más vende y un archivo de categoría alcanzan para arrancar.
2. Mirá móvil primero. Es donde suele fallar todo y donde está buena parte de tu público.
3. Abrí el informe de Core Web Vitals de Search Console. Anotá qué grupo de URLs falla y en qué métrica.
4. Corré PageSpeed Insights sobre una URL representativa. Anotá el elemento que causa el LCP y qué desplaza las cosas en el CLS.
5. Guardá la foto del «antes». Una planilla con fecha, URL, métrica y valor. Sin esto, después no podés probar nada.

Si tu informe viejo habla de FID, está desactualizado. web.dev explica que en 2023 el INP era una métrica en evaluación, con la intención de reemplazar al FID. En la versión de la página que consulté, actualizada el 31 de octubre de 2024, el INP figura como estable entre los Core Web Vitals.

Ojo con los sitios chicos: si tu URL no tiene tráfico suficiente, puede que no aparezcan datos de campo y te quede solo el laboratorio. Ahí conviene medir con la librería web-vitals, que web.dev recomienda para armar monitoreo propio.

¿Qué bloques de Gutenberg afectan los Core Web Vitals de tu sitio?

Los bloques que más pesan son los que dibujan lo más grande de la pantalla (Imagen, Portada, Encabezado grande) para el LCP, los que no reservan espacio (imágenes sin dimensiones, embeds, fuentes web) para el CLS y los que arrastran JavaScript (de terceros o interactivos) para el INP. Este mapa es mi lectura de cómo se comporta cada métrica, no una tabla oficial. Ya lo cubrimos antes en todo lo que podés hacer con Gutenberg FSE.

Métrica	Umbral bueno	Bloques o elementos sospechosos	Primer chequeo
LCP	≤ 2,5 s	Imagen, Portada, Encabezado grande	¿Es la imagen candidata? ¿Tiene fetchpriority=»high» y no tiene lazy?
CLS	≤ 0,1	Imágenes sin width/height, embeds, fuentes web	¿Cada elemento reserva su espacio antes de cargar?
INP	≤ 200 ms	JavaScript de terceros, bloques interactivos, DOM grande	¿Qué script ocupa el hilo principal al tocar la página?

Los bloques nativos generan HTML más liviano que muchos constructores visuales. Eso no garantiza pasar las métricas (ya vi demasiados sitios «limpios» con una portada de 4 MB sin dimensiones).

¿Y Gutenberg le gana a Elementor o a Divi? Las fuentes que usé no traen ningún benchmark comparativo, así que no pienso inventar uno. Lo que sí podés hacer es medir tu propio sitio con datos de campo y decidir con eso.

¿Cómo optimizar imágenes en WordPress para mejorar el LCP?

Desde WordPress 6.3 el core agrega fetchpriority=»high» a la imagen que detecta como candidata a LCP, y según la nota de desarrollo de make.wordpress.org eso típicamente mejora el LCP entre 5 y 10 %. Tu trabajo es no pisarlo: sin lazy loading en la imagen principal, formatos modernos, tamaños responsivos y compresión antes de subir.

• Prioridad automática. La imagen es elegible si supera un umbral mínimo de 50.000 px² (ancho por alto). Ese umbral se ajusta con el filtro wp_min_priority_img_pixels.
• Lazy loading fuera del primer pantallazo. Las imágenes que probablemente queden abajo reciben loading="lazy".
• Umbral de omisión de 1 a 3. El filtro wp_omit_loading_attr_threshold pasó de 1 a 3 en la 6.3 para cuidar los layouts de varias columnas con imágenes.
• Una función central. wp_get_loading_optimization_attributes() decide hoy los atributos fetchpriority y loading en contenido, miniaturas, avatares, imagen de cabecera y widgets.
• Decoding asíncrono. decoding="async" viene por defecto desde la 6.1, y la 6.4 lo consolidó en esa misma función.

Ahora lo práctico: convertí a WebP o AVIF, subí tamaños acordes al lugar donde van a verse y comprimí antes de subir. No te doy porcentajes de ahorro porque las fuentes no los traen.

¿Por qué no usar lazy loading en la imagen principal?

Porque el lazy loading le dice al navegador que espere y fetchpriority=»high» le dice que corra. Son órdenes contradictorias, y la nota de 6.3 las describe como «an anti-pattern that should be avoided» (un anti-patrón que hay que evitar). Por eso la función del core nunca devuelve ambos atributos para la misma imagen.

¿Quién te lo rompe entonces? Un plugin de optimización con la opción «lazy load a todas las imágenes» activada es el sospechoso clásico.

Ejemplo hipotético (no es una medición mía): tu home abre con un bloque Portada con una foto de 1920 × 1080. Supera por lejos los 50.000 px², así que WordPress la marca como candidata. Si un plugin además le pone lazy, el LCP se arrastra justo en el elemento que más importa. Abrí el HTML renderizado y buscá si esa foto es una etiqueta img o un fondo CSS, porque la lógica del core trabaja sobre etiquetas img e iframe. Lo explicamos a fondo en la comparativa entre WordPress y Gutenberg.

¿Cómo ajustar fetchpriority con código cuando la detección falla?

Desde la 6.4 podés tocar el resultado con el filtro wp_get_loading_optimization_attributes, o reemplazar la lógica entera con pre_wp_get_loading_optimization_attributes. Este ejemplo adapta uno de la nota de 6.4 y fuerza la prioridad en una imagen puntual (cambiá la URL por la tuya):

function priorizar_imagen_portada( $loading_attrs, $tag_name, $attr, $context ) {
 if ( 'img' === $tag_name ) {
 if (
 'the_content' === $context &&
 isset( $attr['src'] ) &&
 $attr['src'] === 'https://tusitio.com/wp-content/uploads/portada.jpg'
 ) {
 $loading_attrs['fetchpriority'] = 'high';
 } else {
 unset( $loading_attrs['fetchpriority'] );
 }
 }
 return $loading_attrs;
}
add_filter( 'wp_get_loading_optimization_attributes', 'priorizar_imagen_portada', 10, 4 );

Spoiler: usalo solo si la detección automática se equivoca. Fijate que este código saca fetchpriority de todas las demás imágenes, incluidas las de la cabecera. Además, la 6.4 asume que las imágenes dentro de template_part_header y get_header_image_tag están arriba del primer pantallazo.

¿Cómo evitar el layout shift (CLS) con bloques nativos?

Para mantener el CLS en 0,1 o menos (el umbral de web.dev), cada elemento tiene que reservar su espacio antes de cargar: imágenes con width y height, relación de aspecto definida en Imagen, Portada y Video, contenedores con altura para embeds y publicidad, y fuentes que no muevan el texto al aparecer.

Checklist para el editor de bloques y el tema:

• Dimensiones en cada imagen. Los bloques nativos suelen incluir width y height, pero verificá en el HTML renderizado, sobre todo en imágenes que entran por HTML personalizado o por plugins.
• Relación de aspecto fija. Revisá el control en los bloques Imagen, Portada y Video para que el espacio exista antes de que cargue el archivo.
• Embeds con contenedor. Un video o una publicación de redes se arma dentro de un iframe cuya altura se conoce tarde. Envolvelo con proporción fija.
• Publicidad y banners con altura mínima. Un anuncio que llega tarde empuja todo hacia abajo.
• Pocas fuentes web, bien cargadas. Usá pocas familias, alojalas en tu servidor, precargá la principal o directamente usá fuentes del sistema. El theme.json te deja declararlas en un solo lugar.
• Nada que se inserte arriba del contenido. Barras de cookies y avisos que aparecen tarde mueven la página.

El CLS se rompe seguido después de publicar, cuando alguien del equipo pega un embed o un banner «chiquito».

¿Cómo mejorar el INP en WordPress?

El INP mide qué tan rápido responde la página cuando alguien interactúa, y web.dev fija 200 ms o menos como umbral bueno. En WordPress la palanca más usada es sacar JavaScript: el de los plugins, el de terceros y un DOM grande, que encarece cada interacción. No te prometo un número de mejora, porque depende de cada sitio.

Instalás un plugin de formularios, después uno de sliders, el de chat, el pixel de la agencia, el de reseñas, cada uno carga su script en todas las páginas, y cuando alguien toca el menú en un celular de gama media el hilo principal está ocupado ejecutando cosas que esa página nunca usó.

• Reducí plugins que cargan scripts. Cada uno suma JavaScript, así que revisá cuáles justifican su costo.
• Cargá los assets solo donde se usan. El script del formulario va en /contacto, no en toda la web.
• Controlá el JavaScript de terceros. Chats, pixeles y tags son los que más suelen escaparse del control del desarrollador.
• Mantené el DOM chico. Anidar Grupo dentro de Columnas dentro de Grupo infla la página sin que nadie lo note.

Una limitación: Lighthouse no mide INP y usa el Total Blocking Time (TBT) como indicador. El INP real sale de campo. Más contexto en el impacto de Elementor en el SEO.

¿Qué temas y plugins conviene usar con Gutenberg para no perder performance?

Conviene un tema de bloques (block theme) con theme.json, que mantiene el HTML limpio y los estilos centralizados, y revisar cuánto JavaScript y CSS suma cada plugin que agrega bloques. A eso sumale un hosting con respuesta rápida del servidor: web.dev señala que el TTFB sirve para diagnosticar un LCP lento por culpa del servidor.

• Tema de bloques liviano. Menos capas de estilos y menos HTML para pintar.
• Auditá los plugins de bloques. Una librería con 60 bloques que usás tres puede estar cargando recursos para los otros 57. Comprobalo en DevTools.
• Un solo plugin de caché y optimización. Dos haciendo lo mismo suelen pisarse. Y ninguno arregla una imagen LCP con lazy loading.
• Hosting con buena base técnica. Para sitios en Argentina, el hosting WordPress de Donweb es una opción natural para probar. Medí el TTFB antes y después de migrar: el hosting mueve la aguja solo si el servidor era el cuello de botella.

Sobre Speculation Rules y precarga de páginas, las fuentes de esta guía no traen datos. Prefiero no prometerte nada.

¿Cómo verificar que las mejoras funcionaron?

Medí antes y después con Lighthouse y PageSpeed Insights en laboratorio, y esperá a que Search Console y CrUX acumulen mediciones de visitantes reales, porque el campo no se actualiza al instante. El laboratorio confirma que el cambio funciona; solo el campo confirma que tus visitantes lo notan.

Lista de verificación por métrica:

• LCP: el elemento LCP del informe tiene fetchpriority=»high» y no tiene lazy, y el valor en el percentil 75 baja de 2,5 s.
• CLS: ninguna imagen ni embed se mueve al cargar, y el valor queda en 0,1 o menos.
• INP: los scripts que sacaste no aparecen en la página, el TBT de laboratorio baja y el INP de campo se acerca a 200 ms.

En la práctica, juzgá el resultado después de varias semanas de datos, no a las pocas horas (es mi criterio, no un plazo oficial). Y recordá que Core Web Vitals es una señal entre muchas, no reemplaza la calidad del contenido.

Una salvedad de fecha: a octubre de 2026, la página de web.dev que consulté tiene su última actualización del 31 de octubre de 2024, y las notas de WordPress son de 2023. No vi en esas fuentes cambios posteriores en los umbrales, pero revisá el changelog de web.dev antes de pasarle números a un cliente.

Si querés profundizar en cómo cargan los recursos de WordPress, tenemos una guía sobre prefetching en load-scripts.php para optimizar Core Web Vitals.

Si querés profundizar en esto, tenemos un artículo sobre Core Web Vitals con Gutenberg donde lo vemos en detalle.

Errores comunes al optimizar Core Web Vitals en Gutenberg

• Lazy loading a todas las imágenes con un plugin. Incluye la imagen LCP y anula el trabajo del core. Corregilo excluyendo la primera imagen o dejando que WordPress decida.
• Poner fetchpriority=»high» a mano en varias imágenes. Si todo es prioridad, nada lo es (inferencia mía). Dejá una sola, la que realmente sea el LCP.
• Juzgar por una corrida de Lighthouse en tu notebook. web.dev aclara que el laboratorio no reemplaza al campo, porque el dispositivo y la red del visitante cambian el resultado.
• Revisar solo escritorio. La evaluación se segmenta entre móvil y escritorio, y en móvil suele costar más.
• Creer que un tema liviano resuelve todo. El HTML limpio ayuda, pero una portada pesada o diez scripts de terceros lo arruinan.

Preguntas Frecuentes

¿Cómo mejorar los Core Web Vitals en WordPress con Gutenberg?

Medí con Search Console y PageSpeed Insights, y corregí por métrica: priorizá la imagen LCP sin lazy loading, definí width y height en imágenes y embeds para el CLS, y recortá JavaScript de plugins y terceros para el INP. Empezá por la URL de más tráfico en móvil. Sobre eso hablamos en nuestra guía sobre la comunidad de WordPress.

¿Gutenberg es más rápido que Elementor para Core Web Vitals?

Las fuentes de esta guía no traen un benchmark que lo pruebe. Los bloques nativos suelen generar HTML más liviano, pero el resultado depende de tus imágenes, tus plugins y tu hosting, así que medí tu sitio.

¿Por qué no debo usar lazy loading en la imagen principal?

Porque lazy loading y fetchpriority=»high» se contradicen: uno pospone la carga y el otro la acelera. La nota de WordPress 6.3 lo llama anti-patrón y el core nunca devuelve ambos atributos para la misma imagen. Si ves lazy en tu imagen principal, el culpable probable es un plugin o el tema.

¿Qué valores son buenos para LCP, INP y CLS?

Según web.dev, son buenos un LCP de 2,5 s o menos, un INP de 200 ms o menos y un CLS de 0,1 o menos, medidos en el percentil 75 de cargas reales y segmentados por móvil y escritorio. Una página aprueba cuando cumple los tres.

¿Lighthouse mide el INP?

No: Lighthouse no mide INP y web.dev recomienda mirar el Total Blocking Time (TBT) como indicador de laboratorio. El INP real sale de datos de campo (CrUX, Search Console, PageSpeed Insights) o de monitoreo propio con la librería web-vitals.

Conclusión

Los Core Web Vitals en Gutenberg se resuelven con pocas decisiones concretas: auditar con datos de campo, dejar que WordPress priorice la imagen LCP (mejora típica de 5 a 10 % según su equipo de Core), reservar espacio en cada bloque y sacar JavaScript que no usás. El HTML limpio de los bloques nativos ayuda, pero no aprueba nada solo.

Qué hacer esta semana: elegí tus tres URLs de más tráfico, anotá el «antes» en móvil, revisá que ninguna imagen principal tenga lazy loading y auditá los plugins que cargan scripts en todas las páginas. Después esperá a que el campo se actualice y comparás.

Fuentes

• Web Vitals (web.dev) – definición oficial, umbrales y herramientas de medición
• Image performance enhancements in WordPress 6.3 (make.wordpress.org) – fetchpriority y lazy loading
• Image loading optimization enhancements in 6.4 (make.wordpress.org) – nuevos filtros y decoding async