Herramientas HTML

Gratis Generador de snippet PerformanceObserver

Genere codigo PerformanceObserver para Core Web Vitals (LCP, INP, CLS) con umbrales good/needs-improvement/poor.

Cargando herramienta...

Qué es Generador de snippet PerformanceObserver?

PerformanceObserver es una API del navegador que permite a los desarrolladores observar eventos de medición de rendimiento en tiempo real. En lugar de sondear la línea de tiempo de rendimiento o depender de mediciones de tiempo manuales, PerformanceObserver se suscribe a tipos de entrada específicos (como largest-contentful-paint, layout-shift, first-input, paint y navigation) y recibe las entradas a medida que se registran. Este es el enfoque estándar recomendado por el Web Performance Working Group para medir Core Web Vitals. La API soporta una bandera buffered que devuelve entradas históricas inmediatamente al registrarse, asegurando que no se pierdan métricas que se disparan antes de que el observer esté configurado. Baseline 2025, compatible con Chrome 73+, Edge 73+, Safari 14.1+ y Firefox 84+.

Respuesta rápida

PerformanceObserver proporciona monitoreo en tiempo real de Core Web Vitals (LCP, INP, CLS, FID, FCP, TTFB) mediante un patrón observer eficiente con soporte de entradas almacenadas en búfer. Clasifique cada métrica según los umbrales bueno/mejorable/malo de Google y opcionalmente reporte mediante navigator.sendBeacon para entrega confiable de analítica. Baseline 2025 (Chrome 73+, Safari 14.1+, Firefox 84+). Más eficiente que el sondeo y el enfoque recomendado para medición de Web Vitals en producción.

Last updated: 2026-06-02

Limitaciones

Las entradas de PerformanceObserver no persisten entre navegaciones de página: cada carga de página comienza con una línea de tiempo nueva. Para cambios de ruta en SPA, los observers deben reconectarse manualmente para continuar rastreando métricas en la nueva ruta.
Algunos tipos de entrada de rendimiento tienen disponibilidad o comportamiento específico del navegador. Por ejemplo, las entradas layout-shift no están disponibles en todos los navegadores (Firefox añadió soporte en la versión 134), y la observación de INP requiere Chrome 121+ o Safari 18+. Verifique siempre el soporte antes de registrar observers.
PerformanceObserver tiene un búfer limitado para cada tipo de entrada. Si el búfer se llena antes de que el observer se registre y buffered: true no está configurado, las entradas antiguas pueden descartarse. Registre los observers temprano en el ciclo de vida de carga de la página y use buffered: true para capturar entradas que se dispararon durante la ruta de renderizado crítico.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

Cómo usar esta herramienta

Seleccione las métricas de rendimiento a observar: Core Web Vitals (LCP, INP, CLS, FID, FCP, TTFB) o tipos de entrada individuales como paint, layout-shift, largest-contentful-paint, first-input y navigation.
Configure la clasificación de umbrales: cada métrica se clasifica automáticamente como buena, mejorable o mala según los umbrales de Google Web Vitals. Opcionalmente personalice los umbrales según sus requisitos específicos.
Elija un método de reporte: registre los resultados en la consola, envíe datos mediante navigator.sendBeacon a un endpoint de analítica, o proporcione una función callback personalizada para integración con su monitoreo existente.
Copie el fragmento JavaScript generado. La salida incluye una configuración completa de PerformanceObserver con múltiples observers, soporte de entradas almacenadas, clasificación de umbrales y reporte opcional mediante sendBeacon.

Para qué puedes usarla

Rastrear Core Web Vitals en producción y reportarlos a un endpoint de analítica usando sendBeacon para transmisión de datos confiable y no bloqueante incluso durante la descarga de página.
Monitorear LCP en tiempo real durante el desarrollo para verificar que las optimizaciones de rendimiento (compresión de imágenes, carga de fuentes, lazy loading) están realmente reduciendo los tiempos de LCP.
Detectar cambios de layout inesperados (CLS) en un sitio en vivo registrando cada entrada de layout-shift con su puntuación y nodos afectados, ayudando a identificar la fuente de los cambios de layout acumulativos.

Casos de uso

Ejemplos prácticos

Ejemplo

Monitoreo de Core Web Vitals en producción con sendBeacon

Un sitio de comercio electrónico implementa el fragmento PerformanceObserver generado en sus páginas de producto. El observer rastrea LCP, INP, CLS, FCP y TTFB. Cada métrica se clasifica según los umbrales de Google: LCP bueno bajo 2500ms, mejorable 2500-4000ms, malo sobre 4000ms. Las métricas se envían mediante navigator.sendBeacon a /analytics/cwv cada 30 segundos. El equipo configura alertas en el panel cuando cualquier página excede el 10 por ciento de LCP malo o CLS malo sobre 0.25.

Ejemplo

Depuración de LCP en desarrollo con registro detallado

Un desarrollador que trabaja en optimización de imágenes añade un PerformanceObserver para entradas largest-contentful-paint con registro en consola. Cada entrada LCP muestra la etiqueta del elemento, su URL para imágenes, tiempo de renderizado y tamaño. Al comparar las entradas LCP antes y después de cambiar a formatos de nueva generación y añadir fetchpriority='high' a la imagen principal, el desarrollador confirma una reducción del 40 por ciento en el tiempo de LCP.

Errores comunes

Registrar PerformanceObserver después de la carga de la página sin la bandera buffered: métricas como FCP y TTFB se disparan antes de que la mayoría del JavaScript se ejecute. Establezca siempre buffered: true en las opciones del observer para recibir entradas históricas que se registraron antes de que el observer se registrara.
Observar entradas layout-shift sin verificar hadRecentInput: muchos cambios de layout ocurren durante la interacción del usuario (escribir, hacer clic, redimensionar) y no deberían contar para CLS. Filtre las entradas donde hadRecentInput es true para coincidir con la definición de CLS de Google.
Enviar datos de rendimiento sincrónicamente en la descarga de página en lugar de usar sendBeacon: las solicitudes fetch o XHR regulares durante la descarga pueden ser canceladas por el navegador. navigator.sendBeacon garantiza la entrega usando la cola de procesamiento en segundo plano del navegador.

Verificación

Abra el HTML generado en Chrome DevTools en una página con contenido suficiente. Abra la consola y verifique que PerformanceObserver registre cada métrica con su valor, clasificación (bueno/mejorable/malo) y tipo de entrada. Desplácese hacia abajo, interactúe con la página y confirme que aparezcan entradas INP y CLS después de la interacción del usuario.
Configure el observer para usar reporte sendBeacon y proporcione una URL de endpoint válida. Cargue la página, luego verifique en la pestaña Network de DevTools una solicitud beacon que contenga datos de rendimiento. Verifique que el payload incluya nombres de métricas, valores, clasificaciones de umbral y una marca de tiempo.

FAQ

Preguntas sobre Generador de snippet PerformanceObserver

¿Qué métricas de rendimiento puede monitorear PerformanceObserver además de Core Web Vitals?

PerformanceObserver soporta más de 15 tipos de entrada incluyendo mark, measure, resource, navigation, paint, largest-contentful-paint, first-input, layout-shift, longtask, element, visibility-state y event para INP. El fragmento generado se enfoca en Core Web Vitals pero puede extenderlo para observar cualquier tipo de entrada soportado añadiendo la cadena de tipo apropiada a la lista de tipos de entrada observados.

¿Cómo maneja PerformanceObserver múltiples observers para el mismo tipo de métrica?

Múltiples instancias de PerformanceObserver pueden observar el mismo tipo de entrada simultáneamente sin conflictos. Cada observer recibe una copia de las entradas independientemente. Esto es útil para separar preocupaciones: por ejemplo, un observer envía datos a analítica mientras otro registra información de depuración detallada en la consola. Cada observer debe desconectarse individualmente mediante observer.disconnect() cuando ya no sea necesario.

¿Persisten las entradas de PerformanceObserver entre navegaciones de página en un SPA?

No. Las entradas de PerformanceObserver se recopilan por navegación y se limpian cuando se navega fuera de la página. En aplicaciones de una sola página que usan enrutamiento del lado del cliente, debe reconectar los observers después de cada cambio de ruta. El fragmento generado incluye una función helper que reconecta todos los observers en eventos de cambio de ruta. Para navegaciones de origen cruzado, las entradas de rendimiento de la página anterior no son accesibles.

¿Cuáles son los umbrales bueno/mejorable/malo usados por el código generado?

Los umbrales siguen las guías de Google Web Vitals. LCP bajo 2500ms es bueno, 2500-4000ms mejorable, sobre 4000ms malo. FID bajo 100ms es bueno, 100-300ms mejorable, sobre 300ms malo. CLS bajo 0.1 es bueno, 0.1-0.25 mejorable, sobre 0.25 malo. INP bajo 200ms es bueno, 200-500ms mejorable, sobre 500ms malo. FCP sigue los umbrales de LCP (2500ms/4000ms). TTFB bajo 800ms es bueno, 800-1800ms mejorable, sobre 1800ms malo. Todos los umbrales son configurables en el fragmento generado.

Herramientas relacionadas