Search Console marca tus URLs como Deficientes o Necesitan mejorar en Core Web Vitals. Corres PageSpeed Insights y la puntuación cambia en cada prueba. El informe nombra una métrica, como «Problema de INP: más de 200 ms», pero no te dice qué cambiar.
Las Core Web Vitals son tres mediciones tomadas de usuarios reales de Chrome. Largest Contentful Paint (LCP) mide la carga. Interaction to Next Paint (INP) mide qué tan rápido responde la página a clics, toques y teclas. Cumulative Layout Shift (CLS) mide cuánto brinca el diseño. El INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024, así que los consejos viejos sobre FID ya no aplican.
Corregirlas es un ciclo. Identificas qué métrica falla y en qué plantilla, encuentras la causa concreta, publicas el cambio y esperas a que los datos de campo se actualicen. Esta guía sigue ese ciclo con las herramientas gratuitas de Google.
Respuesta rápida
- En Search Console, abre Core Web Vitals, empieza por Móvil y anota qué métrica falla en qué grupo de URLs.
- Analiza una URL de ejemplo en PageSpeed Insights. Confía en los datos de campo para saber si aprueba y usa los de laboratorio para encontrar causas.
- Para el LCP: haz que la imagen o el texto principal cargue pronto, nunca le pongas carga diferida y reduce el tiempo de servidor y los archivos que bloquean el renderizado.
- Para el INP: encuentra la interacción lenta, divide las tareas largas de JavaScript y recorta scripts de terceros.
- Para el CLS: reserva espacio a imágenes, inserciones y anuncios, y deja de insertar contenido arriba de lo que la gente está leyendo.
- Publica el cambio en toda la plantilla, haz clic en Validar corrección en Search Console y deja pasar la ventana de 28 días.
Antes de empezar
Esto es lo que necesitas:
- Acceso a la propiedad de Search Console (cualquier permiso puede ver el informe; validar requiere Propietario o Usuario con permiso total).
- Google Chrome con DevTools para las pruebas.
- Alguien que pueda modificar plantillas, configuración de imágenes, scripts y la configuración del servidor o la CDN.
- Un sitio de pruebas o una forma de revertir cambios. Las mejoras de rendimiento pueden romper diseños o la medición.
Conoce los umbrales antes de empezar. Google mide cada métrica en el percentil 75 de las visitas, por separado en móvil y en computadora.
| Métrica | Buena | Necesita mejorar | Deficiente |
|---|---|---|---|
| LCP | 2.5 s o menos | Hasta 4 s | Más de 4 s |
| INP | 200 ms o menos | Hasta 500 ms | Más de 500 ms |
| CLS | 0.1 o menos | Hasta 0.25 | Más de 0.25 |
Una página aprueba las Core Web Vitals solo si las tres son buenas en el percentil 75.
Paso 1: Ubica la métrica y la plantilla que fallan en Search Console
En Search Console, abre Experiencia > Core Web Vitals. Verás dos gráficas: Móvil y Ordenador. Haz clic en Abrir informe junto a Móvil primero. La mayoría de los sitios tiene más tráfico móvil y resultados móviles más lentos.
- Haz clic en la fila del problema para ver los grupos de URLs que lo tienen.
El informe agrupa URLs que se comportan igual, normalmente páginas construidas con la misma plantilla. Cada grupo toma el estado de su peor métrica. Haz clic en un grupo para ver una URL de ejemplo y el valor del grupo en esa métrica.
Anota tres cosas por cada problema:
- La métrica (LCP, INP o CLS).
- La plantilla del grupo, como entradas de blog, páginas de producto o el inicio.
- Una URL de ejemplo.
Si una página no aparece, seguramente no tiene suficientes datos de usuarios reales. Search Console solo muestra URLs y grupos con suficiente tráfico de Chrome, y solo URLs indexadas.
Paso 2: Lee PageSpeed Insights de la forma correcta
Entra a PageSpeed Insights (pagespeed.web.dev), pega la URL de ejemplo y haz clic en Analizar. Los resultados tienen dos partes muy distintas.
- Datos de campo. Vienen del Chrome UX Report: visitas reales de los últimos 28 días. Definen si apruebas y coinciden con lo que usa Search Console.
- Datos de laboratorio. Es una sola carga simulada con Lighthouse. Úsala para encontrar causas, no para medir el éxito.
Unas reglas que te ahorran horas:
- La puntuación de Rendimiento no es una Core Web Vital. Una página puede sacar 60 y aprobar, o sacar 90 y reprobar por INP.
- Las pruebas de laboratorio no miden el INP, porque nadie hace clic en nada. El Total Blocking Time es la pista de laboratorio más cercana.
- Si la pestaña Esta URL no tiene datos, cambia a Origen para ver todo el sitio.
- Los datos de campo cambian despacio. Son una ventana móvil de 28 días, así que un cambio publicado hoy muestra su efecto completo unas cuatro semanas después.
Baja hasta los diagnósticos. En las versiones recientes de Lighthouse aparecen como Insights (estadísticas), con nombres como LCP breakdown, LCP request discovery, Render-blocking requests y Layout shift culprits. Pueden cambiar de nombre entre versiones o aparecer traducidos, pero cada uno apunta a una causa concreta.
Paso 3: Corrige el LCP (carga lenta)
Primero identifica el elemento LCP. En PageSpeed Insights, abre el insight LCP breakdown (en informes antiguos se llama «Elemento de Largest Contentful Paint»). Casi siempre es una imagen principal, un encabezado grande o una imagen de fondo.
El tiempo de LCP se divide en cuatro partes. Cada una tiene su propia solución.
| Parte | Qué significa | Solución habitual |
|---|---|---|
| Time to First Byte | El servidor tarda en enviar el HTML | Caché, CDN, menos redirecciones, mejor hosting |
| Retraso de carga del recurso | El navegador encuentra tarde la imagen | Ponla en el HTML, precárgala, agrega fetchpriority |
| Duración de carga del recurso | La imagen pesa mucho | Redimensiona, comprime, usa AVIF o WebP |
| Retraso de renderizado | Algo bloquea el pintado | Menos CSS y JS que bloqueen el renderizado |
Haz que la imagen LCP cargue pronto
El problema más común es una imagen principal que el navegador descubre tarde. Pasa cuando es un fondo de CSS, cuando la inserta JavaScript o cuando tiene carga diferida.
<!-- Bien: en el HTML, prioridad alta, sin carga diferida -->
<img src="/img/hero-1200.avif"
width="1200" height="630"
fetchpriority="high"
alt="Equipo revisando la auditoría de un sitio web">
<!-- Si la imagen es un fondo de CSS, precárgala en el <head> -->
<link rel="preload" as="image" href="/img/hero-1200.avif" fetchpriority="high">
Nunca pongas loading="lazy" en la imagen LCP. Muchos temas y plugins aplican carga diferida a todas las imágenes, incluida la primera. Excluye la imagen principal. Usa fetchpriority="high" en una o dos imágenes como máximo.
Reduce el archivo
Sirve la imagen en un tamaño cercano al que se muestra. Una foto de 3000 píxeles mostrada a 800 desperdicia casi toda la descarga. Usa srcset para que los celulares reciban un archivo más chico, y usa AVIF o WebP.
Reduce el tiempo de servidor
Si Document request latency o el TTFB son altos, revisa el servidor antes que cualquier otra cosa:
- Activa la caché de página completa o la caché en el borde de tu CDN.
- Elimina saltos de redirección. Enlaza directo a la URL final.
- Evita parámetros que se salten la caché, como parámetros de seguimiento únicos en enlaces internos.
Quita lo que bloquea el renderizado
Los archivos CSS grandes y los scripts síncronos en el <head> retrasan el primer pintado. Difiere los scripts que no hacen falta para mostrar la parte superior. Elimina CSS sin uso. Haz que el administrador de etiquetas y los widgets de chat no bloqueen el renderizado. Si cargas etiquetas con Google Tag Manager, nuestra guía para instalar Google Tag Manager explica el fragmento asíncrono estándar.
Paso 4: Corrige el INP (respuesta lenta a clics y toques)
El INP revisa las interacciones de una página y reporta una de las más lentas. Cada interacción tiene tres fases:
- Retraso de entrada: el navegador está ocupado con otra cosa cuando el usuario toca.
- Duración del procesamiento: tus controladores de eventos tardan en ejecutarse.
- Retraso de presentación: el navegador tarda en pintar el resultado.
Encuentra la interacción lenta
Abre la página en Chrome. Abre DevTools y luego el panel Performance (Rendimiento). Las versiones recientes de Chrome muestran ahí los valores en vivo de LCP, CLS e INP mientras usas la página. Abre el menú, despliega acordeones, agrega al carrito, envía formularios. Observa qué interacción sube el INP.
- El INP en vivo de tu sesión. Se pone rojo cuando pasa de 500 ms.
- El registro de interacciones muestra qué elemento fue lento.
Luego haz clic en Grabar, repite la interacción lenta y detén la grabación. En el trace, las tareas largas llevan una esquina roja. Ábrelas para ver qué script se ejecutó. El insight INP breakdown muestra las tres fases de esa interacción.
Para datos de campo de usuarios reales, la librería abierta de JavaScript web-vitals puede enviar a tu analítica el elemento y la fase lentos. Así sabes qué interacciones fallan en celulares reales, no solo en tu laptop.
Correcciones comunes del INP
- Divide las tareas largas. Si un clic dispara mucho trabajo, haz primero la actualización visible y cede el hilo principal antes del resto.
- Pospón lo que no es urgente. Eventos de analítica, registros y recálculos pueden correr después del siguiente pintado.
- Recorta scripts de terceros. Widgets de chat, mapas de calor, herramientas de pruebas A/B y algunas configuraciones de etiquetas ejecutan código pesado en cada interacción. Revisa el insight Third parties. Quita las etiquetas que ya no usas.
- Mantén el DOM pequeño. Las páginas enormes vuelven lenta cada actualización de estilos y diseño. El insight Optimize DOM size lo señala.
- Evita forzar el diseño. Leer medidas (como
offsetHeight) justo después de cambiar estilos obliga al navegador a recalcular. El insight Forced reflow indica el código responsable.
// Muestra el resultado primero y cede antes del trabajo pesado
button.addEventListener('click', () => {
showSpinner(); // actualización visible inmediata
setTimeout(() => {
recalculateCart(); // el trabajo pesado corre después del pintado
sendAnalyticsEvent();
}, 0);
});
En navegadores compatibles, scheduler.yield() hace lo mismo con menos espera. Revisa la compatibilidad antes de depender de él y deja setTimeout como respaldo.
Paso 5: Corrige el CLS (saltos de diseño)
Abre el insight Layout shift culprits en PageSpeed Insights o en un trace de DevTools. Enumera los elementos que se movieron y, muchas veces, la razón: una imagen sin tamaño, una fuente web o contenido insertado.
- Abre Layout shift culprits para ver de dónde sale el CLS.
- Corrige primero el desplazamiento más grande. Muchas veces un solo banner explica casi todo el valor.
Correcciones comunes del CLS
Ponle tamaño a cada imagen y video. Agrega los atributos width y height. El navegador los usa para reservar el espacio correcto, incluso con CSS adaptable.
img { max-width: 100%; height: auto; } /* conserva la proporción de width/height */
.video-embed { aspect-ratio: 16 / 9; } /* reserva espacio para iframes */
.ad-slot { min-height: 250px; } /* reserva el tamaño de anuncio más probable */
Reserva espacio para el contenido tardío. Los avisos de cookies, barras promocionales, anuncios y bloques de «productos relacionados» suelen cargar después del renderizado y empujan el contenido. Dales un espacio fijo con min-height o muéstralos como capa superpuesta que no mueva la página.
Controla las fuentes web. Cuando entra una fuente web, el texto puede cambiar de tamaño y mover líneas. Precarga la fuente principal, elige una fuente de respaldo parecida y considera font-display: optional o ajustes de métricas como size-adjust para que el cambio no mueva el texto.
Anima con transform. Animar top, left, height o margin mueve otros elementos. Usa transform.
Revisa la caché de avance y retroceso. Las páginas restauradas desde la bfcache no repiten sus saltos de carga. Evita lo que las vuelve inelegibles, como los controladores unload.
Las herramientas de laboratorio solo ven los saltos durante la carga. Si tu CLS de campo es mucho peor que el de laboratorio, los saltos pasan después: al hacer scroll, tras un clic o cuando carga contenido diferido. Reproduce ese recorrido en DevTools con las métricas en vivo abiertas.
¿Sigue sin funcionar? Causas comunes
| Síntoma | Causa probable | Solución |
|---|---|---|
| Mejoró la prueba de laboratorio pero Search Console no se movió | Los datos de campo son una ventana móvil de 28 días | Espera unas cuatro semanas después del despliegue completo |
| La puntuación de PageSpeed cambia en cada prueba | Las pruebas de laboratorio varían con la red y la carga del servidor | Corre tres pruebas y compara la mediana; confía en los datos de campo |
| LCP bien en computadora, mal en móvil | Imágenes grandes, CPU lenta y mucho JavaScript en celulares | Sirve imágenes más chicas con srcset y reduce JavaScript en móvil |
| La imagen LCP sigue lenta tras precargarla | Tiene carga diferida o está escondida en un slider | Quita la carga diferida; haz que la primera diapositiva sea una etiqueta img real |
| INP deficiente pero el laboratorio se ve limpio | Las pruebas de laboratorio no interactúan con la página | Usa las métricas en vivo de DevTools y prueba clics reales en un celular de gama media |
| El INP empeoró al agregar etiquetas | Scripts de terceros nuevos corren en cada clic | Quita etiquetas sin uso, retrasa las no esenciales y revisa Third parties |
| CLS malo solo en campo | Saltos después de la carga (anuncios, scroll infinito, banners) | Reserva espacio y reprodúcelo haciendo scroll |
| Falta un grupo de URLs en el informe | No hay suficiente tráfico de Chrome en ese grupo | Usa la vista Origen en PageSpeed Insights o tus propios datos RUM |
| Falló la validación | Algunas URLs del grupo siguen fallando | Corrige la plantilla en todas partes, incluidas variantes como AMP o páginas filtradas |
Plugins de caché que crean problemas nuevos
Los plugins de optimización ayudan, pero algunas opciones salen contraproducentes. Combinar todo el JavaScript en un archivo puede crear una sola tarea larga que daña el INP. La carga diferida en todas las imágenes daña el LCP. Retrasar todos los scripts hasta la interacción puede romper formularios y medición. Activa las opciones de una en una, prueba y toma notas.
Límites del hosting
Si el TTFB es alto incluso en una página sencilla y en caché, el servidor puede ser el cuello de botella. Una CDN con caché de página suele ayudar más que cualquier ajuste del front end. Si no puedes usar caché (por ejemplo, en páginas con sesión iniciada o de carrito), trabaja con tu proveedor o tu desarrollador en la velocidad de la base de datos y del backend.
Cómo confirmar que quedó resuelto
Revisa justo después del despliegue:
- Vuelve a analizar la URL de ejemplo en PageSpeed Insights. El LCP, el TBT y el CLS de laboratorio, y los insights relacionados, deben mejorar.
- En las métricas en vivo de DevTools, repite las interacciones lentas. El INP debe quedar por debajo de 200 ms con la CPU limitada.
- Usa Inspección de URLs > Probar URL publicada en Search Console con un par de páginas para confirmar que Google las sigue renderizando bien.
Después inicia la validación en Search Console. Abre el problema en el informe Core Web Vitals y haz clic en Validar corrección (el centro de ayuda lo llama «Start tracking», iniciar seguimiento). Search Console vigila las URLs afectadas durante 28 días. Si el problema no aparece en ninguna URL en ese periodo, se marca como corregido.
En PageSpeed Insights, la sección de datos de campo se actualiza conforme avanza la ventana de 28 días. Espera un cambio gradual, no un salto.
Las páginas rápidas también ayudan al rastreo y al descubrimiento. Si tus páginas nuevas tardan en salir en Google, lee cómo lograr que Google indexe tu sitio.
Preguntas frecuentes
¿Las Core Web Vitals afectan el posicionamiento?
Forman parte de las señales de experiencia en la página de Google. Una buena calificación no rescata contenido débil, y una mala rara vez hunde por sí sola una página excelente. Trátalas como una mejora de experiencia que además elimina un riesgo de posicionamiento.
¿Por qué PageSpeed Insights dice «Sin datos» en los datos de campo?
La URL no tiene suficientes visitas de Chrome en el Chrome UX Report. Cambia a Origen para ver todo el sitio o recopila tus propios datos de usuarios reales con la librería web-vitals.
¿Todavía se mide el FID?
No. El INP sustituyó al FID como Core Web Vital en marzo de 2024. Quita el FID de tus informes y tableros.
¿Qué corrijo primero?
Empieza por la métrica que falla en la plantilla con más tráfico, normalmente en móvil. Una corrección de plantilla suele mover cientos de URLs a la vez.
¿Los datos estructurados afectan las Core Web Vitals?
No de forma significativa. Un bloque JSON-LD pesa poco y no se renderiza. Si vas a agregarlo, revisa cómo agregar marcado de schema y probarlo.
¿Te atoraste con esto? Lo resolvemos para clientes cada semana. Agenda una auditoría gratis
