Cómo Aprobar Core Web Vitals con Next.js (2026)

Menos de la mitad de la web móvil supera el umbral de rendimiento de Google. En 2025, solo el 48% de los orígenes móviles cumplieron con los tres Core Web Vitals, frente al 36% de dos años antes (HTTP Archive Web Almanac, 2025). Esa brecha es una oportunidad. Si tus competidores son lentos, un sitio Next.js rápido gana tanto en el ranking como en la conversión. El framework te proporciona la mayoría de las herramientas, pero una compilación predeterminada aún falla en muchas auditorías. Esta guía muestra exactamente cómo cerramos esa brecha.

Puntos clave

• Una página pasa cuando LCP es de 2.5s o menos, INP es de 200ms o menos, y CLS es de 0.1 o menos, medido en el percentil 75 de usuarios reales (web.dev, 2025).
• Solo el 48% de los orígenes móviles pasaron los tres vitales en 2025, y LCP es el eslabón más débil con un 62% (Web Almanac, 2025).
• La velocidad es dinero: un sitio de comercio electrónico que carga en 1 segundo convierte aproximadamente 2.5 veces mejor que uno que carga en 4 segundos (Portent, 2022).
• Next.js destaca en las soluciones que más importan: los componentes Image y Font, los Server Components y la carga diferida con dynamic().

¿Qué son los Core Web Vitals en 2026?

Los Core Web Vitals son tres métricas que Google utiliza para calificar la experiencia de página en el mundo real: carga, interactividad y estabilidad visual. Una URL pasa solo cuando las tres se encuentran en la banda "buena" en el percentil 75 de las vistas de página (web.dev, 2025). Una métrica lenta hace que toda la página falle, por lo que no puedes compensar una excelente puntuación de diseño con una carga lenta.

El cambio más grande es la interactividad. Interaction to Next Paint (INP) reemplazó a First Input Delay el 12 de marzo de 2024 (web.dev, 2024). FID solo medía el retraso antes de que se registrara tu primer toque. INP mide la latencia completa de cada interacción durante la visita y luego informa la peor. Es una prueba mucho más difícil, y el JavaScript pesado del lado del cliente es lo que suele romperla.

Aquí están los objetivos a los que apuntas. Cualquier cosa en la banda media es una advertencia, y la banda deficiente es un fallo.

Los umbrales de 2026

• LCP (carga): bueno es 2.5s o menos, necesita trabajo es de 2.5 a 4.0s, deficiente es más de 4.0s.
• INP (interactividad): bueno es 200ms o menos, necesita trabajo es de 200 a 500ms, deficiente es más de 500ms.
• CLS (estabilidad visual): bueno es 0.1 o menos, necesita trabajo es de 0.1 a 0.25, deficiente es más de 0.25.

¿Por qué son importantes los Core Web Vitals para el SEO y los ingresos?

Importan porque las páginas lentas pierden dinero y posiciones en el ranking al mismo tiempo. Portent midió 5.6 millones de sesiones y encontró que la conversión B2C caía del 3.05% con una carga de 1 segundo al 0.67% con 4 segundos, una disminución de aproximadamente 0.3 puntos por segundo añadido (Portent, 2022). En el lado del SEO, Google confirma que unos buenos Core Web Vitals "se alinean con lo que nuestros sistemas de clasificación principales buscan recompensar" (Google Search Central, 2025).

El efecto en los ingresos se agrava. En el estudio de Google y Deloitte de 37 marcas y 30 millones de sesiones, una única mejora de 0.1 segundos en la velocidad móvil aumentó las conversiones minoristas en un 8.4% y el valor promedio de los pedidos en un 9.2% (web.dev, 2020). Una décima de segundo suena trivial hasta que la multiplicas por un cuarto del tráfico.

Para una mirada más profunda sobre cómo esto se relaciona con la búsqueda, nuestra guía de SEO técnico para desarrolladores cubre el lado de la indexación y el renderizado. La velocidad es un pilar de un sistema más grande.

¿Cuántos sitios realmente pasan los Core Web Vitals?

La mayoría no lo hace, y el móvil es donde tienen dificultades. El Web Almanac de 2025 situó la tasa de aprobación general en el 48% en móvil y el 56% en escritorio, siendo LCP la métrica más difícil con un 62% de bueno en móvil frente al 77% para INP y el 81% para CLS (Web Almanac, 2025). El INP de escritorio está casi resuelto con un 97%, pero los teléfonos con CPU lentas y redes irregulares cuentan una historia diferente.

La conclusión es estratégica. Si LCP falla con mayor frecuencia, tu primera hora de optimización debe dedicarse a la imagen principal y las fuentes, no a microajustar un controlador de botón. Soluciona primero el problema más evidente.

¿Cómo solucionamos LCP en Next.js?

LCP falla cuando el elemento más grande, generalmente una imagen principal o un titular, tarda demasiado en renderizarse. Dado que solo el 62% de los sitios móviles lo pasan, aquí es donde se obtienen las mayores victorias (Web Almanac, 2025). El componente Image de Next.js es la solución más importante: sirve formatos modernos, genera tamaños responsivos y te permite marcar la imagen principal para que cargue primero.

Establece priority en la única imagen que está por encima del pliegue. Eso le dice a Next.js que la precargue en lugar de cargarla de forma diferida, lo que en una imagen principal es la diferencia entre pasar y fallar.

import Image from 'next/image';

export function Hero() {
  return (
    <Image
      src="/hero.webp"
      alt="Product dashboard"
      width={1200}
      height={630}
      priority
      sizes="(max-width: 768px) 100vw, 1200px"
    />
  );
}

Las fuentes son la segunda trampa de LCP. Una fuente web de carga tardía bloquea la pintura del texto y puede desplazar el titular. next/font autoaloja el archivo en tiempo de compilación, elimina la solicitud de red a Google y aplica font-display: swap por ti.

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'], display: 'swap' });

export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

Finalmente, renderiza el contenido por encima del pliegue en el servidor. Los Server Components envían HTML que el navegador puede pintar inmediatamente, sin esperar a la hidratación. Mantén la imagen principal, el titular y el texto principal como salida renderizada por el servidor, y empuja la interactividad a los bordes. En nuestras compilaciones, mover una imagen principal fuera de un componente de cliente y añadir priority reduce rutinariamente el LCP móvil a menos de 2.5s por sí solo.

¿Cómo solucionamos INP en Next.js?

INP falla cuando JavaScript bloquea el hilo principal mientras un usuario intenta interactuar. La solución es sencilla de decir y más difícil de hacer: enviar menos JavaScript. Cada componente que mantienes en el servidor es código que el navegador nunca tiene que analizar, y eso mejora directamente la latencia de interacción (web.dev, 2024).

Carga de forma diferida cualquier elemento pesado que no sea necesario para la primera pintura. Un widget de chat, un carrusel, un mapa o un editor enriquecido deben cargarse bajo demanda con dynamic(), no en el paquete inicial.

import dynamic from 'next/dynamic';

const CommentEditor = dynamic(() => import('./CommentEditor'), {
  ssr: false,
  loading: () => <div className="editor-skeleton" />,
});

Para actualizaciones de estado costosas, dile a React que no son urgentes. Envolver una actualización de filtro o búsqueda en useTransition mantiene la entrada responsiva mientras la lista se vuelve a renderizar en segundo plano, que es exactamente lo que INP recompensa.

'use client';
import { useState, useTransition } from 'react';

export function Filter({ items }) {
  const [isPending, startTransition] = useTransition();
  const [query, setQuery] = useState('');

  return (
    <input
      onChange={(e) => {
        const value = e.target.value;
        startTransition(() => setQuery(value));
      }}
    />
  );
}

¿Necesita cada característica interactiva estar en el paquete al cargar? Casi nunca. Audita tus componentes de cliente y normalmente encontrarás que un tercio de ellos pueden moverse al servidor. Para una revisión completa de la arquitectura, nuestro servicio de desarrollo Next.js existe precisamente para este tipo de refactorización.

¿Cómo solucionamos CLS en Next.js?

CLS falla cuando los elementos se mueven después de pintarse, y los culpables habituales son imágenes sin dimensiones, fuentes tardías y banners inyectados. La regla es reservar espacio para todo antes de que llegue. Cuando pasas width y height al componente Image de Next.js, este genera una caja CSS con relación de aspecto que mantiene el diseño estable antes de que se cargue el archivo.

La misma lógica se aplica a los incrustados y anuncios. Envuelve cualquier iframe de terceros en un contenedor con un min-height fijo para que el contenido de abajo no salte cuando el incrustado se hidrate.

<div style={{ minHeight: 400, position: 'relative' }}>
  <Image src="/chart.webp" alt="Quarterly results" fill sizes="100vw" />
</div>

Las fuentes causan los cambios sutiles. next/font reduce esto al hacer coincidir una métrica de reserva con tu fuente web, de modo que el cambio del texto del sistema a la fuente cargada apenas se mueve. Combinado con imágenes con dimensiones, esto es lo que mantiene el CLS cómodamente por debajo del objetivo de 0.1. CLS es el vital más fácil de pasar una vez que haces de "reservar el espacio" un hábito.

¿Cómo medimos y monitorizamos los resultados?

Las herramientas de laboratorio mienten un poco, así que mide a los usuarios reales. Lighthouse y PageSpeed Insights te dan una lectura rápida en un entorno controlado, pero Google clasifica basándose en datos de campo del Informe de Experiencia de Usuario de Chrome, recopilados de visitantes reales de Chrome durante 28 días. La tasa de aprobación móvil ha subido cada año, del 36% en 2023 al 48% en 2025, y el listón sigue subiendo (Web Almanac, 2025).

Para recopilar tus propios datos de campo, el hook useReportWebVitals transmite cada métrica de sesiones reales a tu endpoint de análisis. Vercel Speed Insights lo envuelve por ti, pero el hook sin procesar funciona en cualquier lugar.

'use client';
import { useReportWebVitals } from 'next/web-vitals';

export function WebVitals() {
  useReportWebVitals((metric) => {
    navigator.sendBeacon('/api/vitals', JSON.stringify(metric));
  });
  return null;
}

Nuestro hallazgo: las puntuaciones de laboratorio y de campo divergen más en INP, porque Lighthouse se ejecuta en una máquina rápida sin toques reales. Confía en el número de CrUX para INP, y trata la puntuación de Lighthouse solo como una prueba de humo.

¿Listo para pasar tu auditoría?

Los Core Web Vitals recompensan a los sitios que respetan el tiempo del usuario, y Next.js está construido para ello. Si tu stack actual te está dando problemas, o quieres una compilación que se envíe rápido por defecto, nosotros planificamos, construimos y ajustamos sitios Next.js de principio a fin. Consulta nuestros precios o ponte en contacto para hablar de tus cifras.

Preguntas Frecuentes

¿Cuáles son los umbrales de los Core Web Vitals en 2026?

Una página pasa cuando LCP es de 2.5 segundos o menos, INP es de 200 milisegundos o menos, y CLS es de 0.1 o menos. Google mide cada métrica en el percentil 75 de las vistas de página de usuarios reales (web.dev, 2025), por lo que un puñado de cargas rápidas no rescatará una cola lenta.

¿Next.js pasa automáticamente los Core Web Vitals?

No. Next.js te proporciona los componentes Image y Font, Server Components y streaming, pero una compilación predeterminada aún puede fallar. Tienes que establecer la priority de la imagen, reservar espacio para el diseño y recortar el JavaScript del cliente. El framework elimina las partes difíciles, no elimina el trabajo.

¿Qué reemplazó a First Input Delay?

Interaction to Next Paint reemplazó a First Input Delay el 12 de marzo de 2024 (web.dev, 2024). INP mide la latencia de cada interacción durante una visita, no solo la primera, lo que hace que el JavaScript pesado sea mucho más visible en la puntuación.

¿Afectan los Core Web Vitals al ranking de Google?

Sí, como parte de las señales de experiencia de página. Google afirma que unos buenos vitales se alinean con lo que sus sistemas de clasificación principales recompensan (Google Search Central, 2025). El efecto es más fuerte en consultas móviles competitivas donde muchos resultados son, por lo demás, similares.

¿Cuál Core Web Vital es el más difícil de pasar en móvil?

Largest Contentful Paint. Solo el 62% de los orígenes móviles alcanzaron un buen LCP en 2025, frente al 77% para INP y el 81% para CLS (Web Almanac, 2025). Las imágenes principales lentas y las fuentes que bloquean el renderizado son la causa habitual, por lo que el componente Image es la primera solución.

Conclusión

Pasar los Core Web Vitals no es suerte, es una lista de verificación. Soluciona LCP con el componente Image, priority y next/font. Soluciona INP enviando menos JavaScript a través de Server Components y dynamic(). Soluciona CLS reservando espacio para cada imagen e incrustado. Luego, mide a los usuarios reales con CrUX y el hook useReportWebVitals, porque los datos de campo son lo que Google realmente puntúa. La mitad de la web móvil todavía no supera este umbral. Una compilación limpia de Next.js es cómo aterrizas en la mitad más rápida. Cuando estés listo para lanzar, nuestras últimas guías y nuestro equipo están aquí para ayudarte.