Sepa qué le está diciendo cada métrica
Largest Contentful Paint, o LCP, mide cuándo se renderiza la imagen o bloque de texto más grande en la ventana de visualización inicial (viewport). Interaction to Next Paint, o INP, mide la capacidad de respuesta de una visita mediante su interacción calificante más lenta. Cumulative Layout Shift, o CLS, mide movimientos visibles inesperados durante una visita.
Los objetivos de experiencia publicados por Google son LCP en 2,5 segundos o menos, INP en 200 milisegundos o menos, y CLS en 0,1 o menos. Evalúelos en el percentil 75 de las cargas de página, por separado para móvil y escritorio. Use los objetivos para enfocar el trabajo, no como garantía de posicionamiento ni como motivo para ignorar a los visitantes más lentos.
El contenido principal aparece tarde; investigue el servidor, el descubrimiento de recursos, la descarga y la ruta de renderizado.
Un clic, toque o pulsación espera demasiado por una respuesta visual; la fuente puede ser un iframe embebido.
El contenido se mueve inesperadamente; preste atención extra a los cambios cerca de controles, formularios y posiciones de lectura.
Deje que los datos de campo fijen la prioridad y que las pruebas de laboratorio la expliquen
Los datos de campo provienen de visitas reales, incluidos dispositivos reales, redes, ubicaciones, estados de caché y comportamientos. Los datos de Chrome User Experience Report aparecen en PageSpeed Insights y Search Console cuando hay sufieciente información. Su propio monitoreo de usuarios reales puede añadir contexto por vista de página; recopile solo la telemetría necesaria y evite contenido introducido por clientes.
Los datos de laboratorio son una prueba repetible bajo condiciones seleccionadas. Son útiles para aislar un cambio de lanzamiento y leer un trace, pero no pueden representar a todos los visitantes. Lighthouse no puede medir INP verdadero sin una interacción real, por lo que su Total Blocking Time es un proxy diagnóstico. Cuando los resultados difieren, use los datos de campo para priorizar y los de laboratorio para investigar.
Registre si los datos son a nivel de URL u origen y si son móvil o escritorio.
Guarde la fecha, grupo de páginas, dispositivo, distribución, ajustes de prueba y lanzamientos recientes con la línea base.
Priorización por alcance, daño a la tarea, evidencia y reversibilidad
No empiece por el número más bajo del tablero. Ordene los candidatos por visitas afectadas, importancia de la tarea del visitante, repetición en una plantilla y si un cambio puede aislarse y revertirse. Esto convierte la optimización de Core Web Vitals en una remediación operacional en lugar de en una persecución de puntajes.
Una dimensión faltante en una imagen de una plantilla compartida puede ser un primer cambio mejor que una reescritura especulativa del front-end. Una interacción de checkout menos común puede tener prioridad cuando bloquea la finalización. Acompañe la evidencia métrica con feedback de soporte, observación del embudo y revisión de accesibilidad.
Problemas repetidos observados en campo sobre plantillas importantes con un remedio claro y de bajo riesgo.
Ideas arquitectónicas sin un problema de usuario medido o sin camino de reversión; manténgalas como hipótesis.
Arregle LCP acortando la ruta hacia el contenido principal
Identifique el elemento LCP para la página y el grupo de dispositivos afectados. Inspeccione la respuesta HTML inicial, cuándo el navegador descubre el elemento, cuánto tarda en descargarse su recurso y qué bloquea el renderizado. Un tiempo de respuesta de servidor alto puede hacer que alcanzar el objetivo de LCP sea impráctico incluso con un recurso principal bien optimizado.
Mantenga el contenido primario descubrible temprano cuando eso encaje con el diseño. No lazy-load la imagen que es el elemento LCP. Para páginas centradas en imágenes, use un recurso con tamaño y codificación apropiados y dimensiones explícitas. Pruebe preloads y reglas de entrega: una solicitud temprana solo es útil si no compite con trabajo más importante.
Compruebe redirecciones, trabajo del servidor, comportamiento de caché y proximidad de entrega; esto puede requerir propiedad de la aplicación u hospedaje.
Verifique si el renderizado del cliente, scripts o CSS retrasan el descubrimiento del texto o la imagen principal.
Haga que las interacciones sean rápidas y los diseños predecibles
Para INP, reproduzca un flujo lento en un trace del navegador. Separe el retraso de entrada, el procesamiento de eventos y el retraso de presentación. Tareas largas en el hilo principal, controladores pesados, renderizado costoso y thrashing de layout pueden cada uno posponer la siguiente pintura. Haga trabajo visual para el siguiente frame primero; difiera guardados no esenciales, analytics o actualizaciones secundarias cuando los requisitos del producto lo permitan.
Para CLS, encuentre los elementos que se mueven en lugar de adivinar a partir del total. Reserve espacio para imágenes, vídeo, anuncios, embebidos y iframes con dimensiones o una proporción de aspecto CSS. Revise la carga de fuentes y contenido inyectado. No oculte un consentimiento, error o mensaje de accesibilidad necesario solo para mejorar una puntuación; dele una ubicación estable.
Diferir trabajo puede cambiar el tiempo de la aplicación. Pruebe regresiones de estado, validación y comportamiento del teclado.
Desplácese por áreas lazy-loaded y embebidas; una prueba solo de carga puede pasar por alto desplazamientos posteriores.
Libere mejoras con seguridad y confírmelas
Los cambios de rendimiento pueden afectar scripts, caché, renderizado, embebidos o configuración de entrega. Etape el cambio, compare un camino de prueba definido con la línea base y documente la reversión. Para flujos de pago, cuenta o regulados, involucre a revisores apropiados de seguridad, cumplimiento y accesibilidad antes de cambiar embebidos, validación o manejo de datos. Esto es orientación educativa, no una evaluación de cumplimiento.
Después del lanzamiento, compare el mismo camino de laboratorio y observe segmentos de campo comparables durante su ventana normal de reporte. Busque efectos no intencionales como un error oculto o una interfaz ilegible. Status Is UP soporta la optimización proactiva del tiempo de actividad mediante comprobaciones recurrentes, propiedad clara de la remediación y preparación de reversión entre incidentes.
Vincule cada cambio a un grupo de páginas, métrica, propietario, evidencia de prueba, compensación e instrucción de reversión.
No declare el éxito por una sola pasada sintética; confirme el patrón relevante de usuarios reales.