Core Web Vitals 2026: qué mide Google y 10 arreglos para tu web

Las Core Web Vitals son las tres métricas con las que Google mide la experiencia real de quien visita tu web: cuánto tarda en verse lo importante (LCP), cuánto tarda en responder cuando tocas algo (INP) y cuánto «salta» la página mientras carga (CLS). En 2026 los umbrales siguen siendo 2,5 segundos, 200 milisegundos y 0,1, medidos sobre el 75 % de las visitas reales. Si tu web no los pasa, no desaparece de Google, pero compite con desventaja y, sobre todo, pierde clientes que se cansan de esperar.

Qué mide cada métrica (y qué significa para tu negocio)

LCP: cuánto tarda en aparecer lo importante

Largest Contentful Paint mide el tiempo hasta que se pinta el elemento más grande visible en pantalla: normalmente la foto de cabecera o el titular. Google considera bueno un LCP de 2,5 segundos o menos, según la documentación oficial de web.dev. Por encima de 4 segundos es «deficiente». En una web de pyme, el culpable casi siempre es una imagen de portada de 3 MB o un hosting lento.

INP: cuánto tarda en responder cuando alguien toca algo

Interaction to Next Paint sustituyó a FID como métrica oficial el 12 de marzo de 2024. Mide el retraso entre una interacción (un clic, un toque, una tecla) y el siguiente repintado de la pantalla. Bueno: 200 ms o menos; deficiente: más de 500 ms. Las webs hechas con muchos plugins y scripts de terceros (chats, mapas, vídeos incrustados, píxeles) son las que más sufren aquí.

CLS: cuánto se mueve la página mientras carga

Cumulative Layout Shift cuantifica esos saltos molestos: vas a pulsar un botón y de repente aparece un banner y pulsas otra cosa. Bueno: 0,1 o menos; deficiente: más de 0,25. Suele venir de imágenes sin dimensiones declaradas, fuentes que cambian al cargarse o anuncios y avisos de cookies que empujan el contenido.

Datos de campo frente a datos de laboratorio

Hay un matiz que confunde a mucha gente: la nota de Lighthouse o PageSpeed que ves en el panel «laboratorio» es una simulación. Lo que Google usa para evaluar tu web son los datos de campo del Chrome UX Report (CrUX), es decir, la experiencia real de usuarios de Chrome que han visitado tu página, medida en el percentil 75 y separando móvil de escritorio. Si tu web recibe poco tráfico, puede que ni siquiera tengas datos de campo; entonces conviene fijarse en los datos de laboratorio como aproximación, sabiendo que un móvil barato en 4G es más lento que el portátil de tu agencia.

Dónde mirarlo: PageSpeed Insights (muestra campo y laboratorio) y el informe «Métricas web principales» de Google Search Console, que agrupa las URL con problemas.

10 arreglos típicos en webs de pymes

1. Reducir la imagen de cabecera. Exporta en WebP o AVIF, a la anchura real a la que se muestra (no subas la foto original de la cámara) y carga esa primera imagen con prioridad (fetchpriority="high"), sin loading="lazy".
2. Carga diferida del resto de imágenes. Todo lo que no se ve al entrar debe llevar loading="lazy". Es un atributo HTML, no hace falta plugin.
3. Declarar ancho y alto en todas las imágenes. Con width y height el navegador reserva el hueco y el contenido no salta. Es el arreglo de CLS más barato que existe.
4. Fuentes: menos familias y precarga. Dos familias tipográficas como mucho, formato WOFF2, alojadas en tu propio dominio y con font-display: swap o, mejor, un ajuste de métricas para que el texto no se mueva al cambiar de fuente.
5. Quitar scripts de terceros que no usas. Cada chat, mapa, carrusel o píxel que añadiste «por si acaso» cuesta INP. Haz inventario y deja solo los que generan negocio.
6. Cargar lo pesado después de la interacción. El mapa de Google o el vídeo de YouTube pueden mostrarse como imagen y cargarse solo al pulsar. Es lo que llamamos «fachada».
7. Hosting y caché. Un servidor compartido saturado tarda 1-2 segundos solo en empezar a responder (TTFB). Caché de página, compresión Brotli o gzip y, si tu público está en España, un servidor en Europa.
8. CSS y JavaScript mínimos. Las plantillas genéricas cargan medio megabyte de CSS para usar el 5 %. Un desarrollo a medida carga lo que la página necesita y nada más.
9. Banner de cookies que no empuja el contenido. Que aparezca superpuesto (posición fija) y no inserte un bloque encima de la página. Lo mismo para barras de avisos.
10. Dividir el trabajo largo de JavaScript. Si una interacción tarda, suele ser porque un script bloquea el hilo principal más de 50 ms. Trocear tareas, usar requestAnimationFrame para pintar antes y aplazar lo no urgente mejora el INP sin rehacer la web.

¿Cuánto afecta al SEO?

Sin humo: la experiencia de página es un factor de posicionamiento, pero el contenido relevante pesa más. Dos webs con el mismo contenido, gana la rápida; una web lenta con mejor contenido puede seguir por delante. Lo que sí es seguro es que la velocidad afecta a la conversión: cada segundo extra en móvil son formularios que no se envían y llamadas que no se hacen. Por eso en nuestros proyectos web medimos las tres métricas antes de entregar y las revisamos cuando se añade contenido.

Preguntas frecuentes

¿Qué nota de PageSpeed necesito para «aprobar»?

Ninguna en concreto. Google evalúa las tres Core Web Vitals con datos reales, no la nota de 0 a 100 de Lighthouse. Céntrate en que LCP, INP y CLS estén en verde en el informe de Search Console.

¿Mi web en WordPress puede pasar las Core Web Vitals?

Sí, pero exige disciplina: tema ligero, pocos plugins, imágenes optimizadas y caché. La mayoría de webs de pymes que fallan lo hacen por acumulación de plugins, no por WordPress en sí.

¿Cada cuánto debo revisarlas?

Una vez al trimestre y siempre que cambies algo grande (nueva plantilla, nuevo plugin, nuevas fotos). Los datos de campo se calculan sobre los últimos 28 días, así que un arreglo tarda unas semanas en reflejarse.

Si quieres saber en qué punto está tu web y qué arreglos compensan, cuéntanos tu proyecto y te decimos qué haríamos primero.