LCP, INP, CLS: lo que mide cada métrica
Tres métricas, tres dimensiones distintas de la experiencia percibida. El LCP mide la velocidad de carga, el INP la capacidad de respuesta, el CLS la estabilidad visual. Ninguna sustituye a las demás: una página puede mostrarse rápido y resultar inutilizable, o responder al instante mientras baila ante los ojos. La auditoría trata las tres por separado.
LCP — Largest Contentful Paint
El LCP mide el tiempo transcurrido hasta que se muestra el elemento visible más grande de la ventana: generalmente una imagen hero, un vídeo o un bloque de texto voluminoso. Umbral de aprobación: menos de 2,5 segundos. Por encima de 4 segundos, la página se considera lenta. El LCP está dominado por cuatro factores: el tiempo de respuesta del servidor (TTFB), los recursos que bloquean el renderizado (CSS y JS síncronos), el tiempo de carga del propio recurso y el retraso antes de que el navegador lo descubra.
INP — Interaction to Next Paint
El INP reemplazó al FID en marzo de 2024. Mide la latencia entre una interacción del usuario (clic, toque, pulsación de tecla) y el siguiente renderizado visual que se deriva de ella. A diferencia del FID, que solo juzgaba la primera interacción, el INP observa todas las interacciones de la sesión y retiene la peor. Umbral: menos de 200 milisegundos. Un INP degradado revela casi siempre un hilo principal saturado por JavaScript demasiado largo.
CLS — Cumulative Layout Shift
El CLS cuantifica los desplazamientos visuales inesperados: un botón que salta porque un banner se carga con retraso, una imagen sin dimensiones que empuja el texto. Umbral: menos de 0,1. Es una puntuación sin unidad, calculada sobre la fracción de la pantalla desplazada multiplicada por la distancia del desplazamiento.
Datos de laboratorio frente a datos de campo
Una auditoría Core Web Vitals creíble se apoya en dos fuentes complementarias que con demasiada frecuencia se confunden. Los datos de laboratorio diagnostican, los datos de campo validan.
Los datos de laboratorio provienen de una visita simulada, en condiciones estandarizadas: una máquina definida, una red limitada, sin caché. Lighthouse es su fuente de referencia. Su fortaleza es la reproducibilidad y la depuración: usted aísla una causa, corrige y vuelve a medir de inmediato. Su límite: no reflejan a su audiencia real, sus dispositivos, sus conexiones.
Los datos de campo (field data) provienen del Chrome User Experience Report (CrUX) o de su propio RUM (Real User Monitoring). Agregan las visitas reales sobre 28 días móviles. Es este dato el que Google utiliza para juzgar una URL, y es el que se muestra en Search Console.
| Criterio | Datos de laboratorio | Datos de campo |
|---|---|---|
| Fuente | Lighthouse, simulación | CrUX, RUM, Search Console |
| Condiciones | Estandarizadas, reproducibles | Dispositivos y redes reales |
| INP medible | No (sin interacciones reales) | Sí |
| Uso | Diagnosticar y depurar | Validar el impacto real |
| Veredicto de Google | Ninguno | Determina la conformidad |
Consecuencia práctica: no juzgue nunca el INP con una puntuación de laboratorio. Lighthouse no hace clic en nada. El INP solo existe en el campo. Una auditoría que anuncia un INP 'perfecto' desde Lighthouse se equivoca de herramienta.
Las herramientas para llevar a cabo la auditoría
Cinco herramientas bastan, cada una para un uso preciso. La trampa es utilizar una sola y creer que la auditoría está terminada.
El punto de partida. Agrupa sus URL por estado (bueno, a mejorar, deficiente) a partir de los datos de campo. Revela la magnitud real del problema a escala del sitio, no de una página aislada.
La única herramienta que muestra laboratorio Y campo lado a lado para una URL. Ideal para confirmar que un problema de laboratorio se verifica en los usuarios reales.
Para el diagnóstico profundo. Enumera las oportunidades cuantificadas: recursos bloqueantes, imágenes sobredimensionadas, JS sin usar. Es aquí donde usted encuentra las causas raíz.
Para el INP y el hilo principal. Usted registra una interacción real y ve exactamente qué tarea JS bloquea el renderizado.
Para medir de forma continua en sus propios recorridos, en condiciones reales, sin esperar la agregación de CrUX.
El método: Search Console para enmarcar, PageSpeed Insights para priorizar las páginas tipo, Lighthouse y el panel Performance para diseccionar cada métrica. No se ahogue en el detalle de una URL antes de tener una visión de conjunto. Esta lógica de encuadre antes que detalle es la misma que la de una auditoría SEO completa.
Corregir cada métrica, por causa raíz
Una corrección eficaz apunta a la causa dominante, no a todos los síntomas. Cada métrica tiene sus propias palancas. Se corrige, se vuelve a medir, se pasa al siguiente cuello de botella.
Corregir el LCP
Empiece por el TTFB: un servidor lento o una caché ausente lastra todo lo demás. Active la caché, acerque el dato mediante un CDN, aligere el renderizado del lado del servidor. Después, dé prioridad al recurso LCP: fetchpriority="high" en la imagen hero, precarga (preload) de la fuente y de la imagen crítica, eliminación del lazy-loading en el elemento above-the-fold. Por último, elimine los recursos que bloquean el renderizado: CSS crítico en línea, JS no esencial en defer.
Corregir el INP
El INP se gana en el hilo principal. Divida las tareas largas de JavaScript en fragmentos más cortos, difiera todo lo que no sea necesario para la interacción inmediata y traslade los cálculos pesados a un Web Worker. Desconfíe de los scripts de terceros (tags de analítica, chat, A/B testing): suelen ser el primer responsable de un INP degradado.
Corregir el CLS
El CLS se resuelve casi siempre mediante la reserva de espacio. Declare sistemáticamente width y height (o aspect-ratio) en las imágenes y vídeos. Reserve el espacio de los banners y anuncios antes de su carga. Cargue las fuentes con font-display: optional o precárguelas para evitar el desplazamiento del texto (FOIT/FOUT).
El LCP es con diferencia la métrica que más a menudo falla en los sitios franceses. El culpable número uno sigue siendo el TTFB, seguido de las imágenes hero no optimizadas y del JavaScript bloqueante. Corregir el servidor antes que las imágenes ofrece casi siempre el mejor retorno.
Un detalle estructural pesa sobre el conjunto: las páginas renderizadas únicamente del lado del cliente. Los LLM no ejecutan JavaScript, lo que hace que el SSR o el HTML estático sean indispensables para la visibilidad IA — y el mismo renderizado del servidor mejora mecánicamente el LCP al entregar el contenido sin esperar la hidratación. Una sola decisión de arquitectura sirve a dos objetivos.
Para estructurar este enfoque de principio a fin, nuestra checklist de auditoría SEO 2026 integra un apartado de rendimiento directamente accionable.
Impacto SEO real y arbitraje de prioridades
Los Core Web Vitals son un factor de posicionamiento, pero un factor menor. Seamos precisos para evitar tanto la sobreinversión como la negligencia. Pertenecen a la señal de experiencia de página, que desempata resultados de relevancia comparable. Nunca compensarán un contenido débil, y un sitio que ya está en la zona verde no ganará posiciones pasando de 2,4 a 1,8 segundos de LCP.
El arbitraje racional sigue tres reglas. Primero, salir de la zona roja es prioritario; pasar del verde claro al verde oscuro no lo es. Segundo, trate las plantillas, no las URL aisladas: corregir la plantilla de una categoría repara miles de páginas de una sola vez. Tercero, el impacto de negocio supera a menudo el impacto SEO directo — una página más rápida convierte mejor, y la tasa de rebote cae.
Este equilibrio forma parte del trabajo de optimización técnica continua que llevamos a cabo para nuestros clientes como agencia SEO: cruzar los umbrales, asegurar el terreno y luego invertir allí donde la palanca de crecimiento es real. Para aplicar este rigor a su propia auditoría, el Pack de Plantillas de Auditoría GEO proporciona las cuadrículas de medición y de priorización listas para usar.
Solicite su auditoría GEO gratuita: rendimiento técnico, citabilidad IA y prioridades clasificadas por ganancia real.
Questions fréquentes
¿Son los Core Web Vitals un factor de posicionamiento de Google?+
Sí, pero un factor menor. Forman parte de la señal de experiencia de página, que desempata resultados de relevancia comparable. Una página lenta con un contenido superior puede superar a una página rápida con contenido débil. Los Core Web Vitals actúan como criterio de desempate, no como palanca de relevancia.
¿Qué diferencia hay entre la puntuación de Lighthouse y los datos de Search Console?+
Lighthouse mide una visita simulada en laboratorio, en una máquina y una red estandarizadas. Search Console muestra los datos de campo (CrUX), agregados sobre las visitas reales de los últimos 28 días, en el percentil 75. Es este dato de campo el que determina si una URL se considera conforme por parte de Google.
¿El INP ha reemplazado al FID?+
Sí. Desde marzo de 2024, el INP (Interaction to Next Paint) reemplaza al FID como métrica de capacidad de respuesta. El INP es más exigente: mide la latencia de todas las interacciones de una página, no solo la primera, y retiene la peor. Muchos sitios conformes con el FID fallan en el INP.
¿Cuánto tiempo pasa antes de ver el efecto de una corrección Core Web Vitals?+
Las herramientas de laboratorio muestran el efecto de inmediato. Los datos de campo de Search Console, en cambio, se calculan sobre una ventana móvil de 28 días. Por tanto, hay que esperar unas cuatro semanas tras el despliegue para ver el estado de una URL pasar a la zona verde.
