¿Qué miden LCP, INP y CLS y por qué importan?

Los Core Web Vitals importan porque traducen una sensación muy humana, “esta web va lenta”, en señales técnicas medibles. Si tu página de servicio tarda en mostrar el titular, el usuario espera; si pulsa un botón y no pasa nada, duda; si el contenido salta al cargar un banner, pierde confianza. Qué haría yo: empezaría separando los problemas por métrica, porque no se arregla igual una imagen pesada que un JavaScript que bloquea la interacción. Esa lectura evita pedir “optimizar PageSpeed” como una tarea genérica y obliga a convertir el diagnóstico en acciones concretas.

Las tres señales en lenguaje claro

LCP, INP y CLS no miden toda la calidad técnica de una web, pero sí tres momentos críticos de la experiencia. LCP responde a “¿cuándo veo lo importante?”, INP a “¿cuándo reacciona la página?” y CLS a “¿por qué se ha movido esto?”. Si tu home tiene una imagen hero enorme, un menú con animaciones pesadas y anuncios o módulos que aparecen tarde, puedes fallar las tres métricas a la vez. Qué haría yo: revisaría primero las plantillas con más tráfico orgánico y más intención comercial, no solo la portada.

LCP: cuándo aparece el contenido principal

El LCP suele estar relacionado con el elemento más grande visible al inicio: una imagen principal, un bloque de texto, un banner o una cabecera. Si tu landing abre con una foto de gran tamaño sin compresión adecuada, el usuario no percibe la página como cargada hasta que ese recurso aparece. Qué haría yo: pediría identificar el elemento LCP de cada plantilla importante y revisar su peso, formato, prioridad de carga y dependencia del servidor. Es una métrica muy conectada con negocio, porque afecta al primer impacto.

INP: cuánto tarda la web en responder

El INP mide la respuesta de la página ante interacciones como clics, toques o escritura en formularios. Sustituyó a FID como Core Web Vital en marzo de 2024, así que cualquier informe actual debe hablar de INP, no de FID como métrica principal. Si el usuario abre un desplegable y la web se queda bloqueada porque hay demasiado JavaScript ejecutándose, el INP puede resentirse. Qué haría yo: revisaría scripts de terceros, etiquetas de medición, plugins y funcionalidades que cargan en todas las páginas sin aportar valor en todas ellas.

CLS: si la página se mueve mientras carga

El CLS mide la estabilidad visual: si el usuario está leyendo o va a pulsar un botón y, de repente, un bloque desplaza el contenido, la experiencia empeora. Suele pasar con imágenes sin dimensiones reservadas, fuentes que cambian el tamaño del texto, banners de cookies, iframes o módulos insertados tarde. Qué haría yo: pediría reservar espacio para los elementos dinámicos y revisar primero móvil, donde cualquier salto visual se nota más. No es solo estética: un desplazamiento inesperado puede provocar clics erróneos y fricción.

¿Cuáles son los valores que Google considera buenos?

Google considera buenos estos umbrales: LCP inferior a 2,5 segundos, INP inferior a 200 milisegundos y CLS inferior a 0,1. No conviene tratarlos como notas aisladas, sino como límites para saber si la experiencia entra en una zona saludable. Si tu web está cerca del umbral, pequeños cambios en servidor, imágenes o scripts pueden hacer que unas URLs pasen y otras suspendan. Qué haría yo: no perseguiría una puntuación perfecta, sino que buscaría que las plantillas importantes cumplan de forma estable en móvil y escritorio.

LCP bueno: menos de 2,5 segundos

Un LCP bueno indica que el contenido principal aparece pronto para la mayoría de usuarios. Si una ficha de producto muestra tarde la imagen principal o el nombre del producto, el visitante puede interpretar que la página no carga, aunque el resto del sitio termine funcionando. Qué haría yo: revisaría imágenes above the fold, caché, respuesta del servidor y recursos CSS que bloquean el renderizado. También contrastaría el dato con negocio: una URL informativa puede tolerar menos presión que una página transaccional clave, pero ambas deben ser legibles rápido.

INP bueno: menos de 200 milisegundos

Un INP bueno significa que la página responde con agilidad cuando el usuario intenta hacer algo. No basta con que cargue; tiene que permitir navegar, filtrar, abrir menús, enviar formularios o cambiar opciones sin bloqueo. Si tu web usa muchos plugins, mapas, chats, etiquetas publicitarias o librerías visuales, el navegador puede quedar ocupado en tareas largas. Qué haría yo: pediría una lista de scripts cargados por plantilla, su función y si son imprescindibles. El objetivo no es eliminarlo todo, sino reducir lo que estorba en momentos críticos.

CLS bueno: menos de 0,1

Un CLS por debajo de 0,1 indica que la página mantiene una estructura visual estable durante la carga. Si un aviso legal, una imagen sin alto definido o una fuente externa desplaza el contenido, el usuario percibe desorden incluso cuando la web es rápida. Qué haría yo: documentaría los saltos visuales con capturas o grabaciones de carga en móvil y pediría reservar espacios fijos para imágenes, anuncios, embeds y banners. Es una mejora que suele ser fácil de explicar, porque cualquier persona puede ver el problema sin leer métricas técnicas.

Cómo saber si tu web aprueba o suspende

Para saber si tu web aprueba no mires solo un número global. PageSpeed Insights te muestra métricas, oportunidades y diagnósticos por URL, pero debes analizar tipos de página: home, categorías, servicios, fichas, artículos y formularios. Si tu blog aprueba y tus páginas comerciales suspenden, el problema no está resuelto. Qué haría yo: crearía una muestra corta con las URLs que más tráfico, leads o ventas generan, y la revisaría junto con Search Console. Si quieres ordenar ese análisis, esta guía sobre Cómo usar Google Search Console para encontrar lo que frena tu SEO puede ayudarte.

Lectura práctica de PageSpeed Insights

PageSpeed Insights combina una prueba de laboratorio con datos de campo cuando existen datos suficientes. Por eso conviene mirar primero si hay información real de usuarios y después revisar las oportunidades técnicas. Si una URL falla LCP, no basta con copiar todas las recomendaciones: hay que localizar el elemento LCP y entender por qué tarda. Qué haría yo: anotaría por cada URL la métrica fallida, el recurso sospechoso, la plantilla afectada y la acción pedida. Ese formato convierte el informe en una lista de trabajo, no en un documento que nadie ejecuta.

Datos de laboratorio vs datos de campo (CrUX)

Los datos de laboratorio son pruebas controladas; los datos de campo reflejan la experiencia real de usuarios, normalmente a través de CrUX cuando hay volumen suficiente. Esta diferencia explica por qué una prueba puede salir distinta cada vez y por qué una URL puede tener buena puntuación en laboratorio, pero malos datos reales en móvil. Qué haría yo: usaría laboratorio para diagnosticar causas y CrUX para validar impacto. Si además quieres ver cómo se comporta Google al rastrear tu sitio, el Análisis de logs: cómo ver qué hace Google en tu web aporta una capa técnica complementaria.

Cómo interpretar discrepancias

Cuando laboratorio y campo no coinciden, no significa que una herramienta esté “mal”. Puede haber diferencias por dispositivo, conexión, ubicación, caché, cookies, scripts de terceros o momento de medición. Si tus usuarios reales navegan sobre todo desde móvil y conexiones medias, una prueba de escritorio no representa bien su experiencia. Qué haría yo: segmentaría el diagnóstico por dispositivo y tipo de plantilla, y evitaría tomar decisiones por una medición aislada. Para conectar rendimiento con impacto comercial, también conviene entender la relación entre Velocidad web: cómo afecta a tus ventas y cómo mejorarla.

Mejoras de alto impacto que puedes priorizar

La prioridad no es hacer todas las recomendaciones posibles, sino atacar lo que más pesa en las páginas importantes. En muchas webs, las mejoras de alto impacto están en imágenes sobredimensionadas, CSS o JavaScript bloqueante, servidor lento, fuentes externas y elementos que aparecen sin espacio reservado. Si tu restaurante, clínica o ecommerce tiene una landing clave, esa URL debe ir antes que una página secundaria. Qué haría yo: ordenaría las acciones por métrica, plantilla afectada, dificultad y riesgo. Así evitas invertir horas en microajustes mientras el problema principal sigue intacto.

Prioriza donde el usuario espera

La parte visible al cargar, conocida como above the fold, suele concentrar los problemas más relevantes. Ahí aparecen el logo, menú, titular, imagen principal, botones, mensajes de confianza y, a veces, pop-ups o banners. Si esa zona depende de muchos recursos externos, la percepción de lentitud aumenta. Qué haría yo: simplificaría la primera pantalla antes de añadir más efectos visuales. En rendimiento web Google, menos elementos críticos suelen significar una experiencia más clara, más rápida y más fácil de mantener para el equipo técnico.

Imágenes y contenido above the fold

Las imágenes son una causa habitual de LCP deficiente, especialmente cuando se suben en tamaños pensados para impresión o escritorio grande. Si tu cabecera usa una imagen de 3000 píxeles y se muestra en móvil, estás haciendo trabajar al navegador más de lo necesario. Qué haría yo: pediría formatos modernos, compresión adecuada, dimensiones coherentes y prioridad de carga para la imagen principal. También revisaría si el diseño necesita realmente un gran recurso visual en la primera pantalla o si puede resolverse con una composición más ligera.

JavaScript e interacción

El exceso de JavaScript puede perjudicar INP porque el navegador está ocupado ejecutando tareas antes de responder al usuario. Suele venir de plugins, personalizadores visuales, chats, mapas, carruseles, herramientas de analítica y etiquetas añadidas con el tiempo. Qué haría yo: pediría cargar scripts solo donde sean necesarios, retrasar lo no crítico y eliminar funcionalidades duplicadas. Si la web está en una fase de rediseño o cambio de CMS, conviene planificarlo con cuidado; aquí encaja revisar cómo Cómo migrar una web sin perder posiciones en Google.

Estabilidad visual y fuentes

La estabilidad visual suele mejorar cuando imágenes, vídeos, iframes y módulos dinámicos tienen dimensiones reservadas antes de cargar. Las fuentes también influyen: si el navegador muestra un texto provisional y luego lo sustituye por otra tipografía con medidas diferentes, puede producirse desplazamiento. Qué haría yo: revisaría fuentes críticas, preload cuando proceda y estilos que eviten saltos bruscos. También comprobaría banners de cookies, avisos superiores y bloques promocionales, porque muchas veces no se consideran “rendimiento”, pero son los responsables de un CLS alto en móvil.

Qué pedirle exactamente a tu desarrollador

La mejor petición no es “haz que PageSpeed salga en verde”, sino una lista verificable por métrica y plantilla. Pide identificar el elemento LCP, reducir recursos bloqueantes, optimizar imágenes críticas, revisar scripts de terceros, mejorar caché, comprobar servidor, reservar espacios para elementos dinámicos y medir después con la misma metodología. Qué haría yo: trabajaría con tickets pequeños, cada uno con URL, problema, acción y criterio de validación. Si necesitas apoyo externo, una agencia especializada en SEO debería ayudarte a traducir el diagnóstico técnico en prioridades entendibles para negocio y desarrollo.

Peticiones concretas para convertir el informe en tareas

Un caso tipo de trabajo sería auditar tres plantillas: una página de servicio, una ficha o categoría y un artículo. Para cada una, se revisa la métrica fallida, el recurso afectado, el origen del problema y la acción recomendada. No hace falta inventar resultados ni prometer mejoras automáticas; lo importante es que cada cambio pueda comprobarse antes y después con PageSpeed Insights, CrUX cuando aplique y revisión manual en móvil. Qué haría yo: documentaría capturas, fecha, URL y decisión tomada, porque la trazabilidad evita repetir el mismo problema en futuras publicaciones.