Abrís tu sitio desde la computadora de la oficina y anda bien. Un cliente lo abre desde el celular, en la calle, con una conexión regular. La foto principal tarda, el botón de contacto se corre cuando lo va a tocar y el formulario no responde al primer intento. Cierra la pestaña y le escribe a otro.
Nadie te avisa de esas consultas perdidas. Las Core Web Vitals son la forma que tiene Google de medirlas: tres métricas que dicen si tu sitio carga rápido, responde rápido y se mantiene estable. En esta nota vas a ver qué mide cada una, cómo medir tu sitio y qué arreglar primero.
Tu sitio carga, pero ¿está perdiendo consultas?
Que un sitio "cargue" no dice mucho. La pregunta útil es cómo lo vive la persona que llega desde el celular, con el equipo y la conexión que tiene, en el momento en que quiere pedirte algo.
Google lo plantea en su documentación sobre Core Web Vitals y los resultados de la Búsqueda de Google: son métricas que miden la experiencia real del usuario en carga, interactividad y estabilidad visual. Google recomienda tener buenas Core Web Vitals para que te vaya bien en Search y para dar una buena experiencia en general.
Conviene ponerlo en su justa medida. En su guía sobre la experiencia de página en los resultados de la Búsqueda de Google, Google aclara que sus sistemas de ranking usan las Core Web Vitals. También dice que siempre busca mostrar el contenido más relevante, aunque la experiencia de página no sea la mejor. Cuando hay mucho contenido útil para una búsqueda, la experiencia puede marcar la diferencia.
Por eso este tema importa más por las consultas que por el ranking. Un sitio lento o inestable hace perder a la gente que ya llegó. Para saber dónde se pierde, primero hay que entender qué mide cada métrica.
Qué miden las Core Web Vitals: LCP, INP y CLS, en simple
Las tres métricas responden tres preguntas que se hace cualquier persona al entrar a un sitio. La guía de web.dev sobre Web Vitals y la ayuda de Search Console fijan los umbrales de cada una.
- LCP (Largest Contentful Paint): ¿ya cargó? Mide cuánto tarda en verse el elemento más grande de la pantalla, que suele ser la imagen principal o un bloque de texto grande. Lo bueno es 2,5 segundos o menos.
- INP (Interaction to Next Paint): ¿me responde? Mide cuánto tarda la página en reaccionar cuando tocás, hacés clic o escribís. Lo bueno es 200 milisegundos o menos.
- CLS (Cumulative Layout Shift): ¿se queda quieto? Mide cuánto se mueven los elementos de forma inesperada mientras mirás la página. Lo bueno es 0,1 o menos.
| Métrica | Qué pregunta responde | Buena | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | ¿Ya cargó lo principal? | Hasta 2,5 s | Hasta 4 s | Más de 4 s |
| INP | ¿Responde cuando la uso? | Hasta 200 ms | Hasta 500 ms | Más de 500 ms |
| CLS | ¿Se mantiene estable? | Hasta 0,1 | Hasta 0,25 | Más de 0,25 |
Un detalle importante: estos valores se miden sobre visitas reales y se toma el percentil 75. Dicho en simple, para que una página esté en verde, al menos tres de cada cuatro visitas tienen que tener una buena experiencia. Con eso claro, se puede ver en qué parte del recorrido del cliente duele cada métrica.
Dónde duele cada métrica en el recorrido del cliente
Cada métrica falla en un momento distinto de la visita. Pensarlo así ayuda a explicarle el problema a cualquier persona de la empresa, no solo a quien programa.
El LCP duele en la llegada. Es el primer segundo de la visita, cuando la persona viene de Google o de un anuncio y todavía no decidió quedarse. Si la imagen principal o el título tardan en aparecer, la sensación es que el sitio no anda, y muchos vuelven atrás antes de leer nada.
El INP duele en la acción. Aparece cuando la persona ya está interesada: abre el menú, filtra productos, elige una opción o completa el formulario. Si el sitio tarda en responder, la persona toca dos veces, duda y a veces abandona justo en el paso que más te importa.
El CLS duele en la confianza. Es el botón que se corre cuando un banner termina de cargar, o el texto que salta mientras leés. En el peor caso, la persona toca algo que no quería. En el mejor, se queda con la idea de que el sitio está descuidado.
Un ejemplo hipotético ayuda a ordenar: en un sitio de servicios, la página que más importa suele ser la landing comercial con el formulario. Ahí un INP malo pega directo en las consultas, mientras que un LCP algo lento en una nota vieja del blog pesa mucho menos. Para saber cuál es tu caso, hay que medir.
Cómo medir tu sitio: datos de campo frente a datos de laboratorio (Search Console y PageSpeed)
Hay dos tipos de datos, y confundirlos es la fuente de muchas discusiones. web.dev lo explica en su nota sobre por qué los datos de laboratorio y de campo pueden ser distintos.
- Datos de campo: salen de visitas reales de usuarios de Chrome, con sus equipos, sus redes y sus ubicaciones. Muestran lo que vive tu cliente.
- Datos de laboratorio: salen de una prueba simulada, con un equipo y una conexión predefinidos. Sirven para encontrar la causa de un problema y probar arreglos antes de publicarlos.
El informe Core Web Vitals de Search Console usa datos de campo de los últimos 28 días. Agrupa las URLs parecidas y las clasifica como Buena, Necesita una mejora o Deficiente, según la peor de las tres métricas. Solo incluye URLs indexadas que tengan suficientes visitas, así que un sitio chico puede no tener datos.
PageSpeed Insights combina las dos cosas para una URL puntual: arriba muestra los datos de campo, si existen, y abajo una prueba de laboratorio con recomendaciones. Es normal que los números no coincidan con Search Console, porque miden cosas distintas.
La regla práctica de web.dev es clara: si tenés datos de campo y de laboratorio, priorizá con los de campo, porque reflejan a tus usuarios reales. El laboratorio te ayuda a encontrar la causa. Y las causas, en la mayoría de los sitios, se repiten.
Los culpables más comunes: imágenes, JavaScript, fuentes y plugins
Cuando un sitio está en rojo, el origen casi siempre está en una de estas cuatro familias. Ninguna es exótica, y casi todas se pueden detectar con la prueba de laboratorio de PageSpeed.
- Imágenes pesadas o mal cargadas. Una foto principal enorme, sin un formato moderno ni un tamaño adecuado para el celular, es la causa más común de un LCP malo. La guía de web.dev para optimizar el LCP detalla cómo priorizar ese recurso.
- Demasiado JavaScript. Scripts que bloquean el hilo principal hacen que la página tarde en responder. web.dev lo trata en su guía para optimizar el INP: tareas largas, código que se ejecuta de más y trabajo que se podría dividir.
- Fuentes web. Una tipografía que carga tarde puede demorar el texto o hacerlo saltar cuando aparece. Eso afecta tanto al LCP como al CLS.
- Plugins y scripts de terceros. Chats, píxeles, mapas, sliders y widgets suman peso y trabajo. Cada uno parece inofensivo, pero juntos pueden ser lo que más frena el sitio.
Una causa que suele pasar desapercibida es la base sobre la que está hecho el sitio. Algunos enfoques mandan mucho JavaScript al navegador aunque la página sea casi todo texto. Lo explicamos en cómo Astro ayuda al SEO con páginas que cargan poco JavaScript. Saber qué está fallando es útil, pero con un presupuesto limitado la pregunta real es por dónde empezar.
Qué arreglar primero: la priorización por impacto en el negocio
La tentación es atacar la URL con el peor puntaje. El orden que conviene es otro: primero las páginas que generan consultas, después el resto. La ayuda de Search Console va en la misma línea: corregí primero lo deficiente. Dentro de eso, priorizá lo que afecta a más URLs o a las más importantes.
Una forma simple de priorizar es cruzar dos listas:
- Páginas que importan para el negocio. Landings comerciales, fichas de producto, la página de contacto y las notas que más consultas traen, según tu Analytics.
- Problemas que detecta Search Console. Qué grupos de URLs están en Deficiente o Necesita una mejora, y por qué métrica.
- El cruce de las dos. Lo que aparece en ambas listas va primero. Un INP malo en la landing con el formulario pesa más que un CLS regular en una nota vieja del blog.
- Arreglos de plantilla. Si el problema está en un componente compartido, como el encabezado o el pie, un solo arreglo mejora muchas páginas a la vez.
Después de cada arreglo, validá en Search Console. La herramienta abre un período de seguimiento de 28 días para confirmar si el problema desapareció en las visitas reales. Esta forma de trabajar, con el negocio adelante y la técnica al servicio, es la que usamos al diseñar y desarrollar sitios que convierten visitas en consultas. A veces, sin embargo, la lista de arreglos crece tanto que la pregunta cambia.
Cuándo optimizar alcanza y cuándo conviene rehacer el sitio
La mayoría de los sitios mejora mucho con arreglos puntuales: comprimir imágenes, sacar plugins que nadie usa, cargar más tarde los scripts de terceros y ajustar las fuentes. Si tus problemas son de ese tipo, optimizar alcanza.
Hay señales de que el problema es más profundo:
- Cada arreglo rompe otra cosa. El sitio depende de tantos plugins o parches que tocar uno afecta a los demás.
- El tema o la plantilla es el problema. Todo el sitio carga el mismo código pesado, y cambiarlo implica rehacer el diseño.
- La base no permite mejorar. El enfoque con el que se construyó manda mucho JavaScript al navegador, y ningún ajuste lo resuelve del todo.
- El sitio ya tiene otros problemas. Si además del rendimiento el diseño está viejo o la carga de contenido es un dolor, rehacer resuelve varias cosas a la vez.
Si te toca rehacer, el cuidado principal es no perder lo que ya ganaste en Google. Lo detallamos en cómo rediseñar un sitio web sin perder el posicionamiento: URLs, redirecciones, contenido y medición antes y después del cambio. Quedan algunas preguntas que aparecen siempre que hablamos de velocidad.
Preguntas frecuentes
¿Las Core Web Vitals afectan el posicionamiento en Google?
Sí, los sistemas de ranking de Google las usan, según su propia documentación. Pero Google también aclara que busca mostrar el contenido más relevante. La velocidad no compensa una página que no responde lo que la persona busca.
¿Qué es una buena velocidad de carga para una página web?
La referencia de Google es un LCP de 2,5 segundos o menos, medido sobre el 75 % de las visitas reales. Además, la página tiene que responder en 200 milisegundos o menos y mantener un CLS de 0,1 o menos.
¿Por qué PageSpeed me da un puntaje distinto cada vez?
El puntaje sale de una prueba de laboratorio, que varía según el servidor, la red y el momento. Para decidir, mirá los datos de campo de Search Console o de la parte superior de PageSpeed, que reflejan las visitas reales.
Mi sitio no tiene datos en Search Console, ¿qué hago?
El informe necesita un mínimo de visitas para mostrar datos. Mientras tanto, usá PageSpeed Insights sobre tus páginas clave y priorizá con la prueba de laboratorio, sabiendo que es una aproximación.
¿Cada cuánto conviene revisar las Core Web Vitals?
Una revisión mensual del informe de Search Console suele alcanzar, y una revisión puntual después de cada cambio importante en el sitio: un plugin nuevo, un rediseño o una campaña que traiga mucho tráfico.
Las Core Web Vitals, al final, son una forma de medir algo muy concreto: si tu sitio deja pasar a la gente que ya llegó con ganas de contactarte. Si querés que miremos juntos qué está frenando el tuyo, contanos qué páginas te traen consultas hoy y vemos por dónde conviene empezar.
