Core Web Vitals: qué arreglar primero en una web de negocio
Arregla el LCP primero. Es donde fallan las webs de negocio, sus causas arrastran a las otras dos métricas y es lo más barato de reparar. El orden y el porqué.
TL;DR
En una web de negocio, arregla primero el Largest Contentful Paint. Es la métrica que estas webs suspenden de verdad, y sus tres causas habituales, que son imágenes de cabecera sin optimizar, recursos que bloquean el renderizado y un servidor lento en responder, tienden a arrastrar consigo a las otras dos. Arregla el LCP y muchas veces encuentras el Cumulative Layout Shift y el Interaction to Next Paint mejorados sin tocarlos. El CLS va segundo, porque casi siempre es el mismo fallo: imágenes, anuncios o incrustaciones que entran sin espacio reservado, más tipografías que cambian tarde. El INP va último, porque la mayoría de webs de negocio lo aprueban, y cuando fallan suele ser un script de terceros y no tu código. Mide con datos de campo de Search Console y no con una puntuación de Lighthouse, porque los de campo son los que usa Google.
Las tres métricas, en corto
No hace falta repetirte la documentación. Hace falta lo justo para poder actuar.
Largest Contentful Paint (LCP) mide cuánto tarda en terminar de pintarse el elemento visible más grande, normalmente una imagen de cabecera o un titular. Bueno es por debajo de 2,5 segundos. Cumulative Layout Shift (CLS) mide cuánto salta la página mientras carga. Bueno es por debajo de 0,1. Interaction to Next Paint (INP) mide cuánto tarda la página en responder visiblemente después de un toque o un clic. Bueno es por debajo de 200 milisegundos.
Un detalle pesa más que las definiciones: los tres umbrales se miden en el percentil 75 de las visitas reales, no en la media. Tienen que aprobar tres de cada cuatro visitas. Una media que se ve bien puede suspender igual.
Arregla el LCP primero
El LCP es donde fallan las webs de negocio, y es lo más barato de reparar de los tres.
Hay tres causas habituales y cada una deja una huella distinta. Las imágenes sin optimizar aparecen como un elemento LCP grande con un peso de transferencia enorme en el informe. Los recursos que bloquean el renderizado aparecen como un hueco largo entre que la página responde y que se pinta algo, normalmente hojas de estilo o scripts en el head. Un servidor lento aparece como un tiempo alto hasta el primer byte, antes de que nada más haya empezado siquiera.
El motivo para empezar aquí no es solo que sea lo más frecuente. Es que esas causas son compartidas. Una imagen de cabecera pesada empeora el LCP y después provoca un salto de diseño cuando por fin aterriza. Un script bloqueante retrasa el pintado y añade trabajo al hilo principal, que es lo que castiga la interacción. Arregla bien el LCP y las otras dos métricas suelen mejorar sin que las toques.
Nuestra peor página pesaba 3,5 MB
En junio de 2026 hicimos una auditoría técnica de este mismo sitio. El hallazgo que importaba no estaba en la portada, que era la que vigilábamos. Estaba en /about.
Tres fotos del equipo se servían como PNG sin optimizar de aproximadamente 1,2 MB cada una, unos 3,5 MB en total, mostradas a 380 por 475 píxeles. Estimamos esa página entre 40 y 55 de rendimiento frente a unos 70 a 80 de la portada. Eran estimaciones sacadas de leer el código, no corridas de Lighthouse medidas, y la auditoría lo decía de forma explícita, porque un número que no puedes reproducir no es evidencia.
La corrección fue migrar esas imágenes al pipeline de assets de Astro, que genera WebP y AVIF en varias densidades al compilar, y arreglar los atributos de carga para que la imagen del LCP no vaya en diferido. Una sola causa raíz, cinco hallazgos cerrados. La lección se generaliza: en webs de negocio, la mayor ganancia de rendimiento casi siempre son imágenes que nadie optimizó porque la página se veía bien en el portátil del diseñador.
El CLS va segundo, y casi siempre es el mismo fallo
El Cumulative Layout Shift tiene fama de misterioso. En la práctica, en una web de negocio, son una de dos cosas.
Elementos que entran sin espacio reservado. Una imagen sin ancho y alto, un hueco de anuncio, un vídeo incrustado, un aviso de cookies. El navegador coloca la página, llega el elemento y todo lo de debajo salta. Se arregla reservando el espacio de antemano con dimensiones explícitas o una proporción.
Tipografías que cambian tarde. El texto se pinta con una fuente de respaldo, después llega la real con otras métricas y el texto se recoloca. Precargar la fuente que usa tu elemento LCP quita el cambio visible, y suele ser un cambio de dos líneas.
El INP va último, y muchas veces no es tu código
La mayoría de webs de negocio aprueban el INP sin hacer nada, porque la mayoría de webs de negocio no son aplicaciones. No hay demasiado con lo que interactuar.
Cuando una falla, la causa suele ser un script de terceros y no tu propio JavaScript: un chat, un gestor de etiquetas cargando media docena de etiquetas, un grabador de sesiones, un píxel de marketing. Cada uno corre en el mismo hilo principal que tiene que responder al toque de tu visita.
Vale la pena decirlo claro porque los fallos de INP disparan a menudo una reescritura de código de aplicación que nunca fue el problema. Mira qué terceros cargas antes de refactorizar nada.
Los datos de campo y los de laboratorio discrepan a propósito
Esta es la confusión que más tiempo hace perder, así que conviene ser preciso.
| Lighthouse (laboratorio) | Search Console (campo) | |
|---|---|---|
| Qué mide | Una carga simulada con la conexión limitada | Visitas reales, dispositivos reales, ventana móvil de 28 días |
| De dónde sale | Tu equipo, ahora mismo | Chrome User Experience Report |
| Para qué sirve mejor | Depurar una corrección concreta | Saber si de verdad apruebas |
| Se usa para posicionar | No | Sí |
Un Lighthouse en verde con un Search Console en rojo no es una contradicción. Suele significar que tus visitas usan dispositivos o redes más lentas que tu equipo de pruebas, o que una plantilla que tú casi nunca abres está tirando del agregado. Usa Lighthouse para depurar un cambio y los datos de campo para decidir si tienes un problema.
Dónde se cruza esto con la búsqueda con IA
El rendimiento no es un proyecto aparte de que te citen los asistentes de IA.
Los rastreadores trabajan con presupuestos de tiempo y recursos. Una página lenta en responder se descarga menos veces y de forma menos completa, y una página cuyo contenido solo aparece después del JavaScript puede no leerse, porque la mayoría de rastreadores de IA no renderizan. Si quieres comprobar justo ese fallo, escribimos el paso a paso de las cuatro comprobaciones que deciden si ChatGPT puede leer tu web.
Ese es el argumento para tratar la capa de construcción y la búsqueda como una sola disciplina y no como dos presupuestos. Las mismas correcciones sirven a las dos.
Cómo mantenerlo arreglado
Una optimización de una sola vez se degrada. Alguien mete un vídeo de cabecera, se instala una herramienta de marketing, sube una imagen a resolución completa porque el gestor la aceptó.
La versión duradera es un presupuesto que se aplique automáticamente antes de publicar, para que una regresión rompa la compilación en vez de aparecer en Search Console un mes después. Es lo que hacemos en cada proyecto web, y es la razón de que la regresión de este mismo sitio saliera en una auditoría que nos hicimos a nosotros y no en la queja de un cliente.
Si quieres saber cómo está tu web ahora mismo, empieza por los datos de campo de Search Console y no por una corrida de Lighthouse. Es el número que Google está usando de verdad.
Preguntas frecuentes
-
¿Qué Core Web Vital conviene arreglar primero?
El LCP, en casi todos los casos. Largest Contentful Paint es donde fallan de verdad las webs de negocio, sus causas son las más baratas de reparar y esas mismas causas suelen arrastrar a las otras dos métricas. Una imagen de cabecera sin optimizar empeora el LCP y encima provoca un salto de diseño cuando termina de llegar; un script que bloquea el renderizado retrasa el pintado y añade trabajo al hilo principal, que es lo que castiga la interacción. Arregla el LCP y muchas veces encuentras el CLS y el INP mejorados sin haberlos tocado.
-
¿Los Core Web Vitals afectan de verdad al posicionamiento?
Sí, pero como desempate, no como palanca. Google ha sido consistente en que la experiencia de página cuenta cuando el resto de señales son comparables, y no va a subir una página que no merece posicionar por relevancia. El efecto grande suele ser indirecto: una página lenta pierde visitas antes de que cargue el contenido, y eso daña todas las métricas que al negocio sí le importan. Piénsalo como quitarte un lastre, no como comprar una ventaja, y el esfuerzo se justifica solo.
-
¿Por qué mi puntuación de Lighthouse es buena y Search Console dice que voy lento?
Porque miden cosas distintas. Lighthouse son datos de laboratorio: una carga simulada, con la conexión limitada, desde tu equipo. Search Console informa con datos de campo del Chrome User Experience Report, que son visitas reales en dispositivos y redes reales durante una ventana de 28 días. Google usa los datos de campo para posicionar. Una puntuación verde de Lighthouse con un informe de Search Console en rojo suele significar que tus visitas usan dispositivos o redes más lentas que tu prueba, o que una plantilla que tú casi nunca abres está tirando del agregado hacia abajo.
-
¿Qué es un buen LCP?
Por debajo de 2,5 segundos es bueno, entre 2,5 y 4 necesita mejorar, y por encima de 4 es malo. El detalle que pilla a los equipos es que el umbral se mide en el percentil 75 de las visitas reales, no en la media. O sea que tres cuartas partes de tus visitas tienen que bajar de 2,5 segundos para que la página apruebe. Una media de 2,4 segundos puede suspender igual si el cuarto lento va suficientemente lento, y por eso las medias son el cristal equivocado para esta métrica.
-
¿Importan los Core Web Vitals para la búsqueda con IA?
De forma indirecta, y más de lo que se supone. Los rastreadores de IA trabajan con presupuestos de tiempo y recursos, como cualquier rastreador. Una página que tarda en responder se descarga menos veces y de forma menos completa, y una página cuyo contenido solo aparece después de que corra el JavaScript puede no leerse en absoluto. Así que el trabajo de rendimiento no es un proyecto aparte de la visibilidad en IA. Las mismas correcciones que mejoran el LCP, sobre todo el tiempo de respuesta del servidor y reducir el renderizado en el navegador, dejan tu contenido disponible para los rastreadores que deciden si te citan.
¿Quieres el playbook antes que tu competencia?
Documentamos cada técnica que aplicamos con clientes. Posts nuevos sobre GEO, AEO y velocidad web cada mes, sin paja, solo método.