SEO técnico
SEO técnico
Core Web Vitals: qué son LCP, INP y CLS y cómo mejorar cada uno
Los Core Web Vitals son tres métricas de Google medidas con usuarios reales: LCP (el elemento visible más grande carga en hasta 2,5 s), INP (la página responde a clics y toques en hasta 200 ms) y CLS (el contenido no se mueve más de 0,1). La evaluación usa el percentil 75 de los visitantes. Para mejorar: servidor e imagen principal rápidos para el LCP, menos JavaScript de terceros y tareas largas para el INP, dimensiones declaradas en imágenes y espacio reservado para embeds para el CLS. Pesan poco en el posicionamiento y mucho en la conversión.
En resumen
- Límites de "bueno": LCP hasta 2,5 s, INP hasta 200 ms, CLS hasta 0,1, medidos en el percentil 75 de usuarios reales.
- El INP sustituyó al FID en marzo de 2024 y es la métrica en la que más sitios fallan hoy.
- Usa el informe de Search Console para encontrar los grupos de URL con problemas y DevTools para encontrar la causa.
- LCP: servidor rápido e imagen principal con prioridad. INP: menos scripts de terceros. CLS: dimensiones declaradas.
- Es un factor de desempate en el posicionamiento; el efecto en la conversión es mayor y más directo.
Qué son los Core Web Vitals y los límites actuales
Los Core Web Vitals son las tres métricas que Google usa para resumir la experiencia de carga de una página con datos de usuarios reales. Cada una mide algo distinto, y el sitio tiene que pasar las tres para que la página se considere buena.
| Métrica | Qué mide | Bueno | Necesita mejorar | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que el elemento visible más grande (imagen, vídeo o bloque de texto) termina de renderizarse | hasta 2,5 s | 2,5 s a 4 s | más de 4 s |
| INP (Interaction to Next Paint) | Tiempo entre una interacción (clic, toque, tecla) y la siguiente actualización visible, tomando la peor interacción de la visita | hasta 200 ms | 200 ms a 500 ms | más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se mueve el contenido en pantalla sin que el usuario haya hecho nada | hasta 0,1 | 0,1 a 0,25 | más de 0,25 |
La evaluación se hace en el percentil 75: el 75% de las visitas debe quedar dentro del límite. No basta con que la media sea buena; lo que cuenta es la experiencia de los visitantes más lentos, que son justamente los de móvil y red móvil.
El INP sustituyó al FID (First Input Delay) el 12 de marzo de 2024. El FID medía solo el retraso de la primera interacción; el INP mide la respuesta a todas y reporta la peor. Por eso muchos sitios que pasaban el FID empezaron a fallar tras el cambio.
Datos de campo y de laboratorio: dónde medir
Hay dos tipos de medición, y confundirlos es la causa más común de diagnóstico equivocado:
- Campo (CrUX): datos recogidos de usuarios reales de Chrome que aceptaron compartir estadísticas. Es lo que Google usa para el posicionamiento y lo que aparece en el informe Core Web Vitals de Search Console y en la parte superior de PageSpeed Insights. Solo existe para páginas con tráfico suficiente.
- Laboratorio (Lighthouse): una prueba simulada en un dispositivo y una red estandarizados. Sirve para diagnosticar y reproducir problemas, pero no representa la base real de usuarios. La nota de 0 a 100 de PageSpeed es de laboratorio.
| Herramienta | Tipo de dato | Para qué sirve |
|---|---|---|
| Search Console, informe Core Web Vitals | Campo | Ver qué grupos de URL fallan, en móvil y en escritorio |
| PageSpeed Insights | Campo (arriba) y laboratorio (abajo) | Ver el estado real de una URL y las causas probables |
| Chrome DevTools, panel Performance | Laboratorio, en tu ordenador | Encontrar la interacción lenta y la tarea larga que la causó |
| Extensión Web Vitals de Chrome | Campo, en tu sesión | Ver las métricas en vivo mientras navegas |
| Biblioteca web-vitals + analítica | Campo, de tus usuarios | Recoger las métricas de todos los visitantes y segmentar por página y dispositivo |
Empieza siempre por el informe de Search Console: agrupa las URL con el mismo problema, y corregir la plantilla resuelve el grupo entero.
Cómo mejorar el LCP
El elemento LCP suele ser una imagen destacada, un banner o el título principal. Las causas más frecuentes de LCP malo, por orden de impacto:
- Servidor lento (TTFB alto). Nada se renderiza antes de que llegue el HTML. Caché de página, CDN y alojamiento adecuado resuelven la mayor parte. Un TTFB por encima de 800 ms ya compromete el LCP por sí solo.
- Imagen LCP descubierta tarde. Las imágenes cargadas por CSS (background-image) o por JavaScript solo se encuentran después de procesar esos archivos. Pon la imagen principal en el HTML con
<img>y marca la prioridad:fetchpriority="high". Nunca usesloading="lazy"en el elemento LCP. - Imagen pesada o en formato equivocado. Sírvela al tamaño mostrado, en WebP o AVIF, con
srcsetpara cada ancho de pantalla. - Recursos que bloquean el renderizado. CSS y JavaScript en el
<head>retrasan todo. Pon en línea el CSS crítico, difiere el resto y carga los scripts condefer. - Fuentes web. Si el LCP es un texto y la fuente tarda, el texto aparece tarde. Usa
font-display: swapy hazpreloadde las fuentes principales.
Un ejemplo de imagen principal preparada para el LCP:
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
<img src="/img/hero.webp" width="1200" height="630" alt="..." fetchpriority="high" decoding="async">Cómo mejorar el INP
El INP es el más difícil de los tres, porque depende de lo que pasa durante toda la visita, y no solo en la carga. Empeora cuando el hilo principal del navegador está ocupado en el momento en que el usuario interactúa. Las causas más comunes:
- JavaScript de terceros. Chats, píxeles, mapas de calor, widgets de reseñas y scripts del gestor de etiquetas compiten por el hilo principal. Cada uno es pequeño; juntos son el problema. Audita lo que se carga y elimina lo que no genera una decisión.
- Tareas largas. Cualquier bloque de JavaScript de más de 50 ms bloquea la respuesta a los clics. Divide el trabajo en partes menores y devuelve el control al navegador entre ellas (
scheduler.yield()osetTimeout). - Manejadores de eventos pesados. Un clic que dispara cálculo, renderizado y envío de datos a la vez tarda en mostrar cualquier respuesta. Actualiza la pantalla primero y haz el resto después.
- DOM muy grande. Las páginas con decenas de miles de elementos hacen que cada actualización de diseño cueste más. Paginación, virtualización de listas y menos anidamiento ayudan.
- Hidratación de frameworks. En sitios hechos con React, Vue o similares, la página puede parecer lista y aún no responder porque el JavaScript está "hidratando" los componentes. El renderizado en servidor con hidratación parcial reduce el problema.
Para encontrar la interacción lenta: en Chrome DevTools, graba la sesión en el panel Performance, interactúa con la página y busca las tareas marcadas en rojo. El panel muestra qué script estaba corriendo en el momento del clic.
Cómo mejorar el CLS
El CLS es el más fácil de corregir, porque las causas son pocas y conocidas:
- Imágenes y vídeos sin dimensiones. Sin
widthyheighten el HTML, el navegador no reserva espacio y el contenido salta cuando carga el medio. Declara siempre las dimensiones o usaaspect-ratioen CSS. - Anuncios, embeds e iframes. Reserva un espacio fijo para el contenedor antes de que llegue el contenido.
- Fuentes que cambian. La fuente del sistema se sustituye por la fuente web y el texto cambia de tamaño.
font-display: optionalo el ajuste de métricas consize-adjustminimizan el cambio. - Contenido inyectado arriba. Avisos de cookies, banners y barras que aparecen después de la carga y empujan todo hacia abajo. Posiciónalos con
position: fixedo reserva el espacio. - Animaciones que cambian el diseño. Animar
top,heightomarginprovoca desplazamiento. Animartransformyopacityno.
El CLS se mide durante toda la visita, incluidos los desplazamientos. Una página estable en la carga puede tener un CLS malo por un elemento que aparece a mitad de lectura.
Cuánto pesa esto en el posicionamiento
Los Core Web Vitals forman parte de las señales de experiencia de página, y Google es explícito al decir que son un factor de desempate entre páginas de contenido equivalente, no un factor dominante. Un sitio lento con el mejor contenido sigue ganando a un sitio rápido con contenido flojo.
Eso no los vuelve irrelevantes. Tres razones para tomarlos en serio: en mercados disputados, el desempate decide posiciones; Búsqueda y Discover usan el rendimiento como criterio de elegibilidad para algunas funciones; y el efecto en la conversión es directo y medible, independientemente del posicionamiento. Una tienda con un LCP de 5 segundos pierde ventas en cualquier posición.
El error contrario también existe: pasar meses optimizando vitals en un sitio que no posiciona por falta de contenido o por un bloqueo de indexación. En ese caso el problema es otro, y es lo primero que una auditoría SEO debe separar.
Checklist por plataforma
| Plataforma | Causa más común | Corrección típica |
|---|---|---|
| WordPress | Exceso de plugins, tema pesado, sin caché | Caché de página, quitar plugins redundantes, optimizar imágenes, tema ligero; revisar alojamiento |
| Shopify y otras tiendas SaaS | Apps que inyectan scripts, temas con muchas funciones | Quitar apps sin uso (dejan código), reducir secciones del tema, imágenes al tamaño correcto |
| Sitios en React, Vue y Next | Hidratación pesada, bundles grandes, INP alto | Renderizado en servidor, división de código, hidratación parcial, menos JavaScript en el cliente |
| Sitio institucional estático | Imágenes pesadas, fuentes, scripts de terceros | Formatos modernos, preload de fuentes, cargar terceros después de la interacción |
| Cualquier plataforma | Gestor de etiquetas con decenas de etiquetas | Auditoría de etiquetas: cada una tiene que justificar su existencia |
Si el sitio está en un rediseño, ese es el momento de decidir estas cosas antes de construir, no de corregirlas después. Así tratamos el SEO técnico y el diseño web: la velocidad es un requisito del proyecto.