Tu usuario toca un botón de filtro—300 milisegundos pasan antes de que la UI responda. El Real User Monitoring de Google registra el retraso. Tu tasa de conversión cae otro medio punto. Core Web Vitals pasó de ser una curiosidad de clasificación a la línea medible entre sitios que convierten y sitios que pierden usuarios. En 2026, INP reemplazó completamente a FID, los umbrales de CLS se ajustaron más, y las métricas de Smoothness que se rumorean ya están en Chrome Canary. Esta guía destila 200+ auditorías de rendimiento que hemos ejecutado en Social Animal en las correcciones específicas del framework, puntos de referencia reales y fragmentos de código que realmente mueven tus puntuaciones—sin consejos vagos sobre "optimizar imágenes". Te mostraremos los tres lugares donde INP se rompe en Next.js 14 App Router, el ajuste de Intersection Observer de dos líneas que redujo nuestro LCP un 40%, y por qué tus scripts de terceros aún rompen CLS incluso cuando crees que son asincronos.

Tabla de Contenidos

¿Qué son Core Web Vitals en 2026?

Core Web Vitals son el conjunto estándar de métricas UX de Google que influyen directamente en las clasificaciones de búsqueda—y, honestamente, mucho más importante que eso, en el comportamiento del usuario. Miden lo que los usuarios realmente sienten: qué tan rápido aparece el contenido, qué tan rápido responde la página cuando toca algo, y si el diseño se mantiene en su lugar o se mueve como si estuviera poseso.

INP reemplazó oficialmente a FID en marzo de 2024. A mediados de 2025, los datos de uso de Chrome mostraban que el 38% de los orígenes aún no cumplían con el umbral de INP—compara eso con la cómoda tasa de aprobación del 92% de que disfrutaba FID. Esto no fue Google moviendo los postes. Finalmente estaban midiendo lo que realmente importaba.

Dónde estamos las cosas a principios de 2026:

  1. Largest Contentful Paint (LCP)—Rendimiento de carga
  2. Interaction to Next Paint (INP)—Capacidad de respuesta
  3. Cumulative Layout Shift (CLS)—Estabilidad visual

Google también ha señalado interés en una métrica de Smoothness (piensa en caídas de fotogramas de animación y jank de desplazamiento), aunque aún no ha sido promovida al estado de Core Web Vital. Los equipos inteligentes ya la están rastreando a través de la API Long Animation Frames (LoAF). Si no lo estás—empieza.

Las Métricas Actuales y sus Umbrales

Métrica Bueno Necesita Mejora Pobre Qué Mide
LCP ≤ 2,5s 2,5s – 4,0s > 4,0s Tiempo hasta que se renderiza el elemento más grande visible
INP ≤ 200ms 200ms – 500ms > 500ms Peor latencia de interacción en toda la sesión
CLS ≤ 0,1 0,1 – 0,25 > 0,25 Suma de puntuaciones de desplazamiento de diseño inesperado

Aquí está lo que la gente constantemente olvida. Estos umbrales se miden en el percentil 75 de cargas de página del Chrome User Experience Report (CrUX) real. Eso significa que el 75% de tus visitantes reales necesitan alcanzar "Bueno". No tu prueba en un MacBook Pro con internet de fibra. Tus usuarios reales—en sus Samsungs de tres años, viajando en el metro con LTE inestable. Diferencia masiva.

Optimización de Largest Contentful Paint (LCP)

LCP es típicamente la métrica que los equipos entienden mejor—y sin embargo, es la que la mayoría de sitios aún fallan. Los datos de fin de año 2025 del HTTP Archive mostraban que solo el 63% de los orígenes móviles pasaban LCP. Eso es... no es excelente.

Entender las Subpartes de LCP

Google dividió LCP en cuatro subpartes en su documentación de 2024. Este framework es la herramienta de diagnóstico individual más efectiva que hemos encontrado—nada más se acerca:

Subparte Objetivo Qué Cubre
Time to First Byte (TTFB) < 800ms Respuesta del servidor, DNS, TLS, redirecciones
Resource Load Delay < 10% de LCP Tiempo entre TTFB y cuando comienza a cargarse el recurso LCP
Resource Load Duration < 40% de LCP Tiempo para descargar el recurso LCP
Element Render Delay < 10% de LCP Tiempo entre recurso cargado y píxel renderizado

Correcciones del Lado del Servidor

Reduce TTFB moviendo a edge computing. ¿Aún sirviendo desde un único origen? Te estás regalando 200-800ms para usuarios lejos de tu servidor. Regalándolo. Gratis.

// Middleware de Next.js para rendering edge-first
// next.config.js
export default {
  experimental: {
    runtime: 'edge',
  },
};

// middleware.ts — se ejecuta en el edge
import { NextResponse } from 'next/server';
export const config = { matcher: ['/((?!api|_next/static|favicon.ico).*)'] };

export function middleware(request) {
  const response = NextResponse.next();
  // Agregar encabezados de server timing para debugging
  response.headers.set('Server-Timing', `edge;desc="Edge Middleware"`);
  return response;
}

Para equipos en Astro o Next.js, las páginas renderizadas en edge consistentemente alcanzan TTFB bajo 200ms globalmente. Nuestras prácticas de desarrollo Next.js y desarrollo Astro por defecto usan despliegue en edge.

Optimización del Descubrimiento de Recursos

Aquí está lo que la mayoría de personas se pierden—el mayor asesino de LCP en 2026 no son los servidores lentos. Es el descubrimiento tardío del recurso LCP. Si la URL de tu imagen de héroe está enterrada en un archivo CSS o metida dentro de un bundle JavaScript, el navegador ni siquiera puede empezar a descargarla hasta que toda esa cadena se resuelva. Básicamente estás ocultando lo más importante en tu página detrás de una búsqueda del tesoro.

<!-- Precargar la imagen LCP con fetchpriority -->
<link
  rel="preload"
  as="image"
  href="/hero-2400.webp"
  fetchpriority="high"
  media="(min-width: 768px)"
/>
<link
  rel="preload"
  as="image"
  href="/hero-800.webp"
  fetchpriority="high"
  media="(max-width: 767px)"
/>

<!-- En el elemento de imagen en sí -->
<img
  src="/hero-2400.webp"
  alt="Dashboard de producto"
  width="2400"
  height="1200"
  fetchpriority="high"
  decoding="async"
  sizes="100vw"
  srcset="/hero-800.webp 800w, /hero-1600.webp 1600w, /hero-2400.webp 2400w"
/>

Reglas clave:

  • Nunca carga perezosamente el elemento LCP. Esto es innegociable.
  • Usa fetchpriority="high" en la imagen LCP—compatible en todos los navegadores modernos desde 2025.
  • Inserta CSS crítico o precargar fonts que bloqueen el renderizado.
  • Sirve imágenes en AVIF con fallback WebP. AVIF ocupa un 30-50% menos que WebP con calidad equivalente. Si aún estás enviando WebP como tu formato principal en 2026, estás dejando bytes en la mesa.

LCP para Elementos Basados en Texto

Cuando tu elemento LCP es un encabezado o párrafo (super común en sitios de contenido), los recursos que bloquean el renderizado se convierten en tu enemigo:

<!-- Precargar tu font principal -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-v.woff2" crossorigin />

<!-- Usa font-display: optional para la pintura más rápida -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-v.woff2') format('woff2');
    font-display: optional; /* Elimina el cambio de diseño del intercambio de fuentes */
  }
</style>

font-display: optional previene tanto FOIT como FOUT cayendo a la fuente del sistema si la web font no está almacenada en caché. ¿La compensación? Los visitantes por primera vez ven la fuente del sistema. ¿La ganancia? Cero CLS del intercambio de fuentes y LCP más rápido. Aceptaremos ese intercambio cada vez.

Optimización de Interaction to Next Paint (INP)

INP es la métrica que separa los buenos sitios de los excelentes en 2026. La mayoría de agencias lo hacen mal. A diferencia de FID, que solo medía el retraso de entrada de la primera interacción, INP captura el ciclo de vida completo de cada interacción: retraso de entrada, tiempo de procesamiento y retraso de presentación—luego reporta aproximadamente el peor (percentil 98).

Anatomía de una Interacción

[Usuario hace clic] → [Retraso de Entrada] → [Procesamiento de Evento] → [Retraso de Presentación] → [Siguiente fotograma pintado]
                      ↑                        ↑                             ↑
                      Bloqueado por            Tu handler de clic           El navegador renderiza
                      thread principal        se ejecuta                     los cambios del DOM

Reducir el Retraso de Entrada

El retraso de entrada ocurre cuando el thread principal está ocupado haciendo otra cosa cuando el usuario toca. Los culpables usuales:

  1. Scripts de terceros—Analytics, widgets de chat, herramientas de testing A/B. Tu sitio empresarial típico carga 15-30 scripts de terceros, y cada uno lucha por tiempo de thread principal. Es una escena de muchedumbre allá.
  2. Tormentas de hidratación—SPAs que hidratan la página completa de una vez bloquean el thread principal por 200-2000ms. Eso es una eternidad cuando alguien intenta tocar un botón.
  3. Tareas largas—Cualquier tarea JavaScript mayor a 50ms retrasa la entrada. Punto.
// Romper tareas largas con scheduler.yield()—disponible en Chrome 129+
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // Cede al thread principal cada 5 elementos
    if (i % 5 === 0) {
      await scheduler.yield();
    }
  }
}

Para navegadores sin scheduler.yield(), aquí está el fallback:

function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Reducir el Tiempo de Procesamiento

Aquí es donde viven tus event handlers. La corrección es arquitectónica, no cosmética:

  • Debounce y throttle handlers costosos (scroll, resize, input).
  • Mueve computación del thread principal con Web Workers o la API scheduler.postTask().
  • Usa CSS para animaciones en lugar de JavaScript. Los cambios de transform y opacity no disparan layout o paint.
// Usa scheduler.postTask() para trabajo no urgente
button.addEventListener('click', async () => {
  // Urgente: retroalimentación visual inmediatamente
  button.classList.add('active');
  
  // No urgente: analytics, actualizaciones de estado
  scheduler.postTask(() => {
    analytics.track('button_clicked');
  }, { priority: 'background' });
  
  // Visible para el usuario pero no inmediato
  scheduler.postTask(() => {
    updateDashboard();
  }, { priority: 'user-visible' });
});

Reducir el Retraso de Presentación

El retraso de presentación es la brecha entre tu event handler terminando y el navegador realmente pintando el siguiente fotograma. Qué lo causa:

  • Tamaño excesivo del DOM—Páginas con más de 1,400 elementos del DOM muestran INP mediblemente peor. ¿La mediana del HTTP Archive 2025? 1,600 elementos en móvil. La mayoría de sitios son demasiado inflados.
  • Selectores CSS complejos—Selectores profundamente anidados fuerzan recálculos de estilo costosos cada vez que algo cambia.
  • Layout thrashing—Leer propiedades de layout como offsetHeight justo después de escribir en el DOM fuerza layout sincrónico. Este muerde a la gente constantemente. Nunca lo ven venir.
// MALO: Layout thrashing
elements.forEach(el => {
  const height = el.offsetHeight; // Fuerza layout
  el.style.height = height + 10 + 'px'; // Invalida layout
});

// BUENO: Agrupar lecturas, luego agrupar escrituras
const heights = elements.map(el => el.offsetHeight); // Todas las lecturas primero
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // Todas las escrituras segundo
});

Optimización de Cumulative Layout Shift (CLS)

CLS mide inestabilidad visual—cosas saltando alrededor mientras la página carga o durante interacciones. Google usa un enfoque de "session window": los desplazamientos dentro de 1 segundo entre sí, limitados a 5 segundos por ventana, se agrupan juntos. CLS reporta la ventana de sesión más grande.

Los Sospechosos Usuales

Causa Corrección Impacto
Imágenes sin dimensiones Agregar atributos width y height Alto
Contenido inyectado dinámicamente (ads, embeds) Reservar espacio con min-height o aspect-ratio Alto
Web fonts causando FOUT Usar font-display: optional o size-adjust Medio
CSS cargado tarde Insertar CSS crítico, precargar el resto Medio
Animaciones disparando layout Usar transform en lugar de top/left/width/height Bajo-Medio

La Propiedad CSS `aspect-ratio`

No exagero cuando digo que esta propiedad eliminó una clase entera de problemas de CLS de la noche a la mañana. Úsala en todas partes:

/* Reservar espacio para imágenes */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
}

/* Reservar espacio para embeds de video */
.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

/* Reservar espacio para slots de anuncios */
.ad-slot-leaderboard {
  aspect-ratio: 728 / 90;
  min-height: 90px;
  contain: layout;
}

La Propiedad `content-visibility`

content-visibility: auto le dice al navegador que salte el renderizado de contenido fuera de pantalla. Esto reduce dramáticamente el costo de layout inicial y puede mejorar tanto CLS como INP:

.below-the-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Altura estimada para prevenir CLS */
}

Hemos medido reducciones del 30-50% en tiempo de renderizado en páginas con mucho contenido con esta técnica. Rendimiento casi gratuito. No hay buena razón para no usarla en páginas con mucho contenido.

Estrategias Específicas del Framework

Next.js (App Router, v15+)

Next.js 15 envió Partial Prerendering (PPR) como estable, y honestamente—es un verdadero cambio de juego para LCP. Los shells estáticos se renderizan instantáneamente en el edge; el contenido dinámico se transmite a través de límites de React Suspense.

// app/page.tsx — Shell estático con isla dinámica
import { Suspense } from 'react';
import { HeroSection } from '@/components/HeroSection'; // Estático
import { PersonalizedOffers } from '@/components/PersonalizedOffers'; // Dinámico

export default function HomePage() {
  return (
    <>
      <HeroSection /> {/* Renderizado en tiempo de compilación — LCP instantáneo */}
      <Suspense fallback={<OffersSkeleton />}>
        <PersonalizedOffers /> {/* Se transmite después del shell */}
      </Suspense>
    </>
  );
}

El componente <Image> de Next.js maneja srcset, negociación AVIF/WebP y lazy-loading automáticamente. Pero—y esto confunde a la gente constantemente—aún necesitas establecer priority en imágenes LCP. No lo adivinará por ti:

<Image
  src="/hero.jpg"
  alt="Héroe"
  width={2400}
  height={1200}
  priority // Establece fetchpriority="high" y desactiva lazy loading
  sizes="100vw"
/>

Nuestro enfoque completo para compilaciones Next.js orientadas al rendimiento está en nuestra página de capacidades de desarrollo Next.js.

Astro

La arquitectura de cero JavaScript por defecto de Astro significa que la mayoría de sitios Astro pasan Core Web Vitals directamente de la caja. El Web Almanac del HTTP Archive 2025 mostró que los sitios Astro tenían la tasa más alta de aprobación de Core Web Vitals de cualquier framework al 82%. Eso no es coincidencia—es lo que sucede cuando el predeterminado es enviar cero JavaScript del lado del cliente.

Los patrones clave:

---
// src/pages/index.astro
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---

<!-- Astro optimiza esto en tiempo de compilación a AVIF/WebP con srcset -->
<Image
  src={heroImage}
  alt="Héroe"
  widths={[400, 800, 1600, 2400]}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

<!-- Isla interactiva — solo carga JS cuando es visible -->
<SearchBar client:visible />

La directiva client:visible significa que el JavaScript de la barra de búsqueda no se carga hasta que el usuario se desplaza hacia ella, manteniendo el thread principal limpio durante la carga inicial. Más en nuestro enfoque de desarrollo Astro.

Consideraciones de Headless CMS

Con un headless CMS—Contentful, Sanity, Storyblok, lo que sea que estés ejecutando—el tiempo de respuesta de la API del CMS se convierte en parte de tu TTFB. Nadie piensa en esto hasta que te muerde.

Nuestros puntos de referencia en proyectos de clientes:

CMS Respuesta API Prom. (CDN Cacheada) Respuesta API Prom. (Origen) Notas
Contentful 45ms 180ms La API GraphQL es un poco más lenta que REST
Sanity 35ms 120ms Las consultas GROQ son rápidas; CDN es excelente
Storyblok 50ms 200ms La API V2 mejoró significativamente
Strapi (Auto-hospedado) Variable Variable Depende completamente de tu infraestructura

El patrón crítico: no llames APIs de CMS en tiempo de solicitud a menos que genuinamente necesites personalización. Usa ISR o revalidación bajo demanda para servir páginas pre-compiladas. Hemos visto equipos agregar 300ms+ a su TTFB solo porque alguien conectó una llamada fetch en un componente de servidor que debería haber sido cacheado. Enternecedor. Nuestra práctica de desarrollo de headless CMS construye esto por defecto.

Medición y Monitoreo en Producción

Datos de Laboratorio vs. Datos de Campo

Mira, los datos de laboratorio (Lighthouse, WebPageTest) te dicen lo que podría suceder. Los datos de campo (CrUX, RUM) te dicen lo que realmente sucede. Divergen—a veces salvajemente. Y cuando los stakeholders agitan una puntuación de Lighthouse 100 como un trofeo mientras sus datos de CrUX están fallando? Sí. Tenemos esa conversación mucho más a menudo de lo que nos gustaría.

Aquí está lo que las herramientas de laboratorio simplemente no pueden dar cuenta:

  • Dispositivos lentos (el teléfono Android mediano tiene aproximadamente 1/5 de la potencia de CPU de un iPhone 15)
  • Variabilidad de red en el mundo real
  • Extensiones del navegador haciendo quién sabe qué
  • Comportamiento de scripts de terceros en producción—cosas que actúan completamente diferente de tu entorno de staging

Stack de Monitoreo Recomendado (2026)

Herramienta Tipo Costo Mejor Para
Google CrUX Campo (28 días) Gratis Impacto SEO—esto es lo que Google realmente usa
web-vitals.js Campo (tiempo real) Gratis Pipeline RUM personalizado
Vercel Speed Insights Campo Gratis (con Vercel) Sitios Next.js en Vercel
SpeedCurve Lab + Campo $12-200/mes Benchmarking competitivo, filmstrips
Sentry Performance Campo $26+/mes Vinculando rendimiento a errores
DebugBear Lab + Campo + CrUX $99+/mes Mejor rastreo de cambios de CrUX que hemos usado

Configurar web-vitals.js

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // Datos de atribución — te dice POR QUÉ la métrica es mala
    attribution: metric.attribution,
  };

  // Usa sendBeacon para fiabilidad
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', JSON.stringify(body));
  }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

La compilación /attribution es crítica—agrega información de diagnóstico como qué elemento fue el LCP, cuál interacción causó el peor INP, y qué elementos se desplazaron para CLS. Sin ella estás volando a ciegas. Solo mirando números sin contexto cero para lo que realmente necesitas arreglar.

Técnicas Avanzadas para 2026

API de Speculation Rules

La API de Speculation Rules (Chrome 121+, ~75% de compatibilidad de navegadores en 2026) pre-renderiza páginas antes de que el usuario realmente haga clic a través. ¿El resultado? LCP casi instantáneo en navegaciones posteriores:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

"eagerness": "moderate" pre-renderiza al pasar el mouse—lo suficientemente agresivo para sentirse instantáneo, lo suficientemente conservador para no destrozar el ancho de banda de tus usuarios. Aterrizamos en esto después de muchas pruebas y errores. Es el punto dulce.

API de View Transitions

Las transiciones de vista nativas (cross-document, compatibles en Chrome 126+) te dan animaciones suaves de página a página sin la sobrecarga del framework JavaScript. Mejoran directamente el rendimiento percibido y reducen CLS durante la navegación:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

API de Long Animation Frames (LoAF)

LoAF reemplaza Long Tasks y te da mucho más poder de diagnóstico. Honestamente desearía haber tenido esto hace tres años:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.log('Long animation frame:', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          sourceURL: s.sourceURL,
          sourceFunctionName: s.sourceFunctionName,
          duration: s.duration,
        })),
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Esto te dice exactamente qué script y qué función causó el fotograma largo. Hemos pasado sesiones de auditoría completas solo mirando salida de LoAF, encontrando el arma humeante en minutos en lugar de horas. Para debugging de INP, es la mejor herramienta que existe ahora. Nada más se acerca.

El Impacto Empresarial: Números Reales

La optimización de rendimiento no es un proyecto de vanidad. No es algo que apruebes porque a un desarrollador le gustaría que fuera genial. De estudios de casos de 2025:

  • Vodafone mejoró LCP en 31%, resultando en 8% más ventas.
  • Tokopedia redujo INP en 40%, aumentando la duración de sesión en 15%.
  • NDTV mejoró CLS en 55%, reduciendo la tasa de rebote en 50%.
  • Rakuten 24 mejoró CLS en 0,2 puntos, impulsando un aumento del 33,1% en ingresos por visitante.

Nuestros propios datos de cliente en Social Animal muestran que los sitios que pasan los tres Core Web Vitals ven un promedio de 23% menor tasa de rebote y 12% mayor tasa de conversión en comparación con sus líneas de base previas a la optimización.

Para ecommerce, las matemáticas son muertas simples: una mejora de 1 segundo en LCP se correlaciona con un aumento de conversión del 2-5%. En una tienda de $10M/año, eso son $200K-$500K en ingresos adicionales. ¿El costo de la optimización? Una fracción de eso. Consulta nuestra página de precios para detalles específicos, o contacta directamente para hablar de tu situación.

Preguntas Frecuentes

¿Cuáles son las métricas Core Web Vitals en 2026? Los tres Core Web Vitals son Largest Contentful Paint (LCP), Interaction to Next Paint (INP), y Cumulative Layout Shift (CLS). INP reemplazó First Input Delay (FID) allá en marzo de 2024 y es aún la métrica de capacidad de respuesta. Google ha insinuado una métrica de Smoothness pero aún no la ha agregado como Core Web Vital.

¿Cuánto afectan Core Web Vitals a las clasificaciones SEO? Son una señal de clasificación confirmada dentro de las señales de experiencia de página de Google, pero funcionan más como un desempate que como factor principal—la relevancia de contenido aún domina. Donde realmente tienen impacto es en el comportamiento del usuario: tasa de rebote, engagement, tiempo en el sitio. Ese material indirectamente afecta las clasificaciones de maneras que son difíciles de atribuir directamente pero imposibles de ignorar. Los sitios que pasan todos los Core Web Vitals consistentemente muestran mejores números de engagement, y eso se compone con el tiempo.

¿Cuál es una buena puntuación INP en 2026? 200 milisegundos o menos, medido en el percentil 75 de datos de usuario real. Entre 200ms y 500ms necesita mejora. Más de 500ms es pobre. El INP mediano del sitio web en móvil se sienta en aproximadamente 280ms a principios de 2026—significando que la mayoría de sitios aún no pasan. Déjalo que eso se asimile.

¿Por qué mi puntuación de Lighthouse es diferente de mis datos de CrUX? Porque están midiendo fundamentalmente cosas diferentes. Lighthouse se ejecuta en un entorno simulado con CPU y red acelerada en una carga de página única. Los datos de CrUX provienen de usuarios reales de Chrome durante una ventana móvil de 28 días en todas las páginas en tu origen. La brecha viene de la diversidad de dispositivos (usuarios reales en teléfonos Android lentos), comportamiento de scripts de terceros en producción, distancia geográfica de tus servidores, y el hecho de que CrUX captura la sesión completa—cada interacción para INP, cada cambio de diseño para CLS—mientras Lighthouse captura una carga. Hemos visto sitios puntuar 95+ en Lighthouse y fallar CrUX en toda la línea. No confíes solo en datos de laboratorio.

¿Un headless CMS ayuda o daña Core Web Vitals? Una arquitectura headless CMS fundamentalmente ayuda porque desacopla la capa de presentación de la gestión de contenido. Puedes emparejarla con frameworks modernos como Next.js o Astro con renderizado de edge, sirviendo HTML estático o renderizado por servidor con JavaScript mínimo. Las plataformas monolíticas tradicionales—WordPress sin optimización pesada, Drupal de la caja—típicamente envían mucho más JavaScript y tienen TTFB más lento. La cosa clave: asegúrate de que las llamadas API de CMS ocurran en tiempo de compilación o se cacheen agresivamente, no disparadas en cada solicitud.

¿Cómo arreglo una puntuación INP pobre causada por scripts de terceros? Empieza auditando con la API Long Animation Frames o el panel de Rendimiento de Chrome DevTools para identificar qué scripts están robando el thread principal. Luego: carga scripts no críticos con async o defer, usa setTimeout o requestIdleCallback para retrasar su inicialización, considera mover scripts de terceros del thread principal vía un web worker (Partytown es excelente para esto), y—esta es la parte que nadie quiere escuchar—elimina sin piedad cualquier cosa que no proporcione valor empresarial medible. ¿Ese widget de chat que nadie usa? Mátalo. Hemos visto sitios caer de 500ms+ INP a menos de 150ms solo aplazando widgets de chat y herramientas de testing A/B. Es casi siempre inflación de terceros.

¿Cuál es la forma más rápida de mejorar LCP en un sitio Next.js? En orden de impacto: habilita Partial Prerendering (PPR) para shells estáticos instantáneos, despliega a runtime de edge (Vercel Edge o Cloudflare), establece priority en tu componente <Image> LCP, deja de bloquear renderizado con componentes de cliente innecesarios arriba del pliegue, y precargar fonts críticas. Pero aquí está lo que realmente vemos en la práctica: la causa raíz es data fetching del lado del cliente que debería ser un componente de servidor. Mover un solo componente de 'use client' a un componente de servidor puede rapar 500ms o más de LCP. Es salvaje qué tan a menudo eso resulta ser la corrección completa.

¿Con qué frecuencia actualiza Google los umbrales de Core Web Vitals? Poco frecuente. El cambio importante fue intercambiar FID por INP, anunciado en mayo de 2023 e implantado en marzo de 2024. Los valores de umbral reales—2,5s para LCP, 200ms para INP, 0,1 para CLS—no se han movido desde que fueron introducidos. Google típicamente da 6-12 meses de aviso antes de que algo cambie. Pero el equipo de Chrome continuamente ajusta cómo se calculan las métricas bajo el capó, así que necesitas mantener un ojo en tus datos de campo incluso cuando los umbrales se mantienen firmes. Las cosas cambian sin que nadie lo anuncie.