Core Web Vitals: LCP, INP, CLS — qué miden, umbrales reales y cómo priorizarlos en 2026
Tres métricas que Google usa como señal de ranking, medidas con datos reales de usuarios — no con herramientas de laboratorio. La que más cambió: INP reemplazó a FID en marzo 2024 y subió la vara para todos los sites con interactividad.
Qué son exactamente Core Web Vitals
Core Web Vitals (CWV) son tres métricas que Google publica como criterio universal de experiencia de usuario en la web. No miden percepción subjetiva ni aspectos visuales: miden tiempos y comportamientos concretos del browser. Loading (cuánto tarda en aparecer el contenido principal), interactivity (cuánto tarda en responder a un click), visual stability (cuánto se mueven los elementos durante la carga).
Lo que las hace especiales para SEO: Google las mide con datos reales de usuarios de Chrome a través del Chrome User Experience Report (CrUX), no con herramientas de simulación. Eso significa que tu LCP en CrUX puede ser muy distinto al que ves en Lighthouse — y el que cuenta para ranking es CrUX.
Las tres métricas, con umbrales y qué miden cada una
Largest Contentful Paint
LCP mide cuánto tarda en renderizarse el elemento más grande visible en el viewport. Casi siempre es la imagen hero o un H1 grande. La métrica se dispara cuando ese elemento está pintado en pantalla.
Optimizaciones típicas: hosting rápido, CDN bien configurado, imágenes priorizadas con fetchpriority="high", reducir CSS que bloquea render, evitar lazy-loading en el LCP element, fonts servidas con font-display: swap.
Interaction to Next Paint
INP mide la latencia de la peor interacción del usuario en toda la sesión: clicks, taps, key presses. La métrica reporta cuánto tardó el browser en pintar el siguiente frame después de que el usuario hizo la acción. A diferencia de FID — que solo medía la primera interacción — INP captura toda la experiencia interactiva.
Optimizaciones típicas: dividir tareas largas de JavaScript con scheduler.yield(), usar Web Workers para trabajo pesado, reducir bundles, eliminar event listeners costosos, cuidar third-party scripts (especialmente analytics y ads).
Cumulative Layout Shift
CLS mide cuánto se mueven los elementos en pantalla durante la sesión, sin que el usuario los haya disparado. Es el típico caso de un banner que carga tarde y empuja el texto hacia abajo justo cuando ibas a cliquear un link.
Optimizaciones típicas: setear dimensiones explícitas en imágenes y videos (width y height attributes), reservar espacio para ads y embeds, evitar contenido inyectado above-the-fold, usar font-display: optional con cuidado, no mover elementos con animaciones que afecten layout (preferir transform).
Field data vs lab data — la confusión más cara del sector
Una de las razones por las que muchos proyectos invierten meses en mejorar Web Vitals sin ver impacto en SEO es que miran la métrica equivocada. Hay dos formas de medir CWV:
- Lab data — Lighthouse, PageSpeed Insights (parte simulada), DevTools. Simula la carga en condiciones controladas: red 4G estable, CPU específico, sin third-parties reales en algunos modos. Útil para debugging y para iterar rápido durante development.
- Field data — Chrome User Experience Report (CrUX), Search Console (Core Web Vitals report), PageSpeed Insights (parte de “Discover what your real users are experiencing”). Datos reales de usuarios de Chrome con Usage Statistics activado, agregados al percentil 75. Esto es lo que Google usa para ranking.
El error frecuente: pasar Lighthouse con verde (lab perfecto) pero tener field data en rojo. Pasa todo el tiempo cuando el lab corre sin third-party scripts y el real usuario sí los carga. Lighthouse te dice cómo podría rendir tu site; CrUX te dice cómo está rindiendo.
Cómo se calcula la calificación del site (el percentil 75)
Google no toma el promedio. Toma el percentil 75 de los page views: si el 75% de tus usuarios tuvo LCP < 2.5s, el site califica como “good” en LCP. Si solo el 70% lo cumple, califica como “needs improvement” — incluso si el LCP promedio es bajo.
Eso cambia cómo priorizás. Una página que tiene LCP de 1.5s en el 50% de los usuarios pero 6s en el 30% va a fallar. Mejorar el caso medio no sirve — hay que enfocar en el peor 25%, normalmente: dispositivos lentos, conexiones móviles malas, ubicaciones lejanas del CDN.
Cómo priorizar cuando hay limitaciones
- Empezá por los datos de campo, no por Lighthouse. Mirá Search Console → Core Web Vitals report y PageSpeed Insights con CrUX. Si CrUX dice good y Lighthouse dice needs improvement, no actúes — tu real-user data ya está bien.
- Identificá la métrica que más URLs te penaliza. En Search Console verás qué métrica afecta a más URLs. Empezá por la peor cobertura — el ROI por hora de dev es máximo.
- INP suele ser el más difícil. LCP y CLS se arreglan con técnicas conocidas; INP requiere refactorizar JavaScript, lo que puede ser caro. Calibrá si el problema es código propio o third-parties.
- Mobile primero. Google rankea con mobile-first indexing y CWV mobile suelen ser peores que desktop. Si tenés que elegir, optimizá mobile.
- Distinguí URLs por template, no por URL individual. Si tu site tiene 50.000 URLs de producto, tratalo como un template — un fix sobre el template afecta a todas. La granularidad de URL individual es ineficiente.
- Validá con field data después del fix. CrUX agrega 28 días, así que esperá ese período antes de evaluar si el cambio funcionó. Lighthouse te confirma que el cambio se desplegó; CrUX confirma que mejoró la experiencia real.
Tools recomendadas para medir y debugear
- Search Console — Core Web Vitals report. Source of truth para Google. Te dice qué URLs fallan, en qué métrica, agrupadas por patrón.
- PageSpeed Insights. Field data del CrUX + lab data de Lighthouse en una pantalla. Útil para diagnóstico rápido por URL.
- Chrome DevTools — Performance + Performance Insights. Para debugear casos específicos. Te muestra exactamente qué task bloqueó el INP, qué imagen disparó el LCP, qué shift acumuló al CLS.
- web-vitals JavaScript library. Para medir Web Vitals desde tu propio código y enviarlos a tu analytics. La forma más fina de medir field data sin esperar a CrUX.
- CrUX Dashboard. Vista histórica de Web Vitals de cualquier dominio público. Útil para benchmarking competitivo.
Errores comunes con Core Web Vitals
- Optimizar Lighthouse en vez de CrUX. El error más caro. Subir el score de Lighthouse no mueve la aguja en SEO si CrUX no mejora.
- Ignorar mobile. Web Vitals se evalúan separado en mobile y desktop. Mobile suele ser peor, pesa más en mobile-first indexing.
- Tratar CWV como prioridad #1 cuando no lo es. Google ha sido explícito: contenido de calidad pesa más que CWV. Si tu site tiene problemas de Helpful Content o EEAT, fijar eso primero te trae más tráfico que pulir LCP.
- Optimizar la home y olvidar el resto. Search Console reporta CWV por grupos de URLs. Una home rápida con un blog lento sigue dañando el cluster.
- Confundir INP con FID. FID solo medía la primera interacción. INP mide TODAS. Sites que pasaban FID con folgura pueden estar fallando INP.
- Esperar resultados inmediatos. CrUX agrega 28 días de datos. Los cambios tardan al menos un mes en reflejarse, y el efecto SEO puede tardar más.
- Olvidarse de los third-party scripts. Analytics, chats, ads, tag managers son la causa más frecuente de INP malo. Auditá qué se carga y cuándo.
Cómo se conecta con el resto del SEO
Core Web Vitals son una señal real pero menor dentro de Page Experience, que a su vez es uno de muchos factores que Google evalúa. Tener CWV en verde no compensa contenido pobre; tener CWV en rojo no destruye un site con autoridad temática y EEAT real.
La regla práctica: CWV es un higher-order tiebreaker. Cuando dos URLs compiten por una query con calidad de contenido similar, el site con mejores Web Vitals gana. Si la calidad de contenido es muy distinta, CWV no salva al perdedor. Por eso en proyectos enterprise, CWV no se trata como objetivo aislado — se mete dentro del ciclo continuo de mantenimiento técnico.