Page Experience Metrics: entender Core Web Vitals

Definicion rapida

Las Page Experience Metrics miden como se siente una pagina para personas reales: carga rapido el contenido principal, el layout permanece estable, botones y menus responden sin retraso visible, la pagina es usable en movil, segura y sin interrupciones agresivas? En SEO, el subconjunto mas conocido es Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift.

El encuadre importa. Page experience no reemplaza relevancia, intencion de busqueda ni contenido util. Google explica que una buena experiencia puede ayudar, pero no gana sola si el contenido no resuelve la tarea. Para los equipos, page experience no es solo un tema tecnico. Es la parte de la calidad de contenido que el usuario siente en el navegador.

Terminos cubiertos en esta pagina

• Page experience signal
• Largest Contentful Paint, o LCP
• Cumulative Layout Shift, o CLS
• Interaction to Next Paint, o INP
• First Input Delay, o FID, hoy deprecated
• First Contentful Paint, o FCP
• Time to First Byte, o TTFB
• Total Blocking Time, o TBT
• Speed Index
• Layout stability
• Input latency
• Perceived performance
• Performance API para monitorizar Core Web Vitals

Explicacion simple

Una pagina puede ser fuerte editorialmente y sentirse mal. Tal vez el titulo aparece rapido, pero la imagen hero llega tarde. Tal vez un boton salta hacia abajo cuando se carga un anuncio. Tal vez alguien toca un menu y la pagina responde medio segundo despues porque demasiado JavaScript bloquea el main thread. Las Page Experience Metrics hacen visibles esos momentos.

Core Web Vitals cubre tres preguntas. LCP pregunta: cuando esta listo el contenido visible mas importante? INP pregunta: con que rapidez responde la pagina a interacciones durante la visita? CLS pregunta: que tan estable permanece el layout? Estas tres metricas son datos de campo y deben ser buenas en el percentil 75, separadas por movil y desktop. Importa porque los promedios pueden verse bien mientras muchos usuarios reales siguen teniendo problemas.

Las metricas de apoyo ayudan al diagnostico. FCP muestra cuando algo se vuelve visible. TTFB muestra si servidor y entrega frenan desde el inicio. TBT muestra en lab si tareas largas de JavaScript pueden bloquear interacciones. Speed Index describe que tan rapido el viewport parece lleno. No todas son senales de ranking, pero ayudan a encontrar el problema correcto.

Por que este tema se entiende mal

El primer error es pensar en scores. Un Lighthouse de 100 es bonito, pero no es lo mismo que experiencia real. Lighthouse es diagnostico lab bajo condiciones controladas. Search Console y Chrome UX Report muestran datos de campo de usuarios reales. Ambos sirven, pero para preguntas diferentes.

El segundo error es enfrentar page experience y contenido. Buen rendimiento no vuelve util un contenido debil. Buen contenido pierde impacto cuando la pagina es lenta, inestable o intrusiva. La mejor pregunta no es "contenido o tecnologia?", sino "que friccion impide que el contenido haga su trabajo?"

El tercer error es optimizar metricas aisladas. Un problema de LCP puede venir de servidor, imagenes, fonts, CSS bloqueante, render client-side o prioridad. Un problema de INP puede venir de JavaScript, codigo third-party, tareas largas o interacciones caras. Un problema de CLS puede venir de imagenes sin dimensiones, anuncios, iframes, fonts o contenido insertado tarde.

Reglas de decision

• Usa datos de campo para saber como viven la pagina usuarios reales.
• Usa datos lab para diagnostico reproducible.
• Prioriza LCP cuando el contenido principal aparece tarde.
• Prioriza INP cuando clics, taps o teclado se sienten lentos.
• Prioriza CLS cuando los saltos de layout danan confianza o causan clics erroneos.
• Usa FCP y TTFB como diagnostico de carga, no como reemplazo de LCP.
• Usa TBT como pista lab para posibles problemas de INP.
• Evalua por plantilla y tipo de pagina, no solo por promedio de dominio.
• No persigas numeros perfectos si usuarios y objetivo de negocio ya estan bien servidos.

Flujo practico de auditoria

Empieza con Search Console y PageSpeed Insights. Que grupos de URL tienen malos Core Web Vitals? Movil y desktop son diferentes? El problema afecta todo el sitio, una plantilla, un mercado o pocas URL importantes? Despues elige muestras: una URL importante con muchas impresiones, una URL mala del grupo afectado y una URL buena de comparacion.

El segundo paso separa campo y lab. Los datos de campo dicen si usuarios reales tienen un problema. El lab muestra donde buscar. Si LCP es malo, inspecciona el elemento LCP, peso de imagen, prioridad de recurso, tiempo de servidor, CSS y render. Si INP es malo, busca tareas largas, scripts third-party, event handlers caros y JavaScript innecesario. Si CLS es malo, revisa dimensiones reservadas, ads, embeds, fonts y banners tardios.

El tercer paso conecta con contenido. La pagina da una respuesta clara arriba o el usuario debe seguir buscando? Popups de newsletter o widgets de chat interrumpen la tarea? Los enlaces internos ayudan o distraen? Page experience no es solo milisegundos. Es la friccion entre intencion del usuario y respuesta.

Buen y mal ejemplo

Mal ejemplo: "Lighthouse esta en 96, asi que page experience esta lista." Es demasiado simple. El test lab puede ser bueno mientras usuarios moviles reales en dispositivos lentos tienen mal INP. O el rendimiento tecnico puede estar bien mientras un banner de cookies tapa el contenido principal.

Buen ejemplo: "Las plantillas de guias tienen mal LCP movil en el percentil 75. El elemento LCP suele ser la imagen hero. Reducimos peso de imagen, priorizamos la imagen principal, revisamos TTFB y luego miramos si las paginas no marca mas importantes mejoran en datos de campo. En paralelo quitamos un overlay de newsletter del primer viewport." Esta diagnosis conecta metrica, plantilla, causa y tarea del usuario.

Detalles que suelen faltar

FID ya no es la metrica actual de Core Web Vitals para responsiveness. INP reemplazo a FID porque FID solo miraba el primer retraso de entrada. INP observa interacciones durante la visita y se acerca mas a lo que el usuario siente como lentitud.

Core Web Vitals se evalua con percentiles. El percentil 75 significa que al menos tres cuartas partes de las paginas vistas deben cumplir el umbral bueno. Quien mira solo promedios suele olvidar a usuarios con dispositivos debiles, conexiones lentas o sesiones complejas.

Perceived performance no es una metrica oficial unica de Core Web Vital, pero importa en la practica. Una pagina puede ser mediana tecnicamente y sentirse tranquila si da feedback rapido, usa skeletons con cuidado y evita saltos. Una pagina tecnicamente rapida puede sentirse inestable si el contenido aparece, desaparece o se mueve.

Errores frecuentes

• Confundir Lighthouse score con experiencia real.
• Reportar FID como metrica principal actual.
• Optimizar LCP sin revisar el elemento LCP real por plantilla.
• Ignorar INP porque los antiguos datos FID eran buenos.
• Probar CLS solo en carga inicial y perder saltos posteriores.
• Tratar scripts third-party como intocables.
• Leer page experience como tema puramente tecnico e ignorar friccion de contenido.

Fuentes para revision

• Google Search Central: Page Experience: https://developers.google.com/search/docs/appearance/page-experience
• Google Search Central: Core Web Vitals and Search: https://developers.google.com/search/docs/appearance/core-web-vitals
• Search Console Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• web.dev Web Vitals: https://web.dev/articles/vitals
• Core Web Vitals thresholds: https://web.dev/articles/defining-core-web-vitals-thresholds
• Largest Contentful Paint: https://web.dev/articles/lcp
• Interaction to Next Paint: https://web.dev/articles/inp
• Cumulative Layout Shift: https://web.dev/articles/cls
• First Contentful Paint: https://web.dev/articles/fcp
• Time to First Byte: https://web.dev/articles/ttfb
• Total Blocking Time: https://web.dev/articles/tbt
• Core Web Vitals tools workflow: https://web.dev/articles/vitals-tools
• INP replacing FID: https://web.dev/blog/inp-cwv

Perfiles de metricas

Page Experience Signal

No existe un interruptor unico de page experience. Google describe varios aspectos: Core Web Vitals, entrega segura, mobile usability, pocos anuncios distractores, sin interstitials intrusivos y separacion clara del contenido principal.

LCP

LCP mide cuando se renderiza el elemento visible relevante mas grande del viewport. Palancas tipicas: tiempo de servidor, imagenes, prioridad de recursos, CSS, fonts y estrategia de render.

CLS

CLS mide movimientos inesperados del layout. Buenas practicas: reservar dimensiones, estabilizar ads y embeds, cargar fonts con cuidado y evitar banners sin espacio.

INP

INP mide responsiveness en interacciones. Malos valores suelen venir de tareas largas, demasiado JavaScript, event handlers caros o codigo third-party.

FID

FID esta deprecated y fue reemplazado por INP. Sigue siendo historico, pero no debe ser el objetivo principal de optimizacion Core Web Vitals moderna.

FCP

FCP muestra cuando aparece el primer contenido visible. Ayuda en diagnostico de carga, pero no dice cuando esta listo el contenido principal.

TTFB

TTFB mide el tiempo hasta el primer byte de respuesta. Valores malos pueden afectar LCP, sobre todo en paginas dinamicas y entrega internacional.

TBT

TBT es una metrica lab de tiempo bloqueado del main thread despues de FCP. No es Core Web Vital, pero ayuda mucho a encontrar riesgo de INP.

Speed Index

Speed Index describe que tan rapido el viewport parece visualmente completo. Ayuda a discutir velocidad percibida.

Layout Stability

Layout stability es la calidad practica detras de CLS: leer, escribir y hacer clic sin que los objetivos se muevan de golpe.

Input Latency

Input latency es el retraso entre entrada y respuesta. Los usuarios lo notan rapido, incluso si las metricas de carga son buenas.

Perceived Performance

Perceived performance describe la sensacion subjetiva de velocidad y control. Nace de feedback rapido, UI estable, prioridad clara y pocas interrupciones.

Perspectiva Contextter

Contextter no mide el TTFB del servidor y no reemplaza un motor de performance. Su valor esta en tomar en serio la parte de contenido de page experience: la respuesta es visible rapido, esta clara, bien estructurada, conectada internamente y usable sin interrupciones? Ahi se encuentran SEO scoring y optimizacion tecnica.