Core Web Vitals: qué mueve de verdad las cifras
Las Core Web Vitals son tres mediciones de campo de cómo se siente una página: cuánto tarda en aparecer el contenido principal, cuánto se mueve mientras carga y con qué rapidez responde a la interacción. Son una señal de posicionamiento y, más importante, se correlacionan con que la gente se quede.
Esta guía cubre qué mide cada métrica, las causas concretas detrás de las malas puntuaciones y los arreglos que mueven los datos de campo y no solo los de laboratorio.
Qué miden las tres métricas#
Cada una tiene un umbral para «bueno» y un pequeño conjunto de causas habituales. Tenga en cuenta que la cifra que cuenta para el posicionamiento son los datos de campo de visitantes reales, no una puntuación de laboratorio desde su portátil.
| Métrica | Buena | Mide | Causa habitual cuando es mala |
|---|---|---|---|
| LCP | Menos de 2,5 s | Tiempo hasta que se dibuja el mayor elemento visible | Imagen principal sin optimizar, servidor lento, CSS que bloquea el renderizado |
| CLS | Menos de 0,1 | Cuánto se mueve la maquetación al cargar | Imágenes sin dimensiones, banners insertados, fuentes web tardías |
| INP | Menos de 200 ms | Capacidad de respuesta a la interacción | Tareas largas de JavaScript bloqueando el hilo principal |
Las herramientas de laboratorio miden una carga en una máquina. Los datos de campo son el percentil 75 de visitas reales, que incluye móviles antiguos en redes malas: justo los visitantes con más probabilidad de irse.
Arreglar el LCP#
El LCP es casi siempre una imagen o un titular bloqueado detrás de otra cosa. Vaya por orden; los dos primeros puntos arreglan casi todos los sitios.
- Identifique el elemento LCP real en los datos de campo. Optimizar la imagen equivocada es el esfuerzo desperdiciado más común.
- Nunca cargue en diferido la imagen del LCP. Dele fetchpriority="high" en su lugar.
- Sírvala en formato moderno al tamaño en que se muestra, con srcset para pantallas más pequeñas.
- Precargue la fuente que usa el texto del LCP y use font-display: swap para que el texto no sea invisible mientras espera.
- Elimine del head el CSS y el JavaScript que bloquean el renderizado; incruste el CSS crítico si la página es lo bastante pequeña.
- Reduzca el Time to First Byte con caché y un CDN: ningún trabajo de frontend compensa un servidor lento.
- Recorte los scripts de terceros en la ruta crítica. Cada uno es una resolución DNS, una conexión y un archivo impredecible.
Arreglar el CLS#
El desplazamiento de la maquetación es casi totalmente evitable y los arreglos son baratos. Además es la métrica que los visitantes notan de forma más visceral: es lo que hace que la gente pulse donde no quería.
- Ponga los atributos width y height en cada imagen y vídeo para que el navegador reserve el espacio.
- Reserve espacio para anuncios, incrustaciones e iframes con un contenedor de relación de aspecto fija.
- Nunca inserte contenido por encima del existente después de cargar: los avisos de cookies van abajo o superpuestos.
- Ajuste las métricas de la fuente de respaldo a la fuente web, o use size-adjust, para que el cambio no rehaga la página.
- Evite animar propiedades de maquetación. Anime transform y opacity, que no provocan recálculo.
- Dé a las secciones cargadas dinámicamente un min-height para que no crezcan desde cero.
Arreglar el INP#
El INP sustituyó al First Input Delay y es más difícil, porque mide cada interacción de la visita y no solo la primera. Un INP malo es casi siempre demasiado JavaScript ejecutándose en el hilo principal.
| Causa | Solución |
|---|---|
| Paquete grande analizado al cargar | Dividir el código; cargar solo lo que la página necesita |
| Tareas largas de más de 50 ms | Trocear el trabajo y ceder el hilo principal |
| Manejadores de eventos costosos | Aplicar debounce y sacar el trabajo pesado de la ruta de interacción |
| Etiquetas de terceros pesadas | Cargar tras la interacción, o quitar: audite qué aporta cada una |
| DOM grande (más de 10.000 nodos) | Virtualizar listas largas; simplificar el marcado muy anidado |
| Sacudida de maquetación en manejadores | Agrupar lecturas y escrituras en vez de alternarlas |
En sitios de contenido, el arreglo de INP de mayor valor suele ser borrar JavaScript en vez de optimizarlo. Pregunte qué aporta cada script; los gestores de etiquetas acumulan scripts que nadie recuerda haber añadido.
Preguntas frecuentes
¿Cuánto afectan las Core Web Vitals al posicionamiento?
Son una señal real pero moderada, y actúan como desempate más que como sustituto de la relevancia. Una página rápida sobre el tema equivocado no supera a una más lenta que responde a la consulta. El argumento más fuerte para arreglarlas es conductual: las páginas lentas y que saltan pierden visitantes antes de que el posicionamiento entre en juego.
¿Por qué mi puntuación de Lighthouse es buena y mis datos de campo malos?
Porque Lighthouse simula una carga en su máquina con su conexión, y los datos de campo son el percentil 75 de visitas reales, incluidos móviles de hace tres años en redes móviles congestionadas. Cuando ambos se contradicen, los que cuentan son los de campo. Use las herramientas de laboratorio para diagnosticar, no para puntuar.
¿Tengo que arreglar las tres métricas?
Arregle las que estén fallando, en el orden de lo que experimentan sus visitantes. El CLS suele ser el más barato de arreglar y el más molesto para el usuario, así que es un buen punto de partida. El LCP tiene el mayor efecto sobre si la gente espera. El INP importa más en sitios interactivos y menos en artículos estáticos.
¿Cuánto tardan en verse las mejoras?
Los datos de campo son una ventana móvil de 28 días, así que un movimiento apreciable tarda unas cuatro semanas desde que un arreglo llega a todos los visitantes. No juzgue un cambio a los tres días. Sí compruebe las métricas de laboratorio de inmediato para confirmar que el arreglo hizo lo que esperaba.
core web vitalslcpclsinpvelocidad de páginarendimiento web
