Optimizar LCP, INP y CLS: guía práctica de rendimiento web

Hay una conversación que se repite en el estudio cada pocas semanas. Alguien nos enseña una captura de PageSpeed Insights con un 42 en rojo y nos pregunta qué hay que hacer para llegar a 100. Mi respuesta casi siempre empieza por desplazar la pantalla hacia arriba, hasta los datos de campo. Muchas veces esa web aprueba las tres métricas con usuarios reales y la nota roja es la de un móvil simulado en condiciones muy duras. Otras veces no, y entonces sí toca trabajar, pero sabiendo exactamente dónde.

Optimizar el rendimiento es sobre todo un ejercicio de diagnóstico. Las tres Core Web Vitals miden cosas distintas (cuánto tarda en aparecer lo importante, cuánto tarda la web en responder y cuánto se mueve mientras carga), y cada una tiene sus causas y sus soluciones. Aplicar técnicas al azar suele dar poco; ir a la causa concreta suele dar mucho con muy poco cambio.

Si quieres la explicación general de qué son y por qué importan para el negocio, la tienes en qué son los Core Web Vitals. Aquí nos ponemos el mono de trabajo.

01Los objetivos y dónde medirlos

Google evalúa cada métrica en el percentil 75 de las visitas reales: una página aprueba si al menos tres de cada cuatro visitas tienen una experiencia buena.

Datos de campo y datos de laboratorio

• →Campo (lo que cuenta). Datos de visitantes reales de Chrome, recogidos en el informe CrUX (Chrome User Experience Report) durante 28 días. Los ves en la parte superior de PageSpeed Insights y en el informe de Core Web Vitals de Search Console.
• →Laboratorio (lo que ayuda a diagnosticar). Lighthouse, el panel Performance de Chrome DevTools o WebPageTest simulan una carga en condiciones controladas. Son perfectos para encontrar la causa, pero no sustituyen a los datos reales. Ojo: el laboratorio no mide INP, porque no hay nadie haciendo clic; su indicador aproximado es el TBT (Total Blocking Time).

Si tu web no tiene tráfico suficiente para aparecer en CrUX, puedes recoger tus propios datos de campo con la librería web-vitals de Google, enviándolos a tu analítica. Su versión con atribución te dice, además, qué elemento fue el LCP o qué interacción tuvo el peor INP.

02LCP: que lo importante aparezca pronto

El elemento LCP suele ser la imagen principal del hero, un vídeo de portada o el titular grande. Para mejorarlo, lo más útil es dividir su tiempo en las cuatro fases que propone el equipo de Chrome en web.dev:

1. 01TTFB (Time to First Byte): lo que tarda el servidor en empezar a responder.
2. 02Retraso de carga del recurso: desde ese primer byte hasta que el navegador empieza a descargar la imagen del LCP.
3. 03Duración de carga del recurso: lo que tarda en descargarse esa imagen.
4. 04Retraso de renderizado: desde que la imagen está descargada hasta que se pinta.

En una página bien optimizada, la mayor parte del tiempo se va en el TTFB y en la descarga, y los dos retrasos son casi cero. El panel Performance de Chrome DevTools muestra este desglose para el LCP de cualquier página.

Cómo mejorar cada fase

• →TTFB alto (más de 0,8 s): caché de página completa en el servidor o en una CDN, generación estática de las páginas que cambian poco, un hosting más cercano a tus usuarios y menos redirecciones encadenadas. Un certificado bien configurado con HTTP/2 o HTTP/3 también ayuda, como contamos en HTTPS y certificados SSL.
• →Retraso de carga: que la imagen del LCP sea descubrible en el HTML inicial, con un <img> real y no como fondo CSS o insertada por JavaScript. Y que tenga prioridad alta.
• →Duración de carga: formatos modernos (AVIF o WebP), tamaño ajustado con srcset y sizes, y servirla desde el mismo dominio o una CDN rápida. Lo explicamos en detalle en imágenes en la web.
• →Retraso de renderizado: menos CSS y JavaScript bloqueantes en el <head>, fuentes que no retengan el texto y sin animaciones de entrada que oculten el hero hasta que termina de cargar un script.

Así queda una imagen de hero preparada para un buen LCP:

<img
  src="/img/hero-1200.avif"
  srcset="/img/hero-800.avif 800w, /img/hero-1200.avif 1200w, /img/hero-1800.avif 1800w"
  sizes="100vw"
  width="1800" height="1000"
  alt="Terraza del restaurante al atardecer"
  fetchpriority="high"
  decoding="async">

Dos detalles que vemos a menudo: la imagen del hero con loading="lazy" (la carga diferida retrasa justo la imagen que más importa; resérvala para lo que está por debajo del primer pantallazo) y el hero animado que empieza con opacidad cero y espera a una librería de animación para aparecer. Un hero con carácter y un buen LCP son perfectamente compatibles cuando la animación acompaña a una imagen que ya está pintada.

03INP: que la web responda en cuanto la tocas

El INP mide el tiempo desde que alguien hace clic, toca o pulsa una tecla hasta que la pantalla muestra la respuesta. Se compone de tres partes:

• →Retraso de entrada: el navegador está ocupado con otra cosa y tarda en atender el clic.
• →Tiempo de procesamiento: lo que tarda en ejecutarse el código asociado a esa interacción.
• →Retraso de presentación: lo que tarda el navegador en recalcular estilos, maquetar y pintar el resultado.

Casi todo se reduce a una idea: el hilo principal del navegador hace una cosa cada vez. Cualquier tarea de JavaScript que dure más de 50 ms (una tarea larga) bloquea las respuestas mientras se ejecuta.

Técnicas que funcionan

1. 01Inventaria los scripts de terceros. Chats, mapas de calor, píxeles y widgets son la primera causa de INP alto que encontramos. Retira los que no aportan y carga el resto de forma diferida.
2. 02Trocea las tareas largas. Divide el trabajo en partes y cede el control al navegador entre ellas, para que pueda atender clics por el camino.
3. 03Responde primero, calcula después. Actualiza la interfaz de inmediato (el botón cambia de estado, aparece el menú) y deja para después lo que no es visible: analítica, guardados, cálculos.
4. 04Reduce el tamaño del DOM. Páginas con muchos miles de nodos tardan más en recalcular estilos. content-visibility: auto ayuda en secciones largas por debajo del primer pantallazo.
5. 05En React, usa transiciones. useTransition marca como no urgentes las actualizaciones pesadas, como filtrar un listado, para que la escritura siga fluida.

Este es el patrón para ceder el hilo principal entre bloques de trabajo, con scheduler.yield() donde está disponible y una alternativa para el resto de navegadores:

<script>
  function ceder() {
    if (globalThis.scheduler?.yield) return scheduler.yield();
    return new Promise(r => setTimeout(r, 0));
  }
  async function alPulsarFiltro(items) {
    mostrarEstadoCargando();          // respuesta visual inmediata
    await ceder();
    for (const bloque of trocear(items, 50)) {
      filtrarYPintar(bloque);
      await ceder();                  // el navegador atiende otros clics
    }
    enviarAnalitica();                // lo no visible, al final
  }
</script>

El panel Performance de DevTools muestra las métricas en vivo mientras interactúas con la página e identifica la interacción más lenta. Simula una CPU 4 veces más lenta para acercarte a un móvil de gama media; los problemas de INP rara vez aparecen en un portátil potente. Para profundizar en el peso del código, tienes JavaScript y rendimiento.

04CLS: que nada se mueva sin permiso

El CLS mide cuánto saltan los elementos de la página de forma inesperada: el botón que baja justo cuando ibas a pulsarlo, el texto que se desplaza al cargar una imagen. Los cambios que ocurren en los 500 ms posteriores a una interacción del usuario no cuentan, porque se esperan.

Las causas más frecuentes y su solución:

• →Imágenes y vídeos sin dimensiones. Añade width y height en el HTML o un aspect-ratio en CSS. El navegador reserva el espacio antes de descargar el archivo.
• →Contenido que se inserta arriba. Banners de cookies, avisos o anuncios que empujan la página. Lo que funciona es superponerlos (fijos abajo, por ejemplo) o reservarles un hueco desde el principio.
• →Fuentes web que cambian de tamaño. Al sustituir la tipografía de reserva por la definitiva, el texto puede ocupar más o menos. Los descriptores size-adjust, ascent-override y descent-override igualan las métricas de la fuente de reserva con las de la definitiva.
• →Incrustados de terceros (mapas, vídeos, reseñas). Envuélvelos en un contenedor con altura mínima o proporción fija.
• →Animaciones con propiedades de maquetación. Anima transform y opacity en lugar de top, left, width o height.

.media { aspect-ratio: 16 / 9; width: 100%; height: auto; }
.mapa  { min-height: 360px; }
@font-face {
  font-family: "Marca Fallback";
  src: local("Arial");
  size-adjust: 104%;
  ascent-override: 92%;
  descent-override: 24%;
}
body { font-family: "Marca", "Marca Fallback", sans-serif; }

Los porcentajes de la tipografía de reserva dependen de cada fuente. Herramientas como Fontaine o la optimización de fuentes de Next.js los calculan automáticamente.

Clave: el rendimiento se diseña. Reservar el espacio de cada imagen, decidir qué se carga primero y qué puede esperar son decisiones de diseño tanto como de código.

05Ejemplo resuelto: la portada de un hotel boutique

Para aterrizar todo lo anterior, este es un caso típico de los que vemos. La portada de un hotel boutique en la costa tenía estos datos de campo en móvil: LCP de 4,1 s, INP de 340 ms y CLS de 0,22.

El diagnóstico, con DevTools y la librería web-vitals:

• →El LCP era una foto de 2,4 MB en JPG, aplicada como fondo CSS dentro de un carrusel que se iniciaba con JavaScript.
• →El INP peor estaba en el botón del motor de reservas, que cargaba un widget de terceros al pulsarlo, además de un chat y dos píxeles publicitarios que se ejecutaban en la carga.
• →El CLS venía del banner de cookies, insertado arriba, y de la tipografía de titulares.

Las soluciones, en orden:

1. 01Primera imagen del carrusel como <img> en el HTML, en AVIF con srcset, fetchpriority="high" y dimensiones fijas. El resto de imágenes, con carga diferida.
2. 02Caché de página en la CDN, que bajó el TTFB de 1,1 s a unos 200 ms.
3. 03El chat pasó a cargarse solo cuando el visitante pulsa su icono; los píxeles, cuando el navegador queda libre tras la carga.
4. 04El botón de reservas muestra al instante un estado de carga y precarga el widget cuando el cursor se acerca o el usuario hace scroll hasta esa sección.
5. 05Banner de cookies fijo en la parte inferior, superpuesto, y fuente de reserva ajustada con size-adjust.

Cuatro semanas después, los datos de campo mostraban un LCP de 2,0 s, un INP de 150 ms y un CLS de 0,03. El diseño no cambió ni un píxel; cambió el orden en que las cosas llegan a la pantalla.

06Checklist de rendimiento antes de publicar

• →La imagen o el texto del LCP está en el HTML inicial, con prioridad alta y sin carga diferida.
• →Imágenes en AVIF o WebP, con srcset, sizes, width y height.
• →TTFB por debajo de 0,8 s gracias a caché o generación estática.
• →CSS crítico ligero; JavaScript no esencial con defer o cargado bajo demanda.
• →Fuentes autoalojadas, con font-display: swap y métricas de reserva ajustadas.
• →Scripts de terceros inventariados y diferidos.
• →Ninguna tarea larga en las interacciones principales (menú, filtros, formularios).
• →Espacio reservado para banners, incrustados y anuncios.
• →Animaciones con transform y opacity.
• →Datos de campo vigilados en Search Console tras el lanzamiento.

En SIMA trabajamos el rendimiento desde el diseño: decidimos qué imagen protagoniza cada página, cómo entra la animación y qué scripts merecen un sitio antes de escribir una línea de código. Y lo seguimos midiendo cuando la web ya está publicada, dentro del desarrollo web que hacemos para nuestros clientes. Si tu web suspende alguna métrica y quieres saber por qué, escríbenos y lo diagnosticamos juntos.