Mejorando Core Web Vitals en la práctica — Cómo reduje el LCP de 3s a 1,2s

Resumen clave

• LCP (Largest Contentful Paint) es una métrica central que impacta directamente en las clasificaciones de búsqueda de Google.
• Aplicando secuencialmente optimización de imágenes, estrategia de carga de fuentes y división de código, el LCP se redujo de 3,0 segundos a 1,2 segundos.
• El CLS se mejoró de 0,28 a 0,04 especificando dimensiones explícitas para las imágenes y áreas de anuncios y eliminando los cambios de diseño.
• Basado en un proyecto Next.js de producción real — los mismos principios se aplican a proyectos React y Vue.

Introducción — ¿Por qué Core Web Vitals?

Cuando Google lanzó la actualización Page Experience en 2021, Core Web Vitals dejó de ser una simple métrica de UX y se convirtió en un factor de clasificación SEO. Desde entonces, Google ha seguido aumentando el peso de estas señales, y desde 2024, INP (Interaction to Next Paint) ha reemplazado completamente a FID como métrica de evaluación.

Un proyecto de comercio electrónico que opero estaba sacando una pésima puntuación de 38 puntos en PageSpeed Insights móvil hace apenas seis meses. El LCP era de 3,0 segundos, el CLS de 0,28, el INP de 320ms — las tres métricas en la zona "Necesita mejora". Este artículo documenta el proceso completo de darle la vuelta a esas cifras.

¿Cómo puedes entender rápidamente las tres Core Web Vitals?

LCP — La velocidad de "primera impresión" de una página

LCP mide el tiempo que tarda en renderizarse el elemento de contenido más grande en el viewport (normalmente la imagen hero o el texto H1). El umbral de Google es 2,5 segundos o menos para Bueno; por encima de 4,0 segundos es Pobre.

En sitios de comercio electrónico, la imagen del banner principal es abrumadoramente la candidata a LCP. Si esta única imagen carga demasiado lento, todas las demás optimizaciones se vuelven irrelevantes.

CLS — ¿"Salta" el diseño?

CLS (Cumulative Layout Shift) mide cuánto se desplazan inesperadamente los elementos durante la carga de la página. Los banners publicitarios que cargan tarde o las imágenes sin dimensiones explícitas hacen que el CLS se dispare. 0,1 o menos es el umbral de Bueno.

INP — ¿Con qué rapidez responde la página a la entrada del usuario?

INP mide el retraso en la respuesta para todas las interacciones — clics, toques, entrada de teclado. Reemplazó a FID en marzo de 2024, y 200ms o menos es el umbral de Bueno. Los bundles pesados de JavaScript bloquean el hilo principal y empeoran el INP.

Diagnosticando el problema — Mediciones iniciales

Registrar con precisión las métricas antes de la optimización es el punto de partida. Estas herramientas se usaron en orden:

1. 1PageSpeed Insights — Proporciona simultáneamente datos de campo (datos reales de usuarios) y datos de laboratorio (Lighthouse)
2. 2Chrome DevTools > pestaña Performance — Inspeccionar la línea de tiempo de renderizado y el elemento candidato a LCP
3. 3WebPageTest — Medición del mundo real desde los servidores edge de CDN, confirmación visual mediante filmstrip
4. 4Vercel Analytics / Sentry — Core Web Vitals recopilados de sesiones reales de usuarios

El diagnóstico redujo los cuellos de botella a tres áreas:

• Imagen hero — JPEG de 4,2 MB, insertado directamente mediante una etiqueta sin optimización
• Google Fonts — 3 familias de fuentes cargadas sincrónicamente mediante @import
• Tamaño del bundle — Chunk principal de 1,8 MB, múltiples bibliotecas incluidas sin tree-shaking

¿Cuáles fueron los tres métodos que redujeron el LCP de 3,0s a 1,2s?

Método 1 — Optimización de imágenes y preload

Este fue el de mayor impacto. El manejo de la imagen hero se rediseñó por completo.

Antes

<img src="/banner.jpg" alt="Banner principal" />

Después — Componente Image de Next.js + conversión a WebP

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="Banner principal"
  width={1920}
  height={800}
  priority          // Las imágenes objetivo de LCP siempre deben tener priority
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

Solo añadir la propiedad priority hace que Next.js inyecte automáticamente una etiqueta para la imagen. Después de convertir a WebP, el tamaño del archivo cayó de 4,2 MB a 340 KB — una reducción del 92% aproximadamente.

Para proyectos puros de HTML/React, añade una etiqueta de preload directamente en :

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

Este único cambio bajó el LCP de 3,0s a 1,8s.

Método 2 — Estrategia de carga de fuentes

Cargar Google Fonts mediante @import hace que el navegador detenga el análisis de CSS y realice una solicitud de fuente. Este tiempo de espera aumenta sustancialmente el LCP.

Antes

<style>
  @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
</style>

Después — + display=swap + autoalojamiento

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />


<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

Usar media="print" y luego cambiar a media="all" al cargar hace que el CSS de la fuente se cargue asincrónicamente sin bloquear el renderizado. display=swap muestra una fuente de respaldo inmediatamente mientras se carga la fuente web, manteniendo el texto visible.

Para máximo rendimiento, autoalojar las fuentes elimina completamente el viaje de ida y vuelta a Google Fonts:

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/inter-regular.woff2') format('woff2');
}

Este paso bajó el LCP de 1,8s a 1,4s.

Método 3 — División de código y optimización de bundles

Un chunk principal de 1,8 MB significa que los usuarios deben descargar y analizar casi 2 MB de JavaScript antes de que la página se vuelva interactiva.

Acciones clave realizadas:

1. 1Imports dinámicos — Las bibliotecas pesadas se cargan solo cuando son necesarias:

// Antes: siempre cargado
import Chart from 'chart.js';

// Después: cargado solo cuando el componente de gráfico se renderiza realmente
const Chart = dynamic(() => import('chart.js'), { ssr: false });

1. 1Auditoría de tree-shaking — Se reemplazó import _ from 'lodash' por imports de funciones individuales:

// Antes: carga toda la biblioteca lodash
import _ from 'lodash';

// Después: carga solo debounce
import debounce from 'lodash/debounce';

1. 1Carga diferida de scripts de terceros — Los scripts de análisis y widget de chat se aplazan para cargarse después de que la página sea interactiva:

<script src="/analytics.js" defer></script>

Después de la optimización de bundles, el tamaño del chunk principal cayó de 1,8 MB a 620 KB, y el LCP mejoró de 1,4s a 1,2s.

¿Cómo se redujo el CLS de 0,28 a 0,04?

Los dos principales culpables del CLS fueron los anuncios y las imágenes sin dimensiones explícitas.

Área de anuncios: Reservar espacio por adelantado

/* Reservar altura mínima para que el slot del anuncio nunca cause un cambio de diseño */
.ad-container {
  min-height: 90px;  /* anuncio de banner */
  min-width: 728px;
}

Imágenes: Especificar siempre ancho/alto

/* Antes: sin dimensiones → causa cambio de diseño durante la carga */
<img src="/product.jpg" alt="Producto" />

/* Después: dimensiones explícitas → el navegador reserva espacio */
<Image
  src="/product.jpg"
  alt="Producto"
  width={400}
  height={300}
/>

Contenido dinámico: Usar placeholders

// Mostrar un placeholder de esqueleto mientras se cargan los datos
{isLoading ? (
  <div className="h-48 bg-gray-200 animate-pulse rounded" />
) : (
  <ProductCard data={data} />
)}

Estos tres cambios llevaron el CLS de 0,28 a 0,04.

Resumen de resultados

Comprueba los Core Web Vitals de tu propio sitio

Usa estas herramientas para medir tu puntuación actual:

• PageSpeed Checker — Comprueba la puntuación de PageSpeed Insights al instante
• Meta Tag Checker — Verifica simultáneamente la configuración de SEO y etiquetas OG

Preguntas frecuentes (FAQ)

Q1. ¿Mejorar Core Web Vitals eleva directamente las clasificaciones de búsqueda?

Core Web Vitals son uno de los factores oficiales de clasificación de Google. Google ha confirmado públicamente que son una señal de Page Experience. Sin embargo, otros factores como la calidad del contenido y los backlinks siguen teniendo más peso, por lo que la mejora de Core Web Vitals debe verse como una condición necesaria más que como una garantía.

Q2. ¿Qué métrica de Core Web Vitals tiene el mayor impacto en las clasificaciones?

LCP es la más visible para los usuarios y tiene el impacto más directo en las tasas de rebote, lo que afecta indirectamente a las clasificaciones. El CLS también afecta directamente a la UX, por lo que ambas son objetivos de alta prioridad. La influencia del INP como métrica más reciente aún se está estableciendo.

Q3. ¿Cómo compruebo mi elemento LCP?

Abre Chrome DevTools, ve a la pestaña Performance, registra una carga de página y busca "LCP" en la línea de tiempo. Alternativamente, ejecutar PageSpeed Insights te dirá exactamente qué elemento es el candidato a LCP.

Q4. ¿Google Fonts perjudica a Core Web Vitals?

Sí. Cargar Google Fonts mediante @import bloquea el renderizado y es una causa común de degradación del LCP. Se recomienda encarecidamente usar combinado con display=swap o autoalojar las fuentes.

Q5. ¿Cuánto ayuda Next.js con Core Web Vitals?

Bastante significativamente. Next.js proporciona optimización automática de imágenes (conversión a WebP, lazy loading, optimización de tamaño), optimización integrada de fuentes (next/font) y división de código basada en rutas como características incorporadas. Solo estas pueden conducir a mejoras dramáticas en Core Web Vitals sin configuración adicional.

Q6. ¿Con qué frecuencia deben comprobarse Core Web Vitals?

Se recomienda monitorear al menos una vez al mes. PageSpeed Insights refleja datos reales de usuarios recopilados durante los últimos 28 días, por lo que los cambios tardan tiempo en aparecer. Usar Google Search Console para hacer un seguimiento de las tendencias de los datos de campo a lo largo del tiempo es más práctico que las mediciones puntuales.