Core Web Vitals en 2026: cómo logramos 100/100

TL;DR — Unos Core Web Vitals perfectos en un sitio static-first se reducen a cuatro disciplinas aburridas: enviar menos JavaScript, auto-alojar un subconjunto de tus fuentes con un font-display sensato, dar a cada imagen dimensiones explícitas y lazy-load debajo del pliegue, y dejar que un CDN sirva HTML pre-renderizado desde el edge. Hazlas y el 100/100 deja de ser suerte.

Construimos sitios de marketing y páginas de producto para clientes que no tienen un equipo de performance — y no deberían necesitarlo. Una puntuación verde en Lighthouse no es la meta en sí; es un proxy de un sitio que se siente instantáneo para una persona real, con un teléfono de gama media y un LTE irregular. La buena noticia: las tácticas que mueven la aguja están bien entendidas y son en gran parte de configurar-y-olvidar. Este es el plan que ejecutamos en cada build static-first.

LCP: lo más grande debe llegar primero

El Largest Contentful Paint casi siempre es o una imagen hero o un encabezado renderizado con una fuente web. Ambos tienen arreglo.

Para la imagen hero: sírvela en un formato moderno (AVIF con fallback a WebP), dimensiónala para el ancho real con el que se renderiza y hazle preload para que el navegador la pida antes de terminar de parsear el CSS. No hagas lazy-load de nada por encima del pliegue — hacer lazy-load de tu elemento LCP es la herida autoinfligida más común que vemos.

Para las fuentes: auto-alójalas. Tirar de fuentes desde un origen de terceros añade una resolución DNS, un handshake TLS y una conexión que no controlas. Crea un subconjunto de la fuente con los glifos que realmente usas (Latin, quizá Latin-Extended), sirve woff2 y preload de los uno o dos pesos que se renderizan sobre el pliegue.

<link rel="preload" href="/fonts/inter-subset.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-subset.woff2") format("woff2");
  font-weight: 400 700;
  font-display: swap;
}

font-display: swap muestra el texto de fallback de inmediato e intercambia la fuente web cuando carga — sin retraso de texto invisible contando contra el LCP.

CLS: nada debe moverse después de pintar

El Cumulative Layout Shift lo causa contenido que llega tarde y empuja todo lo demás. Dos arreglos cubren ~90% de los casos.

Primero, cada imagen y embed lleva atributos width y height explícitos (o un aspect-ratio en CSS). El navegador reserva la caja antes de que lleguen los píxeles, así el texto de abajo nunca salta.

<img src="/hero.avif" width="1200" height="630" alt="..." loading="eager" fetchpriority="high">

Segundo, el swap de fuente no debe mover el layout. Elige un fallback cuyas métricas se parezcan a tu fuente web, o ajústalas con size-adjust y ascent-override en el @font-face. El cambio de fallback a fuente web debe ser casi invisible — no un reflow que se note.

Un sitio que nunca se mueve después de pintar se siente confiable. El layout shift es el equivalente digital a un mesero que golpea tu mesa — pequeño, pero lo notas cada vez.

INP y JavaScript: cuanto menos envías, más rápido respondes

El Interaction to Next Paint mide qué tan rápido reacciona la página cuando alguien toca o escribe. El enemigo es un hilo principal gordo, atragantado con JavaScript que no necesitaba descargar.

Static-first gana aquí por defecto — simplemente hay menos JS que parsear y ejecutar. Nuestras reglas:

1. Envía HTML, no un framework, siempre que sea posible. Una página estática con toques de JS vanilla le gana a una SPA hidratada en un sitio de contenido, siempre.
2. Difiere o haz lazy-load de los scripts no críticos. Analytics, widgets de chat y embeds cargan tras la interacción o en idle — nunca bloqueando el primer pintado.
3. Evita el layout-thrashing en scroll. Usa IntersectionObserver, no listeners de eventos de scroll que leen el layout en cada frame.
4. Mantén a los terceros con correa. Cada tag manager, herramienta de A/B y tracker es JavaScript de otra persona corriendo en tu hilo principal. Audítalos trimestralmente y corta lo que no se gana su peso.

Edge y caching: sirve la respuesta desde cerca

El HTML pre-renderizado y cacheado en el edge de un CDN es la victoria de performance más barata que existe. Una petición de un usuario en Miami debería responderse desde un nodo en Miami, no con un viaje de ida y vuelta a un servidor de origen en otro lado.

Las tácticas:

• Pre-renderiza en tiempo de build para que el edge sirva un documento terminado, no uno ensamblado por petición.
• Pon cache largo a los assets estáticos (Cache-Control: immutable) y pon fingerprint a los nombres de archivo para que un deploy invalide solo lo que cambió.
• Comprime con Brotli y habilita HTTP/2 o HTTP/3 — la mayoría de los CDN lo hacen por ti.
• Pon las imágenes también en el CDN, idealmente con negociación de formato al vuelo para que AVIF vaya a los navegadores que lo soportan.

La conclusión

El performance es un presupuesto que defiendes, no un arreglo que envías una sola vez. Un sitio que marca 100/100 en el lanzamiento se erosionará en silencio cuando alguien añada un píxel de marketing, una imagen hero más pesada o un peso de fuente más. Define un presupuesto — un techo de tamaño de JS, un límite de peso de imágenes, un piso de Lighthouse en CI — y trata las regresiones como bugs. La parte difícil nunca fue alcanzar la puntuación. Es mantenerse ahí.