Tres métricas, tres problemas distintos
Usa el percentil 75 de visitas reales, separado entre móvil y escritorio. Una ejecución de Lighthouse ayuda a investigar una falla; no acredita un resultado de campo. Los umbrales siguientes definen valores buenos.
| Métrica / umbral bueno | Investigar |
|---|---|
| LCP ≤ 2,5 s | Descubrimiento del contenido, servidor e imágenes |
| INP ≤ 200 ms | Demora de entrada, manejadores y siguiente pintura |
| CLS ≤ 0,1 | Medios sin espacio reservado, fuentes e interfaz insertada |
Si faltan datos de campo, indícalo y usa pruebas de laboratorio repetibles. Conserva el propósito del diseño mientras corriges la demora, tarea larga o desplazamiento que muestra el registro.
- 01Datos reales
- 02Registro
- 03Corregir
- 04Validar
Entiende qué miden las tres métricas
Largest Contentful Paint, o LCP, mide cuándo se renderiza la imagen, bloque de texto u otro elemento elegible más grande dentro del viewport. Un LCP bueno es de 2,5 segundos o menos; por encima de 4 segundos es deficiente. Interaction to Next Paint, o INP, mide la demora entre un clic, toque o pulsación de tecla elegible y la siguiente respuesta visual. Un INP bueno es de 200 milisegundos o menos; por encima de 500 milisegundos es deficiente. Cumulative Layout Shift, o CLS, mide el movimiento inesperado del contenido visible. Un CLS bueno es de 0,1 o menos; por encima de 0,25 es deficiente.
Estas clasificaciones usan el percentil 75 de las visitas y separan por dispositivo cuando está disponible. Una sola ejecución rápida no equivale a que el 75 por ciento de las personas cumpla el umbral. Los datos de campo provienen de visitas reales e incluyen sus dispositivos, conexiones, ubicación, estado de caché y comportamiento. Los datos de laboratorio provienen de una ejecución controlada de Lighthouse. Registra la fuente, URL u origen, clase de dispositivo y periodo de recopilación de cada cifra.
Diagnostica LCP como una cadena de demoras
Supón que una página de servicio reporta un LCP móvil de 4,3 segundos y que el elemento LCP es la imagen principal. No empieces a reemplazar la imagen a ciegas. Divide el tiempo entre la respuesta del servidor, la espera antes de iniciar la petición de la imagen, su descarga y el tiempo necesario para renderizarla. Un primer byte lento apunta al hosting, el trabajo del servidor, el perímetro o una redirección. Una petición tardía puede significar que la imagen está detrás de JavaScript, en un fondo CSS o en una ruta de descubrimiento con baja prioridad. Una descarga grande puede necesitar una imagen responsive del tamaño correcto, compresión moderna y un objetivo de calidad que conserve el mensaje. Una demora larga de renderizado puede revelar trabajo del hilo principal, fuentes o dependencias de layout.
Usa PageSpeed Insights y DevTools para identificar el elemento LCP y el desglose de tiempos; después compáralo con datos de campo. Haz que el recurso importante sea descubrible en el HTML inicial, evita cargar de forma diferida el elemento visible arriba, reserva sus dimensiones y entrega pronto el documento inicial. Repite la misma URL en las mismas condiciones de laboratorio, pero conserva el valor anterior y la distribución de usuarios reales.
Encuentra la interacción que eleva INP
Imagina la página de reservas de una clínica bogotana cuyo selector de fecha parece congelado. Un trazo de laboratorio muestra una tarea larga justo después del toque: un script grande recalcula disponibilidad, vuelve a renderizar cada cita y dispara analítica antes del siguiente cuadro. INP incluye demora de entrada, procesamiento del evento y presentación, así que reducir solo la petición de red puede no cambiar nada si el hilo principal sigue bloqueado. Perfila la interacción en DevTools, identifica el manejador lento y separa la respuesta urgente del trabajo posterior. Muestra el selector abierto de inmediato y luego consulta o calcula la disponibilidad de forma asíncrona. Divide las tareas largas de JavaScript, evita volver a renderizar filas que no cambiaron y aplaza etiquetas de terceros que no sean esenciales.
INP observa interacciones elegibles durante toda la visita, así que prueba el menú, la búsqueda, los filtros, los formularios y los controles de pago que las personas usan. La atribución de campo o una biblioteca de monitoreo de usuarios reales puede identificar el elemento y la interacción que resultaron lentos; después los flujos de laboratorio pueden reproducirlos. El desplazamiento y el hover no cuentan para INP; sin suficientes interacciones, los datos de campo pueden no estar disponibles. Conserva la acción de negocio y reduce el tiempo hasta su primera respuesta visible.
Rastrea los movimientos inesperados de CLS
Considera una página de producto cuyo botón de compra baja después de que aparece un banner promocional. Revisa la imagen, el banner, la fuente o el embed que llegó tarde en vez de culpar al botón que se movió. Da dimensiones intrínsecas a imágenes y videos o reserva espacio con aspect-ratio. Asigna un área conocida para un aviso, consentimiento, anuncio o iframe antes de que cargue. Evita insertar contenido sobre el viewport sin un placeholder previsto. Una fuente web que cambia los saltos de línea puede mover el contenido; usa un fallback compatible y carga las fuentes críticas con intención.
Lighthouse suele encontrar movimientos durante la carga inicial. Las personas reales también pueden verlos después de desplazarse, abrir un menú o volver mediante la caché back/forward, así que compara laboratorio y campo. En el panel Performance de DevTools, inspecciona los registros de layout shift y los elementos que se movieron, y luego reproduce el recorrido de negocio en una pantalla estrecha. Un cambio iniciado por una interacción puede ser esperado, pero una respuesta de red tardía que empuja un control visible sigue siendo un problema aunque una recarga de laboratorio no lo haya detectado. Busca espacio estable y feedback claro, no una puntuación obtenida ocultando contenido.
Usa mediciones de laboratorio y de campo juntas
Ejecuta una prueba de laboratorio antes de publicar para crear una línea base controlada. Conserva URL, viewport, throttling, versión del navegador e identificador del build. Lighthouse puede mostrar oportunidades y trazos de LCP, trabajo del hilo principal relacionado con INP y CLS durante su carga programada, pero no observa todas las interacciones posteriores ni todas las condiciones de red. PageSpeed Insights también reporta datos de campo de CrUX cuando hay tráfico elegible suficiente, normalmente en un periodo móvil de 28 días. Confirma si el valor corresponde a la URL o solo al origen, y si móvil y escritorio cuentan historias diferentes.
Si el campo es peor que el laboratorio, busca dispositivos, conexiones, etiquetas de terceros, movimientos posteriores a la carga o interacciones que el script omitió. Si el laboratorio es peor que el campo, conserva la advertencia: la muestra puede ser pequeña o estar sesgada hacia dispositivos capaces. Recoge tu propia atribución de campo cuando CrUX sea demasiado general, respetando el diseño de privacidad del sitio. Compara distribuciones y percentiles 75 en vez de una sola puntuación, y anota los despliegues para relacionar un cambio con un efecto medible.
Define una aceptación de negocio sin promesas
Elige la página y la tarea que importan: una página de servicio debe cargar su oferta, un catálogo debe mostrar un producto y un formulario de leads debe responder a un toque. Define un objetivo para cada métrica en el percentil 75, prueba en los dispositivos de tus visitantes y conserva un ejemplo de ruta lenta para revisarlo. Corrige primero la causa verificada más grande y repite el recorrido completo para que una optimización no rompa navegación, analítica, accesibilidad o formulario.
Core Web Vitals son señales útiles, no un contrato de conversión o posición en búsquedas. Una página puede cumplir los tres umbrales y aun así tener textos confusos, una consulta rota o un pago externo lento. También puede fallar un umbral en una URL de poco tráfico mientras su audiencia está satisfecha. Reporta métrica, percentil, segmento, fecha, herramienta y tarea, y declara la incertidumbre restante. El monitoreo continuo de campo y un conjunto pequeño de recorridos de laboratorio repetibles convierten el rendimiento en una práctica operativa, no en una captura de lanzamiento.
Fuentes y lecturas
Fuentes de esta guía, con más detalles de sus publicaciones originales.
- web.dev: umbrales de Core Web Vitals
- web.dev: optimizar Largest Contentful Paint (LCP)
- web.dev: Interaction to Next Paint (INP)
- web.dev: optimizar Interaction to Next Paint (INP)
- web.dev: optimizar Cumulative Layout Shift (CLS)
- Google para desarrolladores: acerca de PageSpeed Insights
- web.dev: por qué difieren los datos de laboratorio y de campo