Core Web Vitals e INP: qué arreglar primero en la web de tu negocio

Los Core Web Vitals miden carga, interactividad y estabilidad visual, y cada uno tiene un umbral de «bueno» publicado por Google en web.dev. Una página los supera cuando cumple los tres en el percentil 75 de sus visitas reales, calculado por separado para móvil y ordenador.

Ese percentil 75 significa que tres de cada cuatro visitas deben tener una experiencia buena. No basta con que tu web vaya rápida en tu ordenador de la oficina: cuenta lo que vive un cliente con un móvil de gama media y una cobertura irregular.

• [LCP](term:lcp) (Largest Contentful Paint): tiempo hasta que se muestra el elemento principal, como la imagen de cabecera o el titular. Bueno: 2,5 segundos o menos.
• [INP](term:inp) (Interaction to Next Paint): latencia de las interacciones con clics, toques y teclado. Bueno: 200 milisegundos o menos; entre 200 y 500 necesita mejorar; por encima de 500 es malo.
• [CLS](term:cls) (Cumulative Layout Shift): cuánto se desplaza el contenido de forma inesperada. Bueno: 0,1 o menos.

INP pasó a ser un Core Web Vital estable en 2024 y reemplazó a FID, una métrica que solo observaba la primera interacción. INP mira las interacciones a lo largo de toda la visita y, según la documentación de web.dev, su valor final es la interacción más lenta observada, sin contar los casos atípicos.

Para un negocio, esto cambia el diagnóstico: una web puede cargar bien y aun así sentirse torpe cuando el visitante abre un menú, filtra un catálogo o pulsa «reservar». Pasar el desplazamiento, el zoom o el hover no cuenta; sí cuentan el clic, el toque y el teclado.

web.dev divide la latencia de una interacción en tres partes: el retraso de entrada (la página está ocupada con tareas largas), el tiempo que tardan en ejecutarse los manejadores del evento y el retraso de presentación (el navegador tarda en pintar el siguiente fotograma). Saber en cuál de las tres se pierde el tiempo orienta la solución.

Empieza por los datos de campo, que son los de visitantes reales, y deja las pruebas de laboratorio para reproducir lo que ya has detectado. Los datos de campo te dicen si hay un problema; el laboratorio ayuda a encontrar la causa.

Tienes tres puntos de partida sin coste: el informe de Core Web Vitals de Search Console, que agrupa tus URL según su rendimiento; PageSpeed Insights, que muestra datos del informe de experiencia de usuario de Chrome (CrUX) cuando hay visitas suficientes; y la librería web-vitals de JavaScript, que permite registrar INP en tu propia web. Según web.dev, los datos de campo con contexto son la mejor fuente para localizar la interacción lenta concreta.

Un aviso sobre el laboratorio: depende de qué interacciones pruebes, y algunas herramientas no informan de INP. El Total Blocking Time sirve como indicio aproximado, pero no lo sustituye.

Un LCP lento casi siempre se explica por la respuesta del servidor o por la imagen principal. La guía de web.dev reparte el tiempo ideal en cuatro partes: aproximadamente un 40 % para la respuesta del servidor, un 40 % para descargar el recurso principal y menos de un 10 % para cada uno de los dos retrasos restantes.

En la práctica, las correcciones con más retorno son estas, todas recogidas en esa guía:

• Reducir redirecciones y servir el HTML desde caché o desde una red de distribución de contenidos (CDN).
• Hacer que la imagen principal esté en el HTML inicial y no solo en el CSS o en JavaScript; si no es posible, precargarla.
• Dar prioridad alta (`fetchpriority="high"`) a una o dos imágenes que sean candidatas a LCP, y bajársela a las que no se ven, como las diapositivas ocultas de un carrusel.
• No aplicar carga diferida (lazy loading) a la imagen principal: añade espera sin necesidad.

CLS suele arreglarse reservando espacio, e INP suele arreglarse reduciendo el trabajo que bloquea el hilo principal. Ninguna de las dos exige rediseñar la web, aunque sí un buen criterio técnico.

Para CLS, web.dev señala como causas habituales las imágenes sin dimensiones, los anuncios, incrustaciones y marcos sin espacio reservado, y las fuentes web. Las soluciones: indicar ancho y alto (o `aspect-ratio`) en imágenes y vídeos, reservar un mínimo de altura para banners, formularios y contenidos que se cargan tarde, animar con `transform` en lugar de con `top` o `left`, y precargar las fuentes críticas con una fuente de reserva parecida.

Para INP no hay una receta única, porque depende de qué interacción es lenta. La pista que da web.dev es repartir el problema en sus tres partes. Si el retraso de entrada es alto, hay tareas largas ocupando la página; es frecuente que lo provoquen scripts de terceros, como chats, etiquetas de medición o ventanas emergentes, aunque conviene confirmarlo con datos de tu web y no suponerlo. Si el problema es el manejador, el código de ese botón o filtro hace demasiado. Si es la presentación, la página pinta demasiado tras la acción.

Google recomienda buenos Core Web Vitals, pero su documentación no les asigna un peso concreto en el posicionamiento: los describe como parte de una experiencia de página que encaja con lo que buscan recompensar sus sistemas de ranking. Tómalos como un requisito de calidad para quien visita tu web, no como una palanca mágica para subir puestos. Un contenido útil y relevante sigue pesando más que un milisegundo.

Nuestra recomendación para una web de empresa, en este orden:

• Revisa Search Console y PageSpeed Insights y anota qué métrica suspende en móvil.
• Elige las páginas que más visitas o consultas generan (inicio, servicios, reserva o contacto) y empieza por ellas.
• Corrige primero lo que suspende: LCP si carga lenta, CLS si el contenido salta, INP si se siente torpe.
• Cambia una cosa cada vez y vuelve a medir, para saber qué ha funcionado.
• Vigila cada vez que añadas un plugin, un chat o una etiqueta: es cuando suelen empeorar las métricas.

Si no tienes a nadie que pueda leer un informe de rendimiento, empieza por pedir un diagnóstico que priorice. Nuestro servicio de SEO técnico revisa qué métrica suspende y en qué páginas, y el de desarrollo web aplica las correcciones en el código.

Cuando la mejora técnica va unida a más consultas o reservas, conviene mirarla junto con la optimización de la conversión. Y si tu web también depende de scripts de medición, repasa antes Consent Mode v2, porque etiquetas y banner forman parte de lo que carga tu página. Si quieres que miremos tu caso, escríbenos.