Core Web Vitals:
carga,
capacidad de respuesta, estabilidad
Interprete las métricas de carga, respuesta y desplazamiento, encuentre la causa del problema y compruebe el trabajo del desarrollador.
Encuentre la causa.
Verifique la corrección.
De una definición breve a la revisión de su sitio: datos reales, informes de laboratorio y situaciones que explican las métricas en rojo.
Qué son las Core Web Vitals y por qué comprobarlas
Las Core Web Vitals miden tres aspectos de la experiencia de página: LCP describe cuándo aparece el contenido grande de la primera pantalla, INP la respuesta a las acciones y CLS la estabilidad de los elementos. Juntas permiten distinguir quejas como «no veo la oferta», «el botón se ha bloqueado» y «el enlace se ha movido bajo el dedo».
Imagine un catálogo de equipos. El título y las fotos aparecen rápido, pero al elegir la potencia el filtro deja de responder un segundo. La carga parece buena; la interacción, no. En otro catálogo el filtro responde al instante, pero una franja publicitaria desplaza los productos hacia abajo cuando aparece. Afirmar que «el sitio es rápido» no describe estas situaciones.
Compruebe estos indicadores al lanzar el sitio, cambiar plantillas, añadir widgets y realizar auditorías técnicas periódicas. Empiece por las páginas donde el visitante lee la oferta y decide: servicios, categorías, productos y artículos. Guarde ejemplos de URL de cada plantilla. El resultado de la página de inicio no puede atribuirse automáticamente a todo el sitio.
Comprender las métricas y definir una tarea verificable. Para un recorrido detallado por servicios de medición de velocidad, solicitudes de red e informes de Yandex, consulte «Cómo comprobar la velocidad de carga de un sitio».
Valores buenos de LCP, INP y CLS
| Métrica | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|
| LCP: aparición del contenido grande | ≤ 2,5 s | > 2,5 y ≤ 4 s | > 4 s |
| INP: latencia de interacción | ≤ 200 ms | > 200 y ≤ 500 ms | > 500 ms |
| CLS: desplazamientos del diseño | ≤ 0,1 | > 0,1 y ≤ 0,25 | > 0,25 |
Los umbrales proceden de la documentación de LCP, INP y CLS. CLS es una puntuación sin unidad: «0,1 segundos» es incorrecto. Cuanto menor sea cada una de las tres métricas, mejor será el aspecto correspondiente de la experiencia.
Qué significa el percentil 75
Los datos de campo se evalúan en p75, por separado para móviles y ordenadores. Si el p75 de LCP es de 2,3 segundos, al menos el 75 % de las cargas registradas alcanzó ese valor o uno mejor. No es una media aritmética ni garantiza ese resultado a todos los visitantes.
Ejemplo didáctico: un grupo de páginas móviles tiene LCP de 2,2 s, INP de 310 ms y CLS de 0,06. El grupo no es totalmente bueno: la respuesta necesita mejorar. Con datos suficientes, PageSpeed aprueba la evaluación si los tres p75 son buenos. Si faltan datos de INP, puede evaluar mediante LCP y CLS; la falta de cualquiera de estos dos impide la evaluación. Este matiz se explica en la metodología de PageSpeed Insights.
Datos de campo, laboratorio y puntuación de PageSpeed
Los datos de campo de CrUX reflejan visitas de usuarios de Chrome que participan en la recopilación. En PageSpeed abarcan una ventana móvil de los últimos 28 días. El informe de laboratorio de Lighthouse simula una carga con limitaciones especificadas. Sirve para diagnosticar, pero no reproduce todos los dispositivos, páginas y acciones de su audiencia.
Compruebe la etiqueta de la fuente: las estadísticas pueden corresponder a una URL o al origen, formado por protocolo, host y puerto. Los datos del origen no miden únicamente el artículo abierto. «Sin datos» significa que faltan muestras aptas, no que no haya problemas ni que la velocidad sea cero.
| Informe | Para qué utilizarlo | Qué registrar |
|---|---|---|
| CrUX en PageSpeed | Entender la experiencia acumulada de los visitantes | Dispositivo, periodo, URL u origen, p75 |
| Core Web Vitals en Search Console | Localizar grupos problemáticos de páginas similares | Grupo, métrica, ejemplos de URL y estado |
| Lighthouse | Revisar una carga concreta y sus diagnósticos | URL, fecha, modo, versión y enlace al informe |
| Panel Performance de Chrome | Reproducir un bloqueo o desplazamiento | Secuencia de acciones y grabación de rendimiento |
Una puntuación de rendimiento de 100 no equivale a aprobar las Core Web Vitals. La prueba de carga puede terminar rápido mientras un filtro pesado solo se ejecuta tras un clic. Lighthouse también muestra TBT, el tiempo de bloqueo durante la carga. Ayuda a diagnosticar, pero no sustituye al INP de interacciones reales. Mantenga siempre la fuente y el periodo junto a los valores.
Dónde consultar las métricas de su sitio
PageSpeed Insights: empezar por una página
- Abra PageSpeed Insights, introduzca la URL pública completa y ejecute el análisis.
- Seleccione la vista móvil. En el bloque de rendimiento de usuarios reales, compruebe la fuente y cada métrica, no solo el estado general.
- Abra el informe de laboratorio situado debajo. Localice LCP, CLS y los diagnósticos relacionados con el problema observado. Guarde el enlace al resultado.
- Cambie a la vista de ordenador. Registre sus métricas por separado: es otro modo, no una confirmación del resultado móvil.
- Repita la prueba para las demás plantillas importantes. Registre un error del servicio como una medición incompleta.
Search Console: pasar de una página a un grupo
- Abra Google Search Console y seleccione la propiedad verificada de su sitio.
- Acceda a «Core Web Vitals» y abra el informe de móviles u ordenadores.
- Seleccione un problema, por ejemplo un LCP que necesita mejorar. Abra la fila del grupo y anote ejemplos de URL.
- Identifique qué comparten esas páginas: plantilla, imagen grande, cabecera o bloque publicitario. Entregue al desarrollador varios ejemplos representativos.
- Después de corregir el grupo, inicie la validación y observe su evolución posterior.
Search Console agrupa páginas con una experiencia similar, por lo que el resultado del grupo puede diferir del de una URL concreta en PageSpeed. El informe no enumera todas las direcciones del sitio. Las reglas de agrupación y validación se explican en la ayuda de Google.
Si el sitio es nuevo y no tiene datos de campo, guarde una referencia de laboratorio y compruebe los recorridos manualmente. No es necesario esperar a reunir datos para corregir un botón que salta a la vista. Pero el acta de aceptación no debe sustituir una métrica de campo desconocida por un valor de laboratorio.
El contenido principal aparece tarde
LCP registra el renderizado del mayor elemento apto en el área visible, como una imagen o un bloque de texto. No significa que todos los archivos de la página se hayan cargado. Un banner grande no tiene por qué ser el elemento LCP en móvil: al cambiar la distribución, puede serlo el título.
Primero identifique el elemento en el informe. Después analice la espera de la primera respuesta del servidor, el retraso hasta la solicitud del recurso, su carga y la demora de renderizado. Si el archivo ya está descargado pero el elemento permanece oculto hasta acabar una animación, comprimir más la imagen no eliminará ese retraso.
- La solicitud comienza tarde. Compruebe si la imagen puede descubrirse en el marcado inicial y si algún script retrasa su aparición. Por lo general, la imagen principal de la primera pantalla no debe cargarse de forma diferida junto con las ilustraciones inferiores.
- La transferencia del archivo tarda demasiado. Ajuste el tamaño de la imagen a su visualización real y compruebe variantes adaptables y compresión. Tras sustituirla, revise los detalles en un teléfono y un monitor grande.
- El servidor responde tarde. Investigue el procesamiento de solicitudes y la caché. No concluya que necesita cambiar de alojamiento solo por el peso de la página.
- El contenido espera para renderizarse. Revise los estilos bloqueantes, la ejecución de scripts, la carga de fuentes y los efectos de aparición.
Son líneas de diagnóstico, no una lista universal de cambios obligatorios. Los componentes y las formas de reducir sus demoras se explican en la guía de LCP de web.dev.
En una página móvil de servicio, el elemento principal es una imagen cuya solicitud empieza después de ejecutarse el carrusel. Compruebe su detección temprana, conserve la composición actual y repita la medición con las condiciones originales. Adjunte una vista del elemento y las líneas de tiempo antes y después.
La página responde lentamente a una acción
INP considera clics, toques y pulsaciones de teclas durante toda la visita. Mide el retraso hasta el siguiente fotograma mostrado tras la interacción, no la duración completa de una operación remota. Sustituyó a FID, que solo medía la espera hasta procesar la primera entrada. Desplazarse por la página, por sí solo, no es una interacción medida por INP.
Compruebe el menú móvil, la búsqueda, los filtros, el cambio de pestañas, la apertura de respuestas y los campos del formulario, durante y después de la carga. Una respuesta instantánea en una página vacía del editor no demuestra nada sobre un catálogo con cientos de elementos y widgets activos.
Cómo reproducir una respuesta lenta
- Abra la URL afectada en Chrome y, después, las herramientas de desarrollo y el panel Performance.
- Inicie la grabación y ejecute un recorrido concreto, como abrir un filtro y elegir un valor.
- Detenga la grabación. Localice la interacción retrasada y las tareas que se ejecutaban en ese momento.
- Registre dónde se consumió el tiempo: antes del manejador, dentro de él o al preparar el siguiente fotograma.
- Tras la corrección, repita las mismas acciones con las mismas limitaciones. Compruebe también un dispositivo real de destino.
El procedimiento de grabación se explica en la documentación del panel Performance. Si hay cálculos pesados, el desarrollador puede dividir las tareas; si hay un repintado costoso, reducir el alcance de la actualización de la interfaz. La elección debe basarse en la grabación, como muestra la guía de optimización de INP.
Ejemplo didáctico: tras elegir una ciudad, el servidor calcula las opciones de entrega. La interfaz debe confirmar la acción de inmediato y mostrar correctamente el resultado o el error después. Una respuesta visual rápida ayuda, pero no justifica una espera interminable ni sustituye la prueba de la propia entrega. No elimine funciones necesarias por una sola métrica.
Los elementos se desplazan durante la lectura
CLS evalúa los desplazamientos inesperados de elementos visibles. El cálculo actual toma la mayor ráfaga de desplazamientos: intervalos inferiores a un segundo y una duración total de hasta cinco segundos. No es la suma simple de todos los movimientos de la visita. Compruebe la carga y también el uso posterior de la página.
Revise especialmente imágenes sin espacio reservado, vídeos incrustados, anuncios, avisos tardíos y cambios de fuente. En una página de servicio, el título puede pasar de dos a tres líneas al cargarse la tipografía de marca, desplazando todo lo que está debajo. Investigue la causa concreta del cambio de geometría.
- Defina las dimensiones correctas o la relación de aspecto de las imágenes para reservar espacio antes de que llegue el archivo.
- Para los bloques dinámicos, acuerde el espacio reservado y el comportamiento cuando no haya datos.
- Compruebe las fuentes de reserva y principal: saltos de línea, tamaño de botones y altura de títulos.
- Repita la lectura, el desplazamiento y la expansión del contenido. Los cambios posteriores a la carga pueden no aparecer en una prueba breve de la primera pantalla.
No todo cambio de diseño se considera inesperado. Por ejemplo, puede excluirse un desplazamiento poco después de una acción puntual del usuario. Aun así, los botones deben ser previsibles. La metodología se explica en la definición de CLS, y las correcciones habituales, en la guía de optimización.
En una ficha de producto, el bloque de pago a plazos aparece tarde y desplaza el botón de compra. Tras corregirlo, pruebe productos con títulos de distintas longitudes y precios diferentes, una red lenta y un servicio de pago a plazos que no responde. El botón debe seguir accesible en todos los casos.
Por qué un diseño caro no garantiza buenas métricas
Ni el presupuesto ni la expresividad del diseño explican cómo se implementó la página. La misma composición puede usar imágenes adecuadas y transiciones ligeras, o cargar un vídeo grande y varias bibliotecas de animación mientras oculta la oferta hasta que arrancan. Evalúe la implementación publicada.
Pida al equipo que muestre la primera pantalla en un teléfono normal: antes y después de cargar los efectos y durante la interacción. Aclare la función de cada elemento pesado. A veces basta con cambiar el orden de carga o mantener un primer fotograma estático para conservar la idea visual. Otras veces hay que replantear un efecto que impide leer la oferta. Decida después de medir.
Google utiliza las Core Web Vitals en sus sistemas de clasificación, pero unas buenas métricas no garantizan los primeros puestos. Acelerar el sitio no corrige textos irrelevantes, indexación bloqueada ni una oferta confusa. Así lo indican las recomendaciones de Google sobre la experiencia de página.
Si el tráfico no crece, compruebe la visibilidad y la relevancia para las búsquedas por separado de la velocidad técnica. Si las solicitudes no llegan, reproduzca el recorrido del usuario. «Pondremos las CWV en verde y llegará al primer puesto» no es un resultado técnico verificable. Estas tareas se conectan mediante una auditoría SEO del sitio.
Cómo priorizar y definir la tarea del desarrollador
Confirme primero el problema y evalúe después su alcance y la importancia del recorrido afectado. Un menú móvil común que responde tarde afecta a muchas páginas. Una ilustración pesada en un artículo poco visitado tiene otro alcance. No asigne la misma prioridad a todas las recomendaciones automáticas.
Incluya el resultado inicial y las condiciones. No escriba solo «acelerar hasta verde». Un encargo útil sería: «En la categoría móvil, elegir una marca tarda demasiado en producir una respuesta visible. Se adjuntan grabación de Performance y pasos. Identificar la causa, corregir y confirmar con el mismo recorrido. Comprobar que se conserva el filtro, funciona el contador y se accede a las fichas de producto».
Antes de recurrir al desarrollador, el responsable puede reunir URL, informes y vídeos, identificar widgets imprescindibles, localizar originales demasiado grandes en la biblioteca y revisar los campos de imágenes. Los cambios de scripts, caché y plantillas comunes deben incluir copia de seguridad y pruebas funcionales. Eliminar la analítica en bloque u ocultar contenido no mejora adecuadamente la experiencia.
Si necesita implementación, la evolución técnica del sitio puede incluir diagnóstico, cambios y control del resultado. El alcance depende de las causas, no del número de filas rojas del informe.
Cómo aceptar las correcciones y mantener el resultado
Tras publicar, compruebe de inmediato la versión actualizada y repita los escenarios de laboratorio. Los datos de campo anteriores no desaparecen en ese momento: el periodo aún incluye visitas previas a la corrección. Anote la fecha de publicación para compararla después con la evolución de CrUX y Search Console.
Una ejecución satisfactoria no garantiza un resultado estable. Repita las mediciones en condiciones comparables, conserve la variación y no elija solo el mejor informe. Mantenga un conjunto de páginas de control para futuras versiones: un nuevo anuncio o widget puede devolver los retrasos. La lista completa de comprobaciones de entrega figura en la guía para aceptar un sitio entregado por el desarrollador.
Qué más conviene saber de las Core Web Vitals
¿Qué métricas forman actualmente las Core Web Vitals?
LCP, INP y CLS. FID fue el antecesor de INP. Si el proveedor muestra un informe antiguo con solo FID, pida una comprobación actualizada de la capacidad de respuesta.
¿Por qué PageSpeed muestra 100 si no se aprueba CWV?
La puntuación corresponde a una carga de laboratorio; el estado CWV, a datos de campo acumulados. Compare periodo, dispositivo, alcance de URL u origen y cada métrica. No los trate como dos resultados de la misma prueba.
¿Se puede comprobar INP recargando la página?
Una comprobación completa de respuesta requiere acciones: clics, toques o pulsaciones de teclas. Una carga rápida y un TBT bajo no demuestran que filtros y menús respondan sin retrasos.
¿Qué hacer si no hay datos de CrUX?
Registre la falta de datos, pruebe la carga de laboratorio y los recorridos reales en dispositivos de destino. Añada la evaluación de campo cuando haya estadísticas suficientes. No invente un valor ausente.
¿Hay que renunciar a las animaciones y fuentes de marca?
No de forma automática. Identifique una causa confirmada del retraso o desplazamiento. Elija un cambio que preserve la legibilidad, la intención visual y el funcionamiento de la interfaz, y compruebe el resultado.
¿Cuándo se actualizan las métricas tras corregir?
Una prueba de laboratorio mide una nueva ejecución. Los informes de campo reflejan un periodo acumulado, cambian gradualmente y dependen de disponer de datos suficientes. No puede garantizarse de antemano cuándo aparecerá un estado bueno concreto.
Continúe la revisión con estas guías: velocidad de carga y adaptación móvil. Las definiciones de otros conceptos están en el glosario digital.
REVISEMOS LOS PROBLEMAS
TÉCNICOS DE SU SITIO
Revisamos páginas y recorridos importantes, identificamos las causas de los retrasos y planificamos mejoras con criterios de aceptación claros.