Plantilla de auditoría de Core Web Vitals y velocidad de página

Benchmark & ​​Field vs Lab Data

Cuándo usarla: Establezca una línea de base para cada Core Web Vital antes de cambiar algo y aprenda en qué fuente de datos confiar para la puntuación frente a la depuración.

Establece tu línea de base

Antes de optimizar nada, registra el valor actual de cada métrica para [URL de la página]. Google clasifica según los datos de campo (usuarios reales de Chrome, el conjunto de datos CrUX y una ventana móvil de 28 días), por lo que esas son las cifras que importan para la Búsqueda. Los datos de laboratorio (Lighthouse y una única carga simulada) sirven para diagnosticar problemas, porque son repetibles y ofrecen trazas útiles.

• Fuente de campo: obtén los datos de CrUX desde PageSpeed Insights o desde el informe Core Web Vitals de Search Console para [Propiedad].
• Fuente de laboratorio: ejecuta Lighthouse (en Chrome DevTools o PageSpeed Insights) para reproducir y rastrear los problemas.
• Registra los umbrales: LCP bueno <=2,5 s, INP bueno <=200 ms y CLS bueno <=0,1; anota el valor actual y si cada métrica supera o no el "percentil 75".

Es normal que los datos de campo y de laboratorio no coincidan. El laboratorio usa un solo dispositivo y una sola red; los datos de campo agregan muchos. Usa el laboratorio para encontrar la causa y los datos de campo para confirmar la solución.

Resultado: una tabla de línea de base con cada métrica, su valor de campo actual, su valor de laboratorio y su estado de aprobado o no aprobado para [Fecha].

Correcciones de Largest Contentful Paint (LCP)

Cuándo usarla: Diagnostique y corrija un LCP lento para que el elemento de contenido principal se renderice en 2,5 segundos para la mayoría de los visitantes.

Haga que el contenido principal aparezca rápido

LCP mide cuándo termina de renderizarse el elemento visible más grande (normalmente una imagen hero, un póster de video o un bloque de encabezado). El objetivo es <=2,5 s en el percentil 75. Identifique el elemento LCP en Lighthouse y luego ataque las cuatro fases que lo retrasan.

1. Tiempo hasta el primer byte: reduzca la respuesta del servidor para [Origin] con almacenamiento en caché, un host más rápido o renderizado en el edge.
2. Recursos que bloquean el renderizado: aplace el CSS y JavaScript no críticos para que el navegador pueda pintar antes.
3. Retraso en la carga del recurso: agregue preload para la imagen LCP y establezca [fetchpriority=high] en ella para que el navegador la descargue pronto.
4. Retraso en el renderizado del recurso: asegúrese de que la imagen LCP no se cargue de forma diferida y se sirva en un formato moderno con el tamaño correcto.

Evite cargar la imagen hero mediante un fondo CSS o JavaScript del lado del cliente, ya que el navegador la descubre demasiado tarde. Una imagen referenciada directamente, precargada y con el tamaño correcto casi siempre gana.

Verificar: vuelva a ejecutar Lighthouse y confirme que el elemento LCP y su cronograma de carga para [Page URL] bajaron de 2,5 s.

Correcciones de Interaction to Next Paint (INP)

Cuándo usarla: Mejore la capacidad de respuesta para que la página reaccione rápidamente a los clics, toques y pulsaciones de teclas, reemplazando la métrica FID anterior.

Haga que las interacciones se sientan instantáneas

INP reemplazó a FID como Core Web Vital en marzo de 2024. Mide la latencia de las interacciones durante toda la visita a la página e informa aproximadamente la peor. El objetivo es <=200 ms. Un INP deficiente casi siempre se debe a que JavaScript acapara el hilo principal cuando el usuario actúa.

• Encuentre tareas largas: use el panel Rendimiento de DevTools para detectar tareas del hilo principal de más de 50 ms durante la interacción en [Page URL].
• Divida JavaScript: divida las tareas largas en partes más pequeñas y ceda al hilo principal para que la entrada pueda procesarse.
• Reduzca el trabajo del hilo principal: elimine o aplace scripts no utilizados, especialmente etiquetas pesadas de terceros como [Tag name].
• Optimice los controladores de eventos: aplique debounce al trabajo costoso y aplace las actualizaciones no urgentes hasta después de la siguiente pintura.
• Minimice el tamaño del DOM y el coste de diseño: un DOM grande o profundamente anidado encarece cada interacción.

El objetivo es mantener el hilo principal libre cuando los usuarios hacen clic y tocan, para que el navegador pueda pintar una respuesta dentro del presupuesto de 200 ms.

Verificar: pruebe interacciones reales y confirme que el INP de campo tienda hacia bueno para [Property].

Correcciones de Cumulative Layout Shift (CLS)

Cuándo usarla: Evite que el contenido salte durante la carga para que el diseño se mantenga visualmente estable por debajo de un CLS de 0,1.

Evite que el diseño salte

CLS mide los cambios inesperados de diseño del contenido visible durante la vida útil de la página. El objetivo es <=0,1. Los cambios frustran a los usuarios y provocan clics erróneos, y casi siempre provienen de elementos que cargan sin espacio reservado.

• Dimensione sus medios: establezca siempre atributos de ancho y alto (o una relación de aspecto CSS) en imágenes, videos e iframes para que el navegador reserve espacio antes de que carguen.
• Reserve espacio para incrustaciones y anuncios: dé a los espacios de [Ad or embed] un contenedor con altura mínima fija para que no empujen el contenido hacia abajo.
• Nunca inserte contenido encima del contenido existente: evite inyectar banners, avisos o barras de cookies que desplacen la página hacia abajo después del renderizado.
• Evite cambios por intercambio de fuentes: precargue las fuentes clave y use [font-display] con prudencia para limitar el reflujo.
• Reserve espacio para la interfaz dinámica: mantenga espacio para los elementos agregados por JavaScript para que se expandan en un espacio preasignado.

Trate cualquier "salto" que pueda ver durante la carga como un defecto que debe eliminar.

Verificar: observe la tira de película de carga y confirme que no haya cambios visibles en [Page URL].

Optimización de recursos y entrega

Cuándo usarla: Recorte y acelere los recursos que envía una página, como imágenes, JavaScript, CSS, almacenamiento en caché y CDN, para mejorar todas las métricas a la vez.

Envíe menos, entregue más rápido

La mayoría de los problemas de velocidad de página se reducen a enviar demasiados bytes o enviarlos demasiado lentamente. Optimizar la entrega mejora LCP, INP y CLS en conjunto porque el navegador tiene menos que descargar, analizar y ejecutar.

• Imágenes: sirva formatos modernos (como WebP o AVIF), ajústelas a las dimensiones mostradas y comprímalas; cargue de forma diferida solo las imágenes de la mitad inferior de la página, nunca la imagen LCP.
• JavaScript: minifique, haga tree-shaking y divida el código para que cada página cargue solo lo que necesita; aplace o cargue de forma asíncrona los scripts no críticos.
• CSS: minifique, elimine reglas no utilizadas e inserte en línea el CSS crítico para el contenido de la mitad superior de la página en [Template].
• Almacenamiento en caché: establezca vidas útiles prolongadas de caché para recursos estáticos y use nombres de archivo con huella digital para que las actualizaciones invaliden la caché de forma segura.
• CDN: sirva recursos desde ubicaciones edge cercanas a los usuarios y habilite la compresión (Brotli o gzip) en [CDN provider].

Audite sin piedad los scripts de terceros, ya que son una causa común y oculta de cargas lentas y mala capacidad de respuesta.

Verificar: compare el tamaño total de transferencia y el recuento de solicitudes antes y después para [Page URL].

Vuelva a probar y supervise

Cuándo usarla: Confirme que las correcciones funcionaron en los datos de campo y configure una supervisión continua para detectar regresiones a tiempo.

Confirme la victoria y consérvela

Una corrección no está terminada hasta que los datos de campo la confirmen. Debido a que CrUX utiliza una ventana continua de 28 días, las mejoras de usuarios reales tardan en aparecer, así que valide en dos etapas: primero en laboratorio para obtener comentarios instantáneos y luego en campo durante las semanas siguientes.

1. Vuelva a ejecutar las pruebas de laboratorio: use Lighthouse o PageSpeed Insights para confirmar que el problema a nivel de traza en [Page URL] está resuelto.
2. Observe los datos de campo: haga seguimiento de CrUX en el informe Core Web Vitals de Search Console y espere a que se actualice la ventana de 28 días antes de declarar el éxito.
3. Establezca objetivos: mantenga cada grupo de URL en LCP <=2,5 s, INP <=200 ms, CLS <=0,1 en el percentil 75.
4. Supervise continuamente: agregue monitoreo de usuarios reales (RUM) o auditorías programadas para [Property] para que las regresiones afloren rápido.
5. Protéjase contra la deriva: vuelva a auditar después de lanzamientos importantes, nuevas etiquetas de terceros o cambios de plantilla.

El rendimiento no es un proyecto de una sola vez; trátelo como un presupuesto continuo que defiende con cada despliegue.

Resultado: un informe de antes/después y una cadencia de supervisión anotada para [Date].