¿Cómo aprobar los Core Web Vitals? La guía de arreglos 2026 para LCP, INP y CLS

Empieza por diagnosticar la métrica correcta

La razón más común por la que los equipos malgastan esfuerzo es arreglar lo que no toca, así que el primer paso no es un cambio de código — es medir. Google posiciona con datos de campo de visitantes reales del Chrome User Experience Report, no con una prueba de laboratorio, y ambos suelen discrepar por un margen amplio; una puntuación verde de Lighthouse en tu laptop casi no dice nada sobre un móvil de gama media con 4G (That’s It Tools, 2026). Empieza en el informe de Core Web Vitals de Google Search Console, halla la métrica que falla en el percentil 75, y arranca por ahí (W3era, 2026).

Para diagnosticar a nivel de página, la herramienta práctica es la librería de JavaScript de código abierto web-vitals, que reporta LCP, INP y CLS desde tus usuarios reales e incluso te dice qué elemento fue el LCP (DEV / Riemer, 2026). Envía esas lecturas a tu analítica, segmentadas por ruta y dispositivo, porque un único número agregado esconde la página o el teléfono donde de verdad vive el problema. La regla que más tiempo ahorra: no trabajes el LCP porque te resulta satisfactorio mientras el INP se hunde en silencio — arregla la métrica que falla.

¿Cómo se arregla el LCP?

El LCP casi siempre es por un recurso específico, así que el arreglo es puntual y no general. El error que cometen los equipos es “optimizamos las imágenes” — cuando la respuesta es la imagen, el elemento más grande sobre la línea de flotación (DEV / Riemer, 2026). Identifícala, y dale prioridad: sírvela como AVIF o WebP comprimida a un tamaño sensato, ponle fetchpriority="high", nunca la cargues en diferido, y precárgala — pero precarga solo a ella, porque precargar todo crea su propia contención (Technova, 2026).

La otra mitad del LCP es el servidor y la ruta de render. Reduce el tiempo hasta el primer byte por debajo de unos 600 milisegundos con caché y una CDN, y elimina el CSS y el JavaScript que bloquean el render y retrasan el primer pintado (Digital Pilots, 2026). Las ganancias más rápidas con el menor trabajo, en orden, suelen ser: comprimir la imagen principal, quitar los scripts pesados de terceros, desplegar una CDN con caché, y reducir el paquete de JavaScript (DEV / Dharanidharan, 2026). Un servidor lento anula cualquier optimización de front-end, así que conviene revisarlo primero.

¿Cómo se arregla el CLS?

El CLS es el más arreglable de los tres, porque viene casi por completo de una sola causa: elementos que cargan sin espacio reservado. Dale a cada imagen, video, iframe y bloque de anuncio atributos explícitos de width y height o un aspect-ratio en CSS, para que el navegador retenga el espacio antes de que llegue el recurso (Digital Pilots, 2026). Para cualquier cosa que se inyecte de forma dinámica —anuncios, incrustaciones, un chat— reserva una altura mínima en su contenedor, para que un espacio vacío sea el peor caso y no un salto que empuja el contenido mientras el usuario lee (DEV / Riemer, 2026).

Las fuentes son la otra fuente clásica. Usa font-display: swap y precarga tus fuentes clave, y ajusta las métricas de la fuente de respaldo para que el cambio de la fuente del sistema a la web no reflujo el texto — una técnica que muchos equipos nunca han oído y que puede bajar el CLS de 0,15 a 0,02 (DEV / Riemer, 2026). Como los arreglos son tan mecánicos, el CLS tiene la tasa de aprobación más alta de los tres — lo que significa que fallarlo suele ser señal de fundamentos ausentes y no de un problema difícil.

¿Cómo se arregla el INP, el difícil?

El INP no se retoca; hay que rearquitecturarlo, que es por lo que cerca del 43% de los sitios lo falla y es el vital que más se falla en 2026 (Digital Applied, 2026). El mecanismo es simple de enunciar y difícil de arreglar: cualquier tarea de JavaScript que corre más de 50 milisegundos bloquea el hilo principal, y mientras corre el navegador no puede responder a un toque, clic o tecla (ToolsPivot, 2026). Un consultor describió a un cliente cuyos filtros de e-commerce tenían un INP de 600 ms porque cada clic disparaba un re-render completo — el tipo de problema que la vieja métrica First Input Delay nunca captaba (That’s It Tools, 2026).

Los arreglos apuntan todos en la misma dirección: menos JavaScript, y más tarde. Reduce el paquete total y divídelo para que el código cargue bajo demanda; difiere los scripts no críticos; mueve el cómputo pesado a un web worker; y cede el hilo principal durante las interacciones para que un manejador de eventos haga casi nada de forma síncrona (Digital Applied, 2026). El patrón a interiorizar: cualquier cosa cara —filtrar, ordenar, registrar, computar— se cede, se difiere o se descarga, para que la interacción pinte primero y el trabajo ocurra después (DEV / Riemer, 2026). Audita los scripts de terceros con el mayor rigor, porque la analítica, el chat y las herramientas de consentimiento son un culpable frecuente del INP que tú no escribiste.

¿Qué páginas fallan qué métrica?

Los fallos se agrupan por tipo de página, lo que te deja priorizar en vez de auditar todo a la vez. Los blogs y las páginas de inicio fallan sobre todo el LCP, porque una imagen principal grande es el elemento más lento en cargar. Las páginas de producto y de categoría tienden a fallar el CLS, porque los precios, las etiquetas de stock y las recomendaciones se inyectan tras el primer pintado y desplazan el diseño. Y los fallos de INP se concentran en las páginas más interactivas —pagos, páginas de aterrizaje con formularios, y listados con muchos filtros— donde un JavaScript pesado corre en cada toque (W3era, 2026).

Conocer el patrón te dice por dónde mirar primero. Si tus páginas que convierten son de producto o categoría, empieza por el CLS y reserva espacio para los elementos dinámicos; si son de contenido, empieza por la imagen principal y el LCP; si son pagos o flujos tipo aplicación, el trabajo es el INP y tomará más tiempo. Como la evaluación de 2026 es de todo el sitio, arreglar la plantilla detrás de cada tipo de página levanta a todas las páginas de ese tipo a la vez — el lugar donde el esfuerzo más rinde.

Qué cambió en 2026: ahora es de todo el sitio

El mayor giro estratégico no es una métrica nueva sino un alcance más amplio. El core update de Google de marzo de 2026 movió los Core Web Vitals de una evaluación por página a un modelo de todo el sitio (ToolsPivot, 2026). La analogía que encaja: antes era una evaluación de desempeño por empleado, y ahora un empleado lento arrastra la puntuación de todo el equipo.

En la práctica esto mata el viejo atajo de optimizar tus 20 mejores páginas de aterrizaje e ignorar el resto. Si una porción grande de tus páginas —digamos el 40%— falla el LCP, eso puede hundir el posicionamiento incluso de las páginas que aprueban las tres métricas por sí solas (ToolsPivot, 2026). El rendimiento ahora es una propiedad de todo el sitio, lo que favorece con fuerza un enfoque a nivel de plantilla: arregla el layout compartido, los scripts globales y la librería de componentes una vez, y cada página construida sobre ellos mejora junta.

¿Qué herramientas necesitas de verdad?

Un stack pequeño y gratuito cubre todo el trabajo. Google Search Console muestra qué grupos de URL fallan en el percentil 75 en datos de campo — tu fuente de verdad sobre qué arreglar. PageSpeed Insights combina esos datos de campo con una corrida de laboratorio de Lighthouse para una URL, útil para una lectura rápida. Para un diagnóstico más profundo, Chrome DevTools en la pestaña Performance graba una interacción real y marca los eventos de LCP, CLS e INP en la línea de tiempo, así ves exactamente qué elemento o qué tarea causó el problema (That’s It Tools, 2026). Y la librería web-vitals, corriendo en producción, te da números continuos de usuarios reales segmentados por ruta y dispositivo.

La disciplina que importa más que cualquier herramienta: usa el laboratorio como diagnóstico y el campo como marcador. Lighthouse existe para encontrar problemas, no para celebrar — el número que afecta el posicionamiento vive en CrUX, y la brecha entre ambos puede ser de un orden de magnitud (DEV / Riemer, 2026).

¿Cuánto tardan en verse los arreglos?

No al instante, y saberlo evita mucha duda. Las herramientas de laboratorio como Lighthouse reflejan un cambio en el momento en que lo despliegas, pero los datos de campo con los que Google posiciona vienen del Chrome UX Report en una ventana móvil de 28 días, así que un arreglo real puede tardar hasta un mes en aparecer en Search Console (That’s It Tools, 2026). El flujo es, entonces: implementar, verificar en staging, desplegar, y luego esperar a que los datos de campo se pongan al día — no refrescar PageSpeed Insights una hora después esperando un número nuevo.

Un buen hábito de alerta temprana es poner avisos por debajo de los umbrales oficiales —por ejemplo INP sobre 160 ms, LCP sobre 2,0 s, CLS sobre 0,08— para que una regresión tras un despliegue te llegue antes de esparcirse por tu ventana de 28 días y afectar el posicionamiento (Digital Applied, 2026). Vigilas un indicador que se mueve despacio, así que quieres el aviso temprano.

¿Cómo evitas que vuelva a empeorar?

Tratas el rendimiento como una función del producto con un responsable, no como un proyecto que terminas. Los equipos que sostienen sus puntuaciones son los que tienen a alguien a cargo de las métricas, las revisan cada semana, tratan las regresiones como errores y no como pendientes, y hacen de aprobarlas parte de la definición de “terminado” (DEV / Riemer, 2026). Los que fracasan son los que tratan los vitals como algo que atender después del próximo lanzamiento — y cada imagen, script y función nueva erosiona la puntuación en el camino.

El mecanismo es una monitorización que no tienes que recordar. Corre Lighthouse en integración continua en cada despliegue importante como diagnóstico, y mantén la monitorización de usuarios reales con la librería web-vitals en producción como marcador (DEV / Dharanidharan, 2026). Como la evaluación ahora es de todo el sitio, cazar una regresión a nivel de plantilla —antes de que llegue a cada página— vale mucho más que arreglar páginas de a una después.

El atajo: construir liviano para aprobar por defecto

Relee los arreglos y aparece un patrón: casi todos son versiones de “envía menos JavaScript y deja que el navegador renderice HTML”. Comprimir y precargar una imagen, reservar espacio con atributos simples, y mover el trabajo fuera del hilo principal — ese es el estado natural de un sitio construido liviano en vez de remendado. Una arquitectura estática y con poco JavaScript aprueba la mayoría de los Core Web Vitals por construcción, por lo que los sitios más rápidos rara vez parecen “optimizados para velocidad”. Solo están bien hechos, un punto que desarrollamos en nuestra guía sobre si Astro es bueno para el SEO y el rendimiento.

Esa es la diferencia entre perseguir las métricas y nunca tener que hacerlo. Un sitio pesado se pasa la vida recuperando milisegundos que la arquitectura sigue añadiendo; uno liviano arranca con el presupuesto intacto y gasta su esfuerzo en mantener bueno algo bueno. El caso completo de por qué esta puntuación es la prueba de que el resto de tu sitio es sólido —legible, accesible, duradero— está en nuestro pilar sobre Core Web Vitals y velocidad web. Aprobar es bueno; construir para que aprobar nunca estuviera en duda es mejor.