Core Web Vitals

Definicion rapida

Core Web Vitals son tres metricas de Google que miden si una pagina web se siente bien para usuarios reales: el contenido principal aparece rapido, la pagina responde pronto a clics y taps, y el layout permanece estable sin saltos inesperados.

Las Core Web Vitals actuales son LCP, INP y CLS. LCP significa Largest Contentful Paint y mide la experiencia de carga. INP significa Interaction to Next Paint y mide la capacidad de respuesta. CLS significa Cumulative Layout Shift y mide la estabilidad visual.

La clave esta en entender el alcance. Core Web Vitals no evalua si tu contenido es util, original o experto. Evalua la usabilidad tecnica alrededor de ese contenido. Una pagina rapida pero pobre no se convierte en un gran resultado de busqueda solo porque sus metricas esten en verde. Pero una pagina fuerte puede perder impacto si los usuarios esperan demasiado, los taps se sienten lentos o el contenido se mueve mientras leen.

Explicacion sencilla

Imagina que buscas una respuesta, haces clic en un resultado y llegas a una pagina. Primero ves el logo, la navegacion y un espacio vacio. Unos segundos despues aparece por fin la imagen principal o el articulo real. Eso es un problema de LCP.

Luego tocas un filtro, un menu o un acordeon. Tocas, pero durante un momento no pasa nada. La pagina esta visible, pero se siente pesada. Eso es un problema de INP.

Despues, un banner de cookies, un anuncio o una imagen que carga tarde empuja el contenido hacia abajo. Tu dedo ya iba hacia un boton y de repente tocas otra cosa. Eso es un problema de CLS.

Por eso Core Web Vitals es util. Convierte frases vagas como "la pagina se siente lenta" en senales concretas. SEO, desarrollo, diseno y contenido pueden hablar del mismo problema en vez de discutir desde impresiones distintas.

Por que Core Web Vitals importa para SEO

Google recomienda buenos Core Web Vitals para tener exito en Search y para ofrecer una buena experiencia general. Forman parte del marco mas amplio de page experience: las personas pueden usar la pagina con comodidad.

Aun asi, Core Web Vitals no es un milagro de ranking. Google quiere mostrar sobre todo resultados utiles y relevantes. Si una pagina no encaja con la intencion de busqueda, los numeros verdes no la salvan. Al mismo tiempo, una pagina relevante no deberia ignorar mala usabilidad, especialmente si competidores ofrecen contenido parecido con una experiencia mas fluida.

Para equipos SEO, estas metricas son valiosas porque hacen que el trabajo tecnico sea priorizable. "Mejorar page speed" es demasiado vago. "Nuestros templates de producto tienen mal LCP porque la imagen hero se descubre tarde" es accionable. "El INP mobile es malo porque un calculador de precios y scripts de terceros bloquean el main thread" es todavia mas claro.

El objetivo no es la perfeccion tecnica por si misma. El objetivo es ayudar a paginas importantes a cumplir su funcion: ser encontradas, ser entendidas, generar confianza y llevar al usuario al siguiente paso sin frustracion.

Las tres Core Web Vitals

LCP: Largest Contentful Paint

LCP mide cuando se ha cargado el elemento de contenido visible mas grande y relevante. Puede ser una imagen hero, un bloque grande de texto, una imagen de producto, un poster de video o un banner principal. La metrica no pregunta: "cuando empezo la pagina?" Pregunta: "cuando sintio el usuario que el contenido principal ya estaba presente?"

Un buen LCP es de 2,5 segundos o menos. Entre 2,5 y 4 segundos necesita mejora. Mas de 4 segundos es pobre.

Las causas comunes de un mal LCP incluyen respuesta lenta del servidor, imagenes demasiado pesadas, falta de imagenes responsive, CSS que bloquea render, demasiado JavaScript antes del contenido principal o client-side rendering que crea el contenido visible demasiado tarde. En muchos sitios modernos, no toda la pagina es lenta. El problema es que el elemento mas importante tiene mala prioridad.

Ejemplo: una landing page muestra rapido navegacion y color de fondo, pero la imagen principal del producto carga como un asset normal, sin prioridad. Los usuarios esperan el ancla visual que da sentido a la pagina. Para LCP, eso es un problema aunque elementos pequenos aparezcan pronto.

INP: Interaction to Next Paint

INP mide que tan rapido una pagina responde de forma visible a interacciones como clics, taps y entradas de teclado. No mira solo la primera interaccion. Evalua la capacidad de respuesta durante la visita.

Un buen INP es de 200 milisegundos o menos. Entre 200 y 500 milisegundos necesita mejora. Mas de 500 milisegundos es pobre.

INP reemplazo a First Input Delay, o FID, como Core Web Vital el 12 de marzo de 2024. Esto importa porque FID media una parte mas estrecha de la respuesta. INP esta mas cerca del uso real, sobre todo en paginas con mucho JavaScript, filtros, configuradores, mapas, widgets de chat o personalizacion.

Un mal INP suele venir de trabajo invisible en el navegador. Long tasks de JavaScript bloquean el main thread. Event handlers hacen demasiado a la vez. Scripts de terceros compiten con la interfaz. Para el usuario, la pagina parece cargada, pero no escucha bien.

CLS: Cumulative Layout Shift

CLS mide movimientos inesperados del layout. La pregunta es simple: la pagina se mantiene estable mientras los usuarios leen y hacen clic, o los elementos se mueven despues de empezar el render?

Un buen CLS es 0,1 o menos. Entre 0,1 y 0,25 necesita mejora. Mas de 0,25 es pobre. CLS no es un valor de tiempo, sino un score de estabilidad visual.

Las causas comunes incluyen imagenes sin dimensiones fijas, anuncios sin espacio reservado, contenido embebido, fuentes que cargan tarde, barras promocionales, banners de cookies o componentes dinamicos que ocupan espacio de repente despues del primer render.

CLS frustra especialmente porque dana la confianza. Si un boton se mueve en el ultimo momento, la pagina no solo se siente lenta; se siente poco fiable. En formularios, paginas de precios y checkouts, eso es mas que un detalle visual.

Entender los umbrales

Good, Needs Improvement y Poor

Los informes de Core Web Vitals usan tres rangos: Good, Needs Improvement y Poor. Estas etiquetas no son un juicio moral sobre tu sitio. Son una forma practica de priorizar.

Good significa que la experiencia probablemente es solida para la mayoria de usuarios. Needs Improvement significa que hay friccion visible que conviene planificar. Poor significa que el grupo de URL merece atencion seria porque una parte relevante de usuarios probablemente tiene una mala experiencia.

Por que importa el percentil 75

Core Web Vitals suele evaluarse en el percentil 75, separado por mobile y desktop. En palabras simples, al menos 75 por ciento de las visitas deberian cumplir el umbral bueno.

Esto es mas util que un promedio. Un promedio puede verse bien mientras muchos usuarios con telefonos lentos, redes debiles o navegadores antiguos siguen sufriendo. El percentil 75 empuja a los equipos a optimizar para la mayoria real, no solo para el entorno ideal de prueba.

Mirar mobile y desktop por separado

Muchos problemas de Core Web Vitals son bastante peores en mobile. Un test desktop con Wi-Fi rapido en la oficina puede tranquilizar mientras usuarios reales en mobile esperan o se frustran. No conviene mezclar mentalmente los datos mobile y desktop.

Si solo mobile es malo, la causa suele estar en potencia del dispositivo, red, peso de JavaScript, tamanos de imagen o layout responsive. Si mobile y desktop son malos, pueden pesar mas la respuesta del servidor, CDN, estrategia de render o arquitectura global de templates.

Field Data vs Lab Data

Field Data: uso real

Field data viene de usuarios reales, por ejemplo mediante Chrome UX Report o el informe Core Web Vitals de Search Console. Muestra como se comportan tus paginas en dispositivos, navegadores, redes, ubicaciones, recorridos y tipos de pagina reales.

Para priorizar en SEO, field data es especialmente importante. Responde: "donde tienen problemas los usuarios reales?" Eso evita optimizar solo para un escenario artificial de prueba.

Field data tambien tiene una caracteristica que puede impacientar a los equipos: no se actualiza al instante. Despues de un deploy, puede pasar tiempo hasta que nuevos datos de usuarios aparezcan. Puedes verificar cambios tecnicos rapido en lab, pero la vista real necesita nuevas visitas.

Lab Data: diagnostico controlado

Lab data viene de pruebas controladas como Lighthouse, PageSpeed Insights o Chrome DevTools. Es excelente para diagnosticar: que recurso bloquea el render, que imagen pesa demasiado, que script crea long tasks, que desplazamiento de layout ocurre durante la carga.

Lab data no sustituye field data. Un test lab puede verse bien en un dispositivo simulado mientras usuarios reales siguen sufriendo. Un solo test lab tambien puede verse mal aunque la mayoria real tenga una experiencia aceptable.

La mejor regla es simple: field data para priorizar, lab data para diagnosticar. Primero encuentra los grupos de URL con problemas reales. Luego usa herramientas lab para entender por que.

Grupos de URL y templates

Search Console suele trabajar con grupos de URL. Paginas similares se evaluan juntas. Para sitios grandes, esto ayuda porque un solo problema de template puede afectar cientos o miles de URLs.

Tambien aqui muchos equipos leen mal el informe. Optimizan una URL de ejemplo y se preguntan por que el grupo sigue mal. Si el problema esta en un template, componente reutilizado o script global, corregir una URL no resuelve el patron.

Para cada problema de Core Web Vitals, pregunta:

• Que tipo de pagina esta afectado?
• El problema aparece en mobile, desktop o ambos?
• Hay un componente compartido por las URLs afectadas?
• El candidato LCP es realmente el mismo elemento?
• Hay scripts de terceros que corren solo en ciertos templates?
• Los malos valores se concentran en paginas SEO importantes o en areas de bajo valor?

Estas preguntas evitan arreglos aleatorios. Optimizas el patron, no solo la URL mas ruidosa.

Como mejorar Core Web Vitals

Mejorar LCP

Para LCP, empieza por identificar el candidato LCP. Cuando sabes que elemento se mide, la optimizacion se vuelve mucho mas clara. Es una imagen, un bloque de texto, un banner o algo inesperado?

Los recursos frecuentes incluyen respuesta de servidor mas rapida, cache, CDN, formatos de imagen optimizados, tamanos correctos, imagenes responsive, preload de la imagen mas importante, menos CSS que bloquea render y una estrategia de render que no cree el contenido principal demasiado tarde.

Un detalle que muchos pasan por alto: lazy loading es util para imagenes mas abajo en la pagina, pero suele ser incorrecto para la imagen hero visible mas importante. Si el candidato LCP esta lazy-loaded, el navegador prioriza tarde justo el elemento que el usuario necesita primero.

Mejorar INP

INP trata del trabajo del navegador despues de las interacciones. No preguntes solo: "que tan grande es nuestro bundle JavaScript?" Pregunta tambien: "que pasa exactamente cuando alguien hace clic?"

Ayudan tareas mas cortas, code splitting, menos trabajo de hydration, event handlers rapidos, debouncing, throttling, Web Workers para calculos pesados y una revision dura de scripts de terceros. Chat, tracking, heatmaps, A/B testing y personalizacion pueden aportar valor, pero no deben bloquear la interaccion basica.

Una buena optimizacion de INP puede sentirse discretamente excelente. Un menu se abre sin duda. Un filtro responde enseguida. Un campo de formulario no se queda colgado. Esos momentos pequenos definen si un sitio parece profesional.

Mejorar CLS

Para CLS, la regla base es: reserva espacio antes de que llegue el contenido. Imagenes y videos necesitan width, height o aspect ratio. Ads y embeds necesitan contenedores planificados. Los banners no deberian empujar contenido despues del render. Las fuentes deberian cargar sin grandes saltos de texto.

Los componentes de consentimiento y promocion tambien importan. Un banner de cookies abajo suele molestar menos que una barra que ocupa espacio encima del contenido despues. Un popup de newsletter puede ayudar a conversion, pero si mueve el layout, la pagina paga con confianza.

Ejemplo realista

Una empresa SaaS tiene una pagina de comparacion importante. El contenido esta bien investigado, la intencion de busqueda encaja y la pagina atrae visitantes cualificados. Aun asi, la conversion mobile es debil. Search Console muestra INP pobre para todo el grupo de paginas de comparacion.

Un test Lighthouse en la oficina no parece terrible. Field data sigue mala. DevTools muestra el patron real: en telefonos medios, varias cosas pasan a la vez durante el primer scroll y los clics de filtros. Un script de A/B testing calcula variantes, un widget de chat se inicializa, tracking envia eventos y un calculador de comparacion actualiza muchos elementos DOM.

El equipo no elimina todo a ciegas. Prioriza por valor. El chat carga mas tarde. El calculador se divide en piezas mas pequenas. Eventos de tracking menos importantes se retrasan. El filtro actualiza primero la UI visible y hace el trabajo mas pesado despues. Tras el deploy, lab data muestra menos long tasks. Unas semanas despues, field data tambien mejora.

La ganancia real no es solo un informe verde. La pagina se siente mas tranquila y directa. Los usuarios comparan mas rapido, entienden mas y abandonan menos.

Malentendidos frecuentes

"Un score Lighthouse de 100 basta"

No. Lighthouse es util, pero un solo score lab no es la realidad de tus usuarios. Core Web Vitals debe conectarse con field data.

"Core Web Vitals es solo para desarrolladores"

No. Los desarrolladores implementan muchos arreglos, pero SEO, contenido, diseno, analytics y marketing influyen mucho en las causas. Imagenes hero enormes, widgets pesados, banners agresivos y personalizacion compleja no nacen solo de engineering.

"Si todo esta verde, rankearemos mejor"

No automaticamente. Las metricas verdes mejoran la usabilidad, pero no sustituyen relevancia, contenido util ni encaje con la intencion de busqueda.

"FID sigue siendo la metrica de interaccion"

No. INP reemplazo a FID como Core Web Vital. Si una auditoria todavia trata FID como metrica principal, esta desactualizada o al menos incompleta.

"Corregimos una URL y terminamos"

Rara vez. Muchos problemas viven en templates, componentes o scripts globales. Una URL suele ser solo un ejemplo de un patron mas grande.

Mini workflow para equipos SEO

1. Abre el informe Core Web Vitals en Search Console. 2. Separa mobile y desktop. 3. Identifica grupos de URL afectados y la metrica mas debil. 4. Revisa PageSpeed Insights para field data a nivel URL u origin. 5. Determina el tipo de pagina y el template responsable. 6. Usa Lighthouse y DevTools para diagnosticar causas. 7. Prioriza paginas con alto valor SEO, revenue o leads. 8. Escribe tickets concretos: candidato LCP, interaccion INP o causa CLS. 9. Vuelve a medir en lab despues del deploy. 10. Espera nueva field data antes de juzgar el exito final.

Buena priorizacion

No todas las alertas de Core Web Vitals tienen la misma importancia. Un grupo de URL pobre con muchas entradas organicas y alta relevancia de conversion es mas urgente que una zona de archivo con poco trafico. Un template mobile pobre suele importar mas que un caso aislado en desktop.

Una buena priorizacion combina:

• Potencial SEO de las paginas afectadas
• Valor business del recorrido afectado
• Gravedad de la metrica
• Numero de URLs afectadas
• Reutilizacion del arreglo
• Esfuerzo y riesgo de engineering

Asi Core Web Vitals deja de ser un juego infinito de performance y se convierte en un programa claro de mejora.

Perspectiva Contextter

Contextter no trata Core Web Vitals como un numero tecnico aislado. El SEO moderno depende de la combinacion: el contenido encaja con la intencion de busqueda, es util y especifico, aparece lo bastante rapido, y se puede leer, comparar y usar con comodidad.

Esta conexion importa especialmente en portfolios de contenido. Una pagina puede ser fuerte editorialmente y aun asi rendir poco si los usuarios ven el contenido principal tarde o si las interacciones mobile se sienten pegajosas. La perfeccion tecnica tampoco ayuda mucho si la pagina no responde bien a la consulta.

En un buen workflow SEO, Core Web Vitals no es el final de la optimizacion. Es la base tecnica de calidad. Profundidad de contenido, enlazado interno, intencion de busqueda, autoridad y guia de conversion se construyen encima.

Terminos relacionados

Estos terminos son buenos siguientes pasos:

• page-speed
• lighthouse
• server-side-rendering
• mobile-first-indexing
• javascript-rendering-seo

Fuentes para la revision

• web.dev: Web Vitals
• Google Search Central: Core Web Vitals and Google Search results
• Google Search Central: Page experience in Google Search
• web.dev: Interaction to Next Paint
• web.dev: Largest Contentful Paint
• web.dev: Cumulative Layout Shift
• Google Search Central Blog: Introducing INP to Core Web Vitals