Core Web Vitals para webs de marketing

Para aprobar las Core Web Vitals, una web de marketing debe mostrar su contenido principal en 2,5 segundos, responder a cada toque o clic en 200 milisegundos y casi no mover el diseño. Son los umbrales «buenos» de LCP, INP y CLS. Los problemas suelen venir de los mismos sitios: multimedia pesada en la cabecera, etiquetas de terceros, banners de cookies y fuentes que cargan tarde.

En esta guía explicamos cada métrica en términos sencillos, mostramos dónde suelen perder puntos las webs de marketing y enumeramos las correcciones que aplicamos en proyectos con Next.js.

¿Qué son las Core Web Vitals y por qué fallan las webs de marketing?

Las Core Web Vitals son tres métricas con las que Google describe la experiencia real en una página. Se miden con visitas reales en Chrome y se evalúan en el percentil 75, es decir, tres de cada cuatro visitas deben cumplir el umbral.

• Largest Contentful Paint (LCP) mide la carga. Registra cuándo termina de pintarse el elemento visible más grande, normalmente la imagen o el titular de cabecera. Bueno es 2,5 segundos o menos.
• Interaction to Next Paint (INP) mide la capacidad de respuesta: cuánto tarda la página en reaccionar visiblemente a clics, toques y teclas durante toda la visita. Bueno es 200 milisegundos o menos. INP sustituyó a First Input Delay como Core Web Vital en marzo de 2024.
• Cumulative Layout Shift (CLS) mide la estabilidad visual. Suma los movimientos inesperados del contenido mientras la página está abierta. Bueno es 0,1 o menos.

La introducción a Web Vitals en web.dev, de Google, define cada una en detalle.

Las webs de marketing fallan por un motivo concreto. A menudo las construye un equipo de diseño y luego las amplía el de marketing. Cada campaña añade una etiqueta, un widget o un vídeo de cabecera más grande. Cada añadido parece pequeño. Juntos, llevan la página más allá del límite.

¿Afectan las Core Web Vitals al posicionamiento? Forman parte de las señales de experiencia de página que usan los sistemas de Google, pero la relevancia y la calidad del contenido pesan mucho más. El motivo de peso es otro: las páginas lentas y que se mueven pierden visitantes antes de que lean tu propuesta.

Datos de campo y de laboratorio: mide lo correcto

Hay dos tipos de medición, y a menudo no coinciden.

• Los datos de campo proceden de usuarios reales a través del Chrome User Experience Report. Son los que muestra el informe de Core Web Vitals de Search Console. Reflejan dispositivos y redes reales, y se actualizan en una ventana móvil de 28 días.
• Los datos de laboratorio salen de una prueba en condiciones controladas, como Lighthouse o la parte de laboratorio de PageSpeed Insights. Sirven para depurar, porque puedes repetir la prueba tras cada cambio.

Un 98 en Lighthouse con un portátil rápido no significa que tus visitantes con móviles de gama media estén bien. Usa el laboratorio para encontrar y corregir problemas. Usa los datos de campo para confirmar que la corrección funcionó.

Las páginas con poco tráfico pueden no tener datos de campo propios. En ese caso, Search Console las agrupa con páginas similares, y puedes añadir tu propia monitorización de usuarios reales.

Cómo corregir el LCP: la cabecera suele ser el problema

En casi todas las páginas de marketing, el elemento LCP es la imagen de cabecera, el póster del vídeo o el titular principal. Las soluciones son conocidas:

1. Sirve la imagen con el tamaño y el formato adecuados. En Next.js, next/image genera tamaños responsive y formatos modernos. Define el atributo sizes para que un móvil no descargue la imagen de escritorio.
2. Dale prioridad. Marca la imagen de cabecera con priority para que se precargue, y nunca uses carga diferida en lo que se ve al abrir la página.
3. Evita sliders y vídeo en reproducción automática. Un carrusel retrasa el elemento LCP real y añade JavaScript. Una imagen fija o un titular potente suelen comunicar mejor de todos modos. En nuestro artículo sobre el diseño de la home de un SaaS repasamos patrones de cabecera que funcionan sin ellos.
4. Renderiza en el servidor. Con React Server Components, el HTML de la cabecera llega completo. El navegador no espera al JavaScript para montar la página.
5. Reduce las peticiones que bloquean el renderizado. Incluye el CSS crítico en línea, aloja tú las fuentes y elimina hojas de estilo innecesarias de widgets de terceros.

Si el elemento LCP es texto, depende de las fuentes. Si el titular espera a una fuente web, el LCP también. Lo vemos más abajo.

Cómo corregir el INP: scripts de terceros y JavaScript pesado

Los problemas de INP aparecen cuando el hilo principal está ocupado justo cuando el usuario interactúa. En las webs de marketing, el culpable no suele ser tu propio código:

• Gestores de etiquetas que cargan varios píxeles de analítica y publicidad.
• Widgets de chat que cargan una aplicación completa en cada página.
• Herramientas de test A/B que ocultan la página hasta que su script decide qué mostrar.
• Librerías de animación pesadas con efectos de scroll en cada fotograma.
• Formularios de terceros incrustados que traen sus propios frameworks.

Lo que funciona:

• Revisa cada etiqueta. Pregunta, para cada script, quién usa sus datos y cuándo los miró por última vez. Elimina lo que no tenga un responsable claro.
• Carga más tarde. En Next.js, next/script con lazyOnload o afterInteractive saca de la ruta crítica los scripts que no son esenciales.
• Carga cuando haya intención. Muestra un botón de chat ligero y carga el widget completo solo cuando alguien lo pulse.
• Envía menos JavaScript al cliente. Mantén la mayoría de los componentes como Server Components y deja como componentes de cliente solo las partes interactivas.
• Divide las tareas largas. Un manejador de eventos debe hacer lo mínimo antes del siguiente pintado y aplazar el resto.

Menos scripts de terceros también facilitan la seguridad. Cada uno es otro origen en tu Content Security Policy, como explicamos en nuestro checklist de seguridad web.

Cómo corregir el CLS: banners, fuentes y elementos incrustados

El desplazamiento de diseño ocurre cuando algo aparece o cambia de tamaño después de que el contenido de alrededor ya se ha pintado.

• Banners de cookies. Muéstralos como una capa fija en la parte inferior de la pantalla, no como un bloque que empuja la página hacia abajo.
• Imágenes y vídeos sin dimensiones. Define siempre ancho y alto, o una relación de aspecto, para que el navegador reserve el espacio.
• Fuentes web. Una fuente de respaldo con otras métricas hace que el texto se recoloque cuando llega la fuente web. next/font aloja las fuentes y ajusta las métricas de la de respaldo, lo que elimina casi todo ese salto.
• Incrustaciones y anuncios. Reserva un contenedor de tamaño fijo para mapas, vídeos y formularios de terceros.
• Avisos y barras tardías. Las barras promocionales que se insertan arriba después de la carga son una causa frecuente. Renderízalas en el servidor o resérvales espacio.

Checklist de Core Web Vitals para tu web de marketing

Úsalo antes del lanzamiento y después de cada campaña importante:

• Imagen de cabecera servida con next/image, con sizes y priority correctos.
• Ningún carrusel ni vídeo automático en la primera pantalla.
• Fuentes alojadas con next/font, con un máximo de dos familias.
• Dimensiones reservadas para cada imagen, vídeo e incrustación.
• Banner de cookies como capa fija.
• Inventario de etiquetas revisado, con un responsable por script.
• Scripts no esenciales cargados con lazyOnload o por acción del usuario.
• La mayoría de los componentes renderizados en el servidor.
• Pruebas de laboratorio aprobadas con un perfil de móvil de gama media y red limitada.
• Datos de campo de Search Console revisados 28 días después del lanzamiento.

El rendimiento es más fácil de mantener que de recuperar. Un presupuesto corto acordado con marketing, como «ningún script de terceros nuevo sin revisión», protege el trabajo después del lanzamiento.

Siguiente paso: una web de marketing que siga siendo rápida

Nuestro diseño de landing page empieza en 5000 $ por una web de una sola página con 8 secciones, con 2 rondas de revisión y un plazo habitual de 1-2 semanas. Para una web de marketing de varias páginas, la web corporativa parte de 8500 $. Desarrollamos con Next.js, los presupuestos de rendimiento forman parte del desarrollo y comprobamos las Core Web Vitals en cada plantilla clave antes del lanzamiento.

Si dudas entre un constructor visual y un desarrollo a medida, nuestra comparativa entre Webflow y desarrollo a medida explica dónde cada opción facilita o complica el rendimiento.