Core Web Vitals checklist para WordPress 2026

Los Core Web Vitals siguen siendo un problema real: según la documentación oficial de Google, menos del 50% de los sitios en la web pasan todas las métricas (según datos 2025). En cada auditoría que hago, el patrón se repite: sitios que técnicamente «funcionan» pero que desde el punto de vista de las métricas de experiencia de usuario, están en rojo. El Core Web Vitals checklist de este artículo es el que uso en cada relevamiento, con los errores más frecuentes y cómo atacarlos.

Hosting es el servicio que proporciona espacio en servidores para almacenar y mantener accesible en internet los archivos de un sitio web. Surgió con la infraestructura de internet y la World Wide Web, permitiendo que cualquier contenido esté disponible públicamente en línea.

Por qué los Core Web Vitals siguen fallando en la mayoría de los sitios

Los Core Web Vitals son el conjunto de métricas que Google usa para medir la experiencia del usuario en términos de velocidad de carga, estabilidad visual e interactividad. Desde 2021 forman parte de los factores de ranking, y desde 2024 el FID (First Input Delay) fue reemplazado por INP (Interaction to Next Paint) como métrica oficial, lo que dejó desactualizados a un montón de guías que todavía circulan por ahí.

El problema con la tasa de fallos no es falta de herramientas. Es que la mayoría de los sitios WordPress se construyen rápido, con themes pesados, plugins que meten scripts en el header sin permiso y hostings compartidos donde el servidor ya viene al límite. Ponele que armaste un sitio en un par de semanas con Elementor, instalaste 30 plugins porque «alguno capaz sirve», subiste imágenes directo del celular y lo publicaste. Ese sitio va a tener un LCP de 5 segundos mínimo, con suerte.

Según Google Search Central, el reporte de Core Web Vitals en Search Console muestra datos de campo reales de Chrome (el CrUX dataset), no simulaciones de laboratorio. Ahí está la diferencia: un sitio puede «verse rápido» en tu MacBook con fibra óptica y tener métricas de campo pésimas porque tus usuarios reales usan Android de gama media con 4G irregular.

LCP, CLS e INP: los tres pilares que tenés que tener claros

LCP (Largest Contentful Paint) mide cuánto tarda en renderizarse el elemento más grande visible en la pantalla. Para Google, el umbral «bueno» es menor a 2.5 segundos. Entre 2.5 y 4 segundos es «necesita mejoras». Por encima de 4 segundos, rojo.

CLS (Cumulative Layout Shift) mide la inestabilidad visual: ese fenómeno molesto de que el contenido se mueve mientras cargás la página porque una imagen aparece de repente y empuja el texto. El umbral bueno es menor a 0.1. Por encima de 0.25, rojo.

INP (Interaction to Next Paint) reemplazó al FID en marzo de 2024. Mide la respuesta a interacciones del usuario (clicks, teclado, toques). Bueno: menor a 200ms. Necesita mejoras: entre 200 y 500ms. Rojo: más de 500ms.

Lo interesante es que en la práctica, el 80% de los problemas que veo en auditorías se concentran en LCP. Si resolvés el LCP, la mitad de las otras métricas mejoran como efecto secundario, porque el problema suele ser el mismo: un servidor lento o assets pesados que bloquean el render. Relacionado: obtener ayuda de la comunidad WordPress.

Los 5 errores más comunes que encontré auditando sitios WordPress

Estos son errores reales, de sitios reales, no de un laboratorio.

1. Imágenes sin dimensiones explícitas

El clásico. Subís una imagen, no le ponés width y height en el HTML, y el navegador no sabe cuánto espacio reservar hasta que la descarga. Resultado: layout shift. Este solo error destruye el CLS de la mayoría de los sitios. En WordPress, si usás el bloque de imagen nativo, desde la versión 5.5 se agregan las dimensiones automáticamente. El problema viene con themes viejos o con código custom que no respeta eso.

2. El LCP image sin preload

El hero image, el banner principal, la imagen del header. Ese elemento que el browser tiene que renderizar primero para que el LCP sea bajo. Si ese recurso no tiene un `` en el head, el browser lo descubre tarde, lo carga tarde, y el LCP se va al demonio. Es uno de los ajustes más rápidos de implementar y uno de los que más impacto tiene. (Spoiler: la mayoría de los sitios no lo tienen.)

3. JavaScript de terceros que bloquea el render

Google Analytics en el header. Hotjar. Un plugin de chat que carga su script de forma síncrona. Scripts de redes de ads. Cada uno de esos puede agregar 200-800ms al tiempo de carga. Subís el modelo, lo probás en local sin esos scripts, todo funciona bárbaro, lo mandás a producción y de repente el LCP es 5 segundos porque el vendor de analytics decidió que su script tenía que estar antes que todo lo demás.

4. Fuentes web sin font-display: swap

Cargar fuentes desde Google Fonts o desde el servidor propio sin la directiva `font-display: swap` hace que el texto sea invisible mientras la fuente carga. El navegador espera. El LCP espera. El usuario espera. Y si la fuente tiene 300KB entre todas las variantes, estás regalando varios segundos de render invisible.

5. CSS no crítico cargado de forma síncrona

El CSS completo del theme en un solo archivo de 500KB, cargado en el head de forma síncrona, bloquea el render hasta que termina de descargarse y parsearse. Si separás el CSS crítico (el que se necesita para renderizar lo que está arriba del fold) e inline lo metés en el head, el resto puede cargarse de forma diferida. Pocos themes lo hacen por defecto. Pocos plugins de optimización lo hacen bien.

Checklist completo: 12 pasos para auditar tu sitio

Este es el flujo que sigo en cada auditoría. Ordenado de diagnóstico a implementación. Para más detalles técnicos, mirá mejorar la experiencia de usuario.

• Paso 1 — PageSpeed Insights: Primera medición en PageSpeed Insights. Anotá LCP, CLS e INP tanto en móvil como en desktop. El número de móvil es el que importa para ranking.
• Paso 2 — Search Console, reporte CWV: Verificá el reporte «Experiencia de la página» en Search Console. Muestra datos de campo reales (CrUX), no laboratorio. Si hay URLs marcadas en rojo, empezá por esas.
• Paso 3 — Identificar el elemento LCP: En Chrome DevTools, abrí la pestaña Performance, grabá una carga y buscá el marcador «LCP». Fijate qué elemento lo dispara. En el 70% de los casos es una imagen.
• Paso 4 — Auditar imágenes: ¿Tienen width y height explícitos? ¿Están en WebP o AVIF? ¿El LCP image tiene preload? ¿Las imágenes below the fold tienen lazy loading?
• Paso 5 — Revisar scripts de terceros: Con la pestaña Network de DevTools, filtrá por JS y ordená por tamaño. Identificá scripts de terceros. Verificá si tienen defer o async. Si no, ese es tu problema.
• Paso 6 — Auditar fuentes: ¿Cargan desde Google Fonts (round-trip extra)? ¿Están self-hosted? ¿Tienen font-display: swap?
• Paso 7 — Verificar caché del navegador: Los assets estáticos (CSS, JS, imágenes) deberían tener headers Cache-Control con max-age largo. Si cambian a cada rato sin versionado, el browser los descarga siempre.
• Paso 8 — Activar compresión Gzip/Brotli: Con DevTools o con una herramienta como web.dev, verificá que los assets de texto (HTML, CSS, JS) se sirvan comprimidos. En hosting compartido esto suele estar disponible desde el panel.
• Paso 9 — CDN para assets estáticos: Si el servidor está en Argentina y tus usuarios son de Argentina, el impacto del CDN es menor. Pero si tenés usuarios de otros países, un CDN reduce el TTFB de forma notable. Cloudflare free plan alcanza para la mayoría.
• Paso 10 — Plugin de caché: W3 Total Cache, LiteSpeed Cache (si el hosting lo soporta), WP Rocket. La caché de página elimina el tiempo de procesamiento PHP en cada request. Si tu hosting tiene LiteSpeed (como el hosting WordPress de Donweb), usá LiteSpeed Cache que aprovecha las directivas del servidor directamente.
• Paso 11 — Minificación de CSS y JS: Reducí el tamaño de archivos eliminando espacios y comentarios. Lo hace cualquier plugin de optimización. Ojo con minificar JS que no fue escrito para eso: a veces rompe funcionalidad.
• Paso 12 — Segunda medición y comparación: Volvé a PageSpeed Insights. Comparás los números. Si el LCP bajó y el CLS está bajo 0.1, bien. Si no, revisás el paso donde el Waterfall del Performance tab muestre el cuello de botella.

Optimizaciones rápidas que funcionan en hosting compartido

No tenés root. No podés tocar nginx.conf. No podés instalar módulos de PHP. Aun así, hay bastante margen.

Caché de navegador vía .htaccess: En servidores Apache (que es lo que tiene la mayoría del hosting compartido), podés agregar directivas de caché en el .htaccess. La mayoría de los plugins de caché lo hacen automáticamente, pero si querés entender qué están haciendo, es básicamente esto: ` Header set Cache-Control «max-age=31536000, public» `.

Compresión Gzip: chequeá desde el panel de control si está activa. En cPanel hay una sección específica. Si no está, algunos plugins la activan vía .htaccess también.

Para imágenes, Imagify, ShortPixel o Smush hacen la conversión a WebP y la optimización de forma automática al subir. No necesitás acceso al servidor. El impacto en LCP cuando tenés imágenes sin optimizar puede ser de 1 a 3 segundos directamente.

¿Y qué pasa con los scripts de terceros en hosting compartido? Los controlás desde WordPress, no desde el servidor. El atributo defer en el script tag lo agrega cualquier plugin de optimización. Script Optimizer, Autoptimize, o WP Rocket tienen esta opción. Ojo con activar defer en jQuery si el theme depende de jQuery cargado de forma síncrona: la mitad de los themes viejos se rompen.

Herramientas gratuitas para monitorear Core Web Vitals

Herramienta	Tipo de datos	Cuándo usarla
PageSpeed Insights	Lab + Field (CrUX)	Primera auditoría, comparar antes/después
Google Search Console (reporte CWV)	Field real	Monitoreo continuo, detectar URLs problemáticas
Chrome DevTools (Performance)	Lab	Diagnosticar elemento LCP, waterfall de carga
web.dev/measure	Lab (Lighthouse)	Reporte Lighthouse completo con recomendaciones
WebPageTest	Lab	Pruebas desde distintas ubicaciones, filmstrip

Para monitoreo ongoing, el reporte de Search Console es el más importante porque usa datos reales de usuarios reales, no una simulación. PageSpeed Insights también muestra datos de campo si hay suficiente tráfico en el CrUX dataset, pero si el sitio tiene poco tráfico, solo muestra datos de laboratorio. Te puede servir nuestra cobertura de crear landing pages de alto rendimiento.

Caso de estudio: de LCP 6.8 segundos a 2.1 segundos en un e-commerce

Sitio WooCommerce de indumentaria (2025), 800 productos, theme Flatsome, hosting compartido. Cuando llegué, PageSpeed Insights en móvil marcaba:

• LCP: 6.8 segundos (rojo)
• CLS: 0.31 (rojo)
• INP: 420ms (necesita mejoras)

El waterfall mostraba que el elemento LCP era el banner hero de la home. Una imagen de 1.4MB en JPEG, sin dimensiones explícitas, sin preload, servida desde el mismo servidor sin CDN. El CLS venía de las imágenes de productos sin width y height en los thumbnails de WooCommerce.

Las acciones tomadas, en orden:

• Convertir el banner hero a WebP y comprimirlo a 180KB con Imagify (de 1.4MB a 180KB, sí, en serio)
• Agregar preload del banner en el head del theme
• Agregar width y height a todos los thumbnails de producto vía hook de WooCommerce
• Activar LiteSpeed Cache con caché de página habilitada
• Diferir todos los scripts de terceros (Google Analytics, un widget de reviews) con WP Rocket
• Pasar las fuentes de Google Fonts a self-hosted con font-display: swap

Tiempo de implementación: 6 horas distribuidas en dos días. Resultados a los 30 días (con datos de campo, no laboratorio):

• LCP: 2.1 segundos (verde)
• CLS: 0.08 (verde)
• INP: 160ms (verde)

El cliente reportó un aumento del 18% en conversiones comparando los 30 días anteriores y posteriores. No puedo atribuirlo solo a las CWV, porque también coincidió con una campaña, pero la tasa de rebote en móvil bajó 12 puntos. Eso sí es directamente correlacionable con la velocidad.

Preguntas Frecuentes

¿Por qué mis Core Web Vitals están fallando si el sitio «se ve rápido»?

Los datos de laboratorio (lo que ves en PageSpeed Insights bajo condiciones ideales) difieren de los datos de campo reales. Si usás una computadora rápida con buena conexión, el sitio te va a parecer veloz. Tus usuarios reales probablemente tienen dispositivos más lentos y conexiones variables. Google usa datos de campo del CrUX dataset (datos reales de Chrome) para el ranking, no datos de laboratorio.

¿Qué métrica es más importante: LCP, CLS o INP?

LCP impacta más en la percepción de velocidad y es el que más fallan los sitios, así que es el primero a atacar. CLS es el más fácil de corregir una vez que identificás las imágenes sin dimensiones. INP es el más complejo porque depende de JavaScript en runtime, no de la carga inicial. Para WordPress, en el 80% de los casos, resolver LCP y CLS es suficiente para pasar a verde. Esto se conecta con lo que analizamos en probar optimizaciones antes de publicar.

¿Cuánto tiempo demora optimizar Core Web Vitals?

Las optimizaciones básicas (imágenes, caché, defer de scripts) toman entre 2 y 8 horas en un sitio WordPress estándar. Los resultados en datos de campo tardan entre 28 y 35 días en reflejarse en Search Console porque Google acumula datos de un período de 28 días. No esperes ver mejoras inmediatas en el reporte CWV aunque los laboratorios ya muestren verde.

¿Cuál es el error más común en WordPress para Core Web Vitals?

Imágenes sin optimizar, sin dimensiones explícitas y sin preload del elemento LCP. Es el error que aparece en el 90% de los sitios que audité. Una imagen hero de 1MB o más sin preload es suficiente para que el LCP supere los 4 segundos en móvil. La corrección es rápida: comprimir la imagen, convertirla a WebP y agregar un link de preload en el head.

¿Los Core Web Vitals afectan directamente el ranking de Google?

Sí, son un factor de ranking desde 2021 y forman parte de las señales de «experiencia de página». No es el factor más pesado (el contenido y los links siguen siendo más determinantes), pero en nichos competitivos donde el contenido es similar, puede ser el diferencial. Google indicó que sitios con «buena» experiencia de página tienen ventaja sobre sitios con contenido equivalente.

Conclusión

El Core Web Vitals checklist que uso no tiene nada de mágico. Son 12 pasos que atacan los problemas más frecuentes en un orden lógico: primero medís, después identificás el cuello de botella, después corregís de mayor a menor impacto. El 90% de los sitios WordPress fallan por las mismas tres cosas: imágenes pesadas sin preload, scripts de terceros que bloquean el render y ausencia de caché.

Lo que sí varía es la profundidad con la que podés optimizar según el hosting. Con acceso a un servidor que soporte LiteSpeed o con una configuración de caché bien armada, los resultados son notablemente mejores que en un hosting compartido genérico. No es el único factor, pero importa.

Si tu sitio está en rojo y no sabés por dónde arrancar: abrí PageSpeed Insights, pegá la URL, fijate cuál de las tres métricas está peor, y empezá por ahí. Un LCP de 7 segundos se puede bajar a 2.5 en una tarde con las herramientas correctas. No requiere rehacer el sitio.

Fuentes

• Google Search Central — Core Web Vitals: documentación oficial de métricas y umbrales
• Google Search Console Help — Reporte de Experiencia de Página
• web.dev/performance — Guías técnicas de rendimiento web de Google
• Rafa Sospedra — Guía práctica de Core Web Vitals en español
• KDOSD — Core Web Vitals: qué son y cómo mejorarlas