Google usa las Core Web Vitals para posicionar, pero una buena nota no asegura salir arriba. Por sí solas tampoco te dicen qué hacer.
Para convertir estas métricas técnicas en decisiones de negocio, traduce cada fallo a la plantilla que lo causa (el molde que comparten las páginas de un mismo tipo) y a la tarea del visitante que estropea: así sabes qué arreglar primero y en qué no gastar.
Qué son las Core Web Vitals
Web Vitals es la iniciativa de Google para dar una guía única sobre los indicadores de calidad de la web. Las Core Web Vitals son la parte que se aplica a todas las páginas: el LCP (carga), el INP (respuesta) y el CLS (estabilidad visual), que según Google deben medir todos los propietarios de sitios.
En español tienen dos nombres: Métricas web principales en la Búsqueda de Google y Métricas web esenciales en web.dev, su sitio para desarrolladores. Desde el 12 de marzo de 2024, el INP sustituye al FID, que solo medía la primera interacción.
Las tres métricas web y sus umbrales
Las tres métricas web tienen tres tramos cada una: buena, necesita una mejora y deficiente. Para aprobar, una página tiene que ser buena en las tres.
| Métrica | Qué mide | Buena | Necesita una mejora | Deficiente |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | El tiempo hasta que aparece el mayor elemento visible | Hasta 2,5 s | Hasta 4 s | Más de 4 s |
| INP (Interaction to Next Paint) | La demora en responder a clics, toques y teclas | Hasta 200 ms | Hasta 500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Los saltos inesperados del contenido | Hasta 0,1 | Hasta 0,25 | Más de 0,25 |
Desliza a la izquierda: tres fichas, una por fila →
Cada valor se lee en el percentil 75 de las visitas: si al menos el 75 % de las visitas a una página cumple el umbral bueno, la página es buena en esa métrica. Google eligió ese percentil para que lo cumpla la mayoría de las visitas sin que manden los valores extremos.
Cómo se miden las métricas web: campo y laboratorio
Las métricas web principales son, ante todo, datos de campo: salen de visitas reales. Un dato de campo no es un número, es una distribución. El laboratorio carga la página con un dispositivo y una red fijos para poder repetir la prueba.
| Herramienta | Qué datos da | Para qué te sirve |
|---|---|---|
| Search Console | De campo, por grupos de URL | Ver qué plantillas fallan y en qué dispositivo |
| PageSpeed Insights | De campo (28 días) y de laboratorio | Revisar una URL y ver pistas para corregirla |
| Lighthouse | De laboratorio | Reproducir un fallo y probar el arreglo |
| Medición propia de usuarios reales | De campo, visita a visita | Saber qué página o qué interacción empeora |
Desliza a la izquierda: cuatro fichas, una por fila →
El laboratorio no puede medir el INP, porque nadie toca la página: Lighthouse usa el tiempo total de bloqueo (TBT), que suma el exceso sobre 50 milisegundos de cada tarea que bloquea el navegador. Un buen resultado de laboratorio no demuestra que tus usuarios aprueben, y un mal dato de campo no dice qué código corregir: necesitas los dos.
Cómo leer las métricas por plantilla, dispositivo y tarea
Las métricas técnicas se leen por grupos de páginas, no como una nota de toda la web: el informe de Search Console agrupa las URL con una experiencia parecida y etiqueta cada grupo por dispositivo, móvil u ordenador.
Search Console aconseja un orden: primero lo deficiente y, dentro de cada estado, lo que afecta a más URL o a las más importantes (para ti, las plantillas que traen contactos o ventas). Si además han bajado las visitas desde el buscador, mira qué revisar en Search Console cuando cae el tráfico orgánico. Lee esos grupos en tres capas.
- Plantilla. Traduce cada grupo a su plantilla: servicio, entrada del blog, ficha de producto o página de contacto. Un fallo en la plantilla se repite en cada página que la usa.
- Dispositivo. Los límites son los mismos, pero un grupo puede ser bueno en ordenador y deficiente en móvil: mira en cuál te llegan los contactos.
- Tarea. Pregúntate qué hace el visitante en esa plantilla: leer, abrir el menú o pedir presupuesto. El mismo retraso pesa más en tu formulario que en una entrada antigua (repasa los errores en formularios web).
De la métrica técnica a la decisión de negocio
Convertir una métrica técnica en una decisión de negocio exige cruzar cuatro factores: la gravedad del fallo, a cuántas páginas llega, lo que pesa la tarea en tu negocio y el riesgo del cambio.
| Señal | Tarea en riesgo | Qué decides |
|---|---|---|
| LCP deficiente | El contenido principal tarda en verse | Revisar la imagen principal y el servidor de esa plantilla |
| INP deficiente | El menú, un filtro o el formulario responden tarde | Darle prioridad si pasa donde se pide presupuesto o se compra |
| CLS deficiente | Un clic por error o perder el punto de lectura | Buscar el bloque que se mueve; si es común, se arregla una vez |
| Laboratorio bien, campo mal | Optimizar para un escenario que no es el tuyo | Decidir con el campo; el laboratorio, para reproducir el fallo |
| Sin datos de campo | No puedes afirmar que cumples | No pagar por «aprobar»: medir tus visitas reales o esperar |
Desliza a la izquierda: cinco fichas, una por fila →
Qué arreglo pedir para cada métrica web
Cada métrica web tiene arreglos conocidos, que puedes pedir a quien mantiene tu web.
- LCP. Por orden de efecto probable, según la guía del LCP: que el HTML inicial nombre la imagen principal, con prioridad alta y sin carga diferida, que la retrasa hasta que va a verse; que no la frenen hojas de estilo ni scripts; que pese poco, en formatos como AVIF o WebP, y que el servidor empiece antes a enviar la página (el TTFB).
- INP. Que el hilo principal del navegador, el que ejecuta el código, esté libre cuando tocas algo: partir las tareas largas, cargar menos código al abrir la página y no generar mucho HTML tras cada clic, como propone la guía del INP.
- CLS. Que imágenes, vídeos, anuncios e incrustados tengan su hueco reservado, que los avisos no empujen el contenido y que la letra provisional ocupe lo mismo que la definitiva: así se atajan las causas más comunes de un CLS deficiente.
Qué decisiones de negocio cambian las Core Web Vitals
Las Core Web Vitals pesan en cinco decisiones que no son técnicas.
- Arreglar o rehacer. Si falla un bloque, se arregla; si falla la base de la web (el tema, el maquetador o los plugins), quizá compense rehacerla. Para decidirlo, lee cuándo rediseñar y cuándo optimizar, y compara WordPress a medida o plantilla.
- Cómo lanzas las campañas. Según la guía del LCP, las redirecciones de anuncios y enlaces acortados alargan el TTFB, y los parámetros únicos que se añaden a la URL para medir pueden impedir que la página salga de la caché de una CDN (una red de servidores con copias de tu web). Repasa qué debe resolver una landing para Google Ads.
- Qué piezas externas se quedan. Un mapa o un vídeo incrustado sin hueco reservado mueve la página, y un chat puede frenar su respuesta mientras arranca: decide si te compensa o basta con reservarle su sitio o cargarlo más tarde.
- Qué pides a quien mantiene la web. Un criterio medible, como «buena en móvil en el percentil 75 de los datos de campo de esa plantilla», y no «subir la nota de PageSpeed».
- Cuándo no gastar. Si las tres ya son buenas con datos de campo, no pagues por la nota perfecta: según Google, perseguirla solo por SEO quizá no compense tu tiempo.
Un ejemplo inventado: del botón que tarda a la decisión
Una web inventada, que no es un caso de Navarting, ve en Search Console un INP deficiente en móvil en sus páginas de servicio, las del botón de pedir presupuesto. Al reproducir el fallo, tocando el botón mientras la página aún carga, el retraso coincide con el arranque del chat de un proveedor externo, que carga en todas ellas.
Con los cuatro factores, el arreglo va primero: el fallo es deficiente, llega a todas las páginas de servicio, estropea la tarea que trae contactos y el cambio tiene poco riesgo. La decisión no es solo técnica: como el chat se usa, se queda, pero pasa a cargarse cuando alguien lo abre. Se prueba en una copia de esa plantilla y se publica. Después, «Empezar revisión» en Search Console vigila 28 días de datos reales. Vale como prueba que el grupo deje de ser deficiente; los presupuestos se miden aparte.
Checklist de priorización
Antes de aprobar un arreglo de rendimiento, repasa estos 8 puntos.
Marca lo que ya está y llévate la lista a tu equipo.
0de 8
Límites de estas métricas web
Las métricas web principales no miden toda la experiencia: una página puede aprobarlas y seguir siendo confusa, y otra suspender por una integración necesaria. Tampoco miden el contenido ni la accesibilidad, que tiene su referencia en las pautas WCAG 2.2.
Los umbrales pueden cambiar: compruébalos en la fuente oficial el día que audites. Y esta guía no sustituye a una auditoría técnica.
Preguntas frecuentes sobre las Core Web Vitals
¿Las Core Web Vitals influyen en el posicionamiento?
Sí: Google dice que sus sistemas de posicionamiento las usan. Pero la Búsqueda intenta mostrar siempre el contenido más relevante, aunque su experiencia sea deficiente, y un buen informe no garantiza aparecer arriba.
¿Mejorar las Core Web Vitals aumenta las ventas?
No se puede dar por hecho. En un caso que publicó web.dev en 2021, Vodafone Italia mejoró el LCP un 31 % y vendió un 8 % más en una prueba A/B, repartiendo las visitas a medias entre la página optimizada y la de siempre. Sin una prueba así, atribuir más ventas a una mejora técnica es suponer: una puntuación no es una promesa comercial.
¿Por qué Search Console no muestra datos de mi web?
Porque la propiedad es nueva o porque el Informe sobre la experiencia del usuario en Chrome (CrUX), de donde salen los datos, aún no reúne bastantes de ese tipo de dispositivo: solo incluye páginas públicas con visitas suficientes. Si un grupo de URL no llega, Search Console lo junta con el resto de su origen (por ejemplo, todo https://www.tuweb.com).
¿Por qué PageSpeed Insights y Search Console no dan lo mismo?
Porque no miden lo mismo. PageSpeed Insights da el dato de campo de una URL, o de su origen si no hay bastante, y una prueba de laboratorio en un solo dispositivo simulado. Search Console da el dato de un grupo de URL parecidas y conserva los parámetros de URL que distinguen una página; PageSpeed Insights los quita. Compara siempre campo con campo.
Siguiente paso
Elige una plantilla y una tarea antes de pedir optimizaciones. Si el problema está en cómo se hizo la web, así trabajamos el diseño y desarrollo web; si vas a cambiar de web, compara estas métricas antes y después, dentro del rediseño web.
Fuentes
Las páginas se consultaron por última vez el 2 de octubre de 2026.
- web.dev: Métricas web esenciales, LCP, INP, cómo se definieron los umbrales, tiempo total de bloqueo y datos de laboratorio frente a datos de campo.
- web.dev: guías para optimizar el LCP, el INP y el CLS; el INP sustituye al FID, casos de impacto en el negocio y el caso de Vodafone.
- Centro de la Búsqueda de Google: Métricas web principales y resultados de búsqueda y experiencia en la página.
- Ayuda de Search Console: informe de métricas web principales. Chrome para desarrolladores: Informe sobre la experiencia del usuario en Chrome. Documentación de PageSpeed Insights.
- W3C: Pautas de accesibilidad WCAG 2.2.
Historial de actualizaciones
Publicado el 22 de septiembre de 2026.
Actualizado el 3 de octubre de 2026.
Añadidos: qué son estas métricas y sus nombres en español, los tramos de cada una, las herramientas de campo y de laboratorio, cómo leerlas por plantilla, dispositivo y tarea, qué arreglo pedir para cada una, qué decisiones de negocio cambian, un caso medido con prueba A/B y preguntas frecuentes.
¿Te suena? Mejorar la conversión de tu web
Ver cómo lo abordamos