Google solía clasificar los sitios web en función de palabras clave y vínculos de retroceso. En 2021, introdujeron la Actualización de experiencia de página. Cambiaron el algoritmo para filtrar los sitios que son “molestos”.

Molesto = Lento (LCP).
Molesto = Nervioso (CLS).
Molesto = No responde (INP).

Si no cumple con estos Core Web Vitals (CWV), no solo molestará a los usuarios; pierdes tráfico orgánico. En Maison Code Paris, tratamos el rendimiento como una característica. Un sitio de lujo lento es una contradicción en los términos.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

1. Pintura con contenido más grande (LCP): la fecha límite de 2,5 segundos

Medidas LCP Rendimiento de carga. Detiene el reloj cuando se representa el elemento visible más grande (normalmente la imagen principal o el texto de bloqueo H1). Objetivo: < 2,5 segundos.

La física de LCP

LCP es una carrera contra cuatro subpartes:

TTFB (Tiempo hasta el primer byte): Tiempo de respuesta del servidor.
Retraso en la carga de recursos: tiempo hasta que el navegador descubre la URL de la imagen.
Tiempo de carga de recursos: Tiempo para descargar la imagen.
Retraso de renderizado de elementos: Es hora de pintar píxeles.

Cómo solucionarlo (Estrategia Next.js)

1. No cargues perezosamente al héroe A los desarrolladores les encanta loading="lazy". Pero si lo coloca en Hero Image, el navegador espera hasta que analiza la etiqueta <img> para comenzar a descargar. Debe Cargar con impaciencia el candidato a LCP.

// Malo
<Image src="/hero.jpg" cargando="perezoso" />

// Bueno (Siguiente.js)
<Imagen src="/hero.jpg" prioridad={true} />

2. Precargar recursos críticos Dígale al navegador en <head>: “Necesitará esta fuente y esta imagen de inmediato”.

<enlace rel="precarga" href="/hero.webp" as="imagen" />
<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin />

3. Usar formato AVIF WebP es bueno. AVIF es mejor (20% más pequeño). Asegúrese de que su CDN admita la negociación de contenido.

2. Cambio de diseño acumulativo (CLS): el índice de estabilidad

CLS mide Estabilidad visual. Calcula cuánto contenido cambia inesperadamente. Objetivo: < 0,1.

Escenario: El usuario intenta hacer clic en “Pagar”. Se carga un anuncio encima del botón. El contenido empuja hacia abajo. En su lugar, el usuario hace clic en “Cancelar”. Este es un patrón oscuro, aunque sea accidental.

El problema: relaciones de aspecto

Si incluyes una imagen sin dimensiones: <img src="foto.jpg" /> El navegador no conoce la altura hasta que se descarga la imagen. Representa una altura de 0 px y luego salta a 500 px.

Solución: Reserva siempre espacio. La “relación de aspecto” de CSS es tu amiga.

.hero-envoltorio {
  relación de aspecto: 16/9;
  fondo: #f0f0f0; /* Color del marcador de posición */
}

El cambio de fuente (FOIT/FOUT)

Las fuentes personalizadas tardan en cargarse. Si el navegador oculta el texto hasta que se carga la fuente (FOIT), aparece un destello. Si el navegador muestra una fuente alternativa (Arial) y luego intercambia (Inter), el ancho cambia. Los saltos de línea cambian. Cambios de diseño.

Solución: use font-display: opcional o coincida con métricas. Usamos @next/font que alinea automáticamente las métricas de fuentes alternativas para evitar cambios en el diseño.

3. El costo de las fuentes pesadas

A los diseñadores les encantan las fuentes. Los ingenieros les temen. Un peso único de Circular Std es 30 KB (WOFF2). Si carga Regular, Negrita, Cursiva, Negro -> 120 KB. Esto bloquea la representación del texto (FOIT). Estrategia:

Subconjunto: No necesitas caracteres griegos/cirílicos. Subconjunto de Latin-1. (Ahorra 50%).
Fuentes variables: utilice un archivo (Inter-Variable.woff2) que contenga todos los pesos. Maneja mejor la animación.
Autoanfitrión: elimine el protocolo de enlace TLS para fonts.googleapis.com.

4. Aplazar CSS no crítico

Tailwind es genial porque es pequeño (10 KB). Pero los proyectos antiguos de Sass suelen tener “main.css” (500 KB). El navegador detiene el procesamiento hasta que se descarga main.css. Solución: extraiga “CSS crítico” (estilos para el encabezado/héroe) e inclúyalo en <head>. Cargue el resto de forma asíncrona: <link rel="stylesheet" href="main.css" media="print" onload="this.media='all'"> Este truco aumenta el LCP en aproximadamente 1 segundo en redes 3G.

5. Interacción con la siguiente pintura (INP): la capacidad de respuesta

Nota: INP reemplazó a FID (Retraso de primera entrada) en marzo de 2024.

INP mide Latencia de eventos. “Cuando hago clic en el botón Menú, ¿cuántos milisegundos faltan para que se abra realmente el menú?” Objetivo: < 200 milisegundos.

El culpable casi siempre es El hilo principal. JavaScript es de un solo subproceso. Si el navegador está ocupado analizando un enorme paquete de hidratación de 5 MB y haces clic en “Menú”, el navegador dice: “Espera, estoy ocupado”. La interfaz de usuario se congela.

Estrategias para arreglar el INP

1. Rendimiento al hilo principal Divida las tareas largas. Si está iterando más de 10.000 elementos, hágalo en partes.

// Bloqueo
artículos.forEach(proceso);

// Sin bloqueo (cediendo)
función asíncrona procesoAsync() {
  para (elemento constante de elementos) {
    aguarde el planificador.postTask(() => proceso(elemento));
  }
}

2. Reaccionar usoTransición En React 18, use useTransition para marcar las actualizaciones como no urgentes. Esto le dice a React: “Si el usuario hace clic, interrumpa este trabajo de renderizado para manejar el clic”.

const [está Pendiente, iniciarTransición] = useTransition();

función seleccionarTab(siguienteTab) {
  iniciarTransición(() => {
    setTab(siguienteTab);
  });
}

4. Medición: datos de campo versus datos de laboratorio

Los desarrolladores viven en Lab Data (Lighthouse en una MacBook rápida). Google vive en Datos de campo (CrUX - Informe de experiencia del usuario de Chrome). CrUX recopila datos reales de usuarios reales (a menudo en teléfonos Android lentos).

Tu puntuación de Lighthouse podría ser 100. Pero si su usuario P75 (percentil 75) tiene una conexión lenta, su puntuación CrUX podría ser “pobre”. Optimice siempre para el usuario de P75 en 4G.

5. Impacto de terceros

¿Quién está acabando con tus Web Vitals? Generalmente:

Widgets de chat (Intercom/Drift): paquetes enormes.
Píxeles de seguimiento: Bloqueo del hilo principal.
Herramientas de prueba A/B (optimizadas): oculta el contenido del cuerpo para una experiencia “sin parpadeos” (elimina LCP).

Solución: muévalos a Web Workers usando Partytown. (Consulte Tamaño del paquete).

6. API de reglas de especulación (prerenderizado)

Ésta es la opción nuclear para la velocidad. Puedes indicarle a Chrome que represente la siguiente página en segundo plano antes de que el usuario haga clic. No solo descargue el HTML. Ejecuta el JS y Pinta los Píxeles. Cuando hacen clic, la transición es 0ms. Instante.

{
  "prerenderizar": [
    {
      "fuente": "lista",
      "url": ["/página siguiente", "/carrito"]
    }
  ]
}

Usamos esto para el flujo “Agregar al carrito” -> “Pagar”. Parece una aplicación nativa.

7. Navegaciones suaves y CWV

En una aplicación de una sola página (Next.js), navegar desde Inicio a la página del producto es una Navegación suave. Anteriormente, Core Web Vitals los ignoraba en gran medida. En 2024, Google actualizó las métricas para rastrear “INP en navegaciones suaves”. Si su transición JS tarda 500 ms en recuperar JSON y representar la nueva página, está fallando en LCP/INP. Solución: utilice la interfaz de usuario optimista. Muestra un esqueleto inmediatamente. No espere a que se complete await fetch() antes de cambiar la URL.

9. Monitoreo de usuarios reales (RUM)

Lighthouse es una “prueba de laboratorio”. Funciona en un ambiente limpio. Los usuarios reales tienen Spotify ejecutándose en segundo plano y 50 pestañas abiertas. Necesitas RON. Usamos Vercel Analytics (o SpeedCurve). Realiza un seguimiento de los signos vitales de los visitantes reales. Si tu LCP es 1.2s en iPhone 15 pero 4.5s en iPhone 11, RUM te lo indica. Los datos de laboratorio mienten. Los datos de campo detectan fugas de ingresos.

10. ¿Por qué Código Maison?

En Maison Code, somos extremistas del rendimiento. No nos limitamos a “minimizar CSS”. Diseñamos para Zero-Layout-Shift e Instant-Interaction. Sabemos que para las marcas de lujo, “lento” = “barato”. Auditamos todo su stack, desde Edge CDN hasta React Hydration. Ofrecemos sitios que parecen nativos, incluso en redes 4G del tercer mundo. Porque 100 ms de latencia = 1% de caída de ingresos (Estudio de Amazon).

12. La diferencia entre OTC e INP

El tiempo total de bloqueo (TBT) es una métrica de laboratorio. La interacción con la siguiente pintura (INP) es una métrica de campo. TBT predice INP. Si su TBT es alto (>200 ms), es probable que su INP sea deficiente. Bucle de optimización:

Ejecute Lighthouse (medir TBT).
Optimizar la hidratación.
Implementar.
Espere 28 días para obtener datos de CrUX (medir INP).
Repita. No esperes 28 días para saber si lo solucionaste. Utilice TBT como su proxy.

13. Conclusión

Core Web Vitals no son solo métricas. Son representantes del respeto. Respetando el tiempo de su usuario. Respetando la batería de su dispositivo. Google simplemente está imponiendo buenos modales. Si tratas bien al usuario, Google te trata bien.

¿Su sitio es lento?

¿Su Search Console muestra “URL deficientes”? Realizamos auditorías de rendimiento profundas para solucionar el problema de la hidratación. Contrate a nuestros arquitectos.