Cuando le digo a un cliente que su sitio tiene un Largest Contentful Paint lento, generalmente obtengo una mirada en blanco. Cuando le digo que su página de inicio tarda 4.2 segundos en mostrar contenido significativo y que esto le está costando posicionamiento en buscadores y clientes, la conversación cambia.

Los Core Web Vitals son la forma que tiene Google de medir la experiencia de usuario de una página. Son señales de ranking desde 2021, y hoy importan más que nunca. Pero más allá del posicionamiento, miden algo genuinamente importante: si tu sitio se siente rápido y estable para las personas que lo usan.

Las tres métricas que importan

Largest Contentful Paint (LCP) mide cuánto tiempo tarda en cargar el elemento visible más grande de la página. Por ejemplo: la imagen hero, el encabezado principal, la foto destacada. El umbral de Google es 2.5 segundos — por encima de eso, estás en la zona de "necesita mejoras". Más de 4 segundos es malo.

Esta es la métrica que veo fallar con más frecuencia, y casi siempre por las mismas razones: imágenes sin optimizar, recursos que bloquean el renderizado, o un servidor demasiado lento.

Cumulative Layout Shift (CLS) mide la inestabilidad visual — cuánto salta el diseño de la página mientras carga. Experimentaste un CLS malo cuando vas a tocar un botón y justo en ese momento se desplaza, y terminás tocando otra cosa. El umbral de Google es una puntuación de 0.1.

Los fallos de CLS son casi siempre causados por imágenes o publicidades sin dimensiones explícitas, o por fuentes web que cargan y se intercambian después de que la página ya renderizó.

Interaction to Next Paint (INP) reemplazó al First Input Delay en 2024 y mide la capacidad de respuesta — específicamente, cuánto tarda la página en responder visualmente después de cualquier interacción del usuario. El umbral es 200 milisegundos.

Un INP alto generalmente apunta a JavaScript haciendo demasiado trabajo en el hilo principal, bloqueando al navegador para responder a la interacción del usuario.

Qué realmente soluciono

Abordo los Core Web Vitals igual que cualquier problema técnico: mido primero, después soluciono. No adivino qué es lento — uso PageSpeed Insights, Chrome DevTools y los datos de campo del Chrome User Experience Report (CrUX) para encontrar los cuellos de botella reales.

Esto es a lo que se reduce la mayoría de las soluciones:

Para LCP:

  • Convertir imágenes a WebP o AVIF — típicamente 30–70% más pequeñas que JPEG con calidad equivalente
  • Agregar <link rel="preload" as="image" fetchpriority="high"> para el elemento LCP, para que el navegador lo descubra y descargue de inmediato, sin esperar a parsear toda la hoja de estilos
  • Eliminar scripts y estilos que bloquean el renderizado
  • Usar loading="eager" en la imagen LCP y loading="lazy" en todo lo que está debajo del fold
  • Optimizar el tiempo de respuesta del servidor — el TTFB (Time to First Byte) es la base sobre la que todo lo demás se construye

Para CLS:

  • Agregar atributos explícitos width y height a cada etiqueta <img> — esto solo elimina la mayor parte del CLS
  • Agregar font-display: swap a las declaraciones de fuentes web y preconnect a los CDN de fuentes para minimizar los saltos de diseño por la carga de fuentes
  • Reservar espacio para contenido dinámico (publicidades, embeds) antes de que carguen

Para INP:

  • Auditar y dividir los bundles de JavaScript grandes — cargar solo lo necesario para la página actual
  • Mover computaciones costosas fuera del hilo principal usando web workers
  • Diferir scripts no críticos con async o defer
  • Evitar tareas largas (cualquier cosa de más de 50ms) en event handlers

El caso de negocio

Google publicó datos que muestran que cuando el tiempo de carga de una página pasa de 1s a 3s, la probabilidad de que un visitante abandone aumenta un 32%. De 1s a 5s, es un 90%. Estos no son números abstractos — son clientes que se van antes de ver tu oferta.

Más allá de la tasa de abandono, los Core Web Vitals son un factor de ranking directo. Dos páginas con contenido equivalente serán rankeadas de forma diferente según su rendimiento. Si tus competidores tienen sitios más rápidos, te superan en el ranking incluso con igual esfuerzo SEO.

Vi esto directamente cuando trabajé en optimización de rendimiento para clientes de e-commerce y servicios: arreglar el LCP redujo la tasa de abandono, y la combinación de mejor posicionamiento más mejor experiencia en el sitio se compuso en mejoras de revenue medibles.

El rendimiento y las funcionalidades avanzadas no están en conflicto

Algo en lo que quiero cuestionar la suposición: que agregar funcionalidades ricas e interactivas a un sitio significa aceptar un rendimiento más lento. No tiene que ser así.

Cuando construyo experiencias web 3D e inmersivas, aplico la misma disciplina de presupuesto de rendimiento que uso en cada proyecto — mejora progresiva, assets con carga diferida, y preloading agresivo para lo que más importa. Una escena Three.js y una puntuación de 90+ en PageSpeed no son mutuamente excluyentes. Solo requieren una arquitectura más cuidadosa.

Obtener una auditoría de rendimiento

Si no sabés cómo está parado tu sitio, el punto de partida siempre es PageSpeed Insights en pagespeed.web.dev. Pegá tu URL y leé las secciones Opportunities y Diagnostics — ahí están los problemas accionables.

Si querés que haga una auditoría completa y solucione los problemas que encuentro, lo hago como un engagement independiente. El alcance y el costo dependen de en qué está construido el sitio y qué revela la auditoría.

Contactáme y contame sobre tu sitio — te doy una evaluación honesta de qué vale la pena solucionar y qué priorizar.