HTMLツール

無料 PerformanceObserverスニペットジェネレーター

good/needs-improvement/poor閾値付きでCore Web Vitals（LCP、INP、CLS）のPerformanceObserverコードを生成します。

ツールを読み込み中...

PerformanceObserverスニペットジェネレーターとは

PerformanceObserver is a browser API that allows developers to observe performance measurement events in real-time. Instead of polling the performance timeline or relying on manual timing measurements, PerformanceObserver subscribes to specific entry types (like largest-contentful-paint, layout-shift, first-input, paint, and navigation) and receives entries as they are recorded. This is the standard approach recommended by the Web Performance Working Group for measuring Core Web Vitals. The API supports a buffered flag that returns historical entries immediately upon registration, ensuring you do not miss metrics that fire before your observer is set up. Baseline 2025, supported in Chrome 73+, Edge 73+, Safari 14.1+, and Firefox 84+.

クイックアンサー

PerformanceObserver provides real-time Core Web Vitals monitoring (LCP, INP, CLS, FID, FCP, TTFB) through an efficient observer pattern with buffered entry support. Classify each metric against Google good/needs-improvement/poor thresholds and optionally report via navigator.sendBeacon for reliable analytics delivery. Baseline 2025 (Chrome 73+, Safari 14.1+, Firefox 84+). More efficient than polling and the recommended approach for production Web Vitals measurement.

制限事項

PerformanceObserver entries do not persist across page navigations -- each page load starts with a fresh timeline. For SPA route changes, observers must be reconnected manually to continue tracking metrics on the new route.
Some performance entry types have browser-specific availability or behavior. For example, layout-shift entries are not available in all browsers (Firefox added support in version 134), and INP observation requires Chrome 121+ or Safari 18+. Always check for support before registering observers.
PerformanceObserver has a limited buffer for each entry type. If the buffer fills before the observer is registered and buffered: true is not set, older entries may be discarded. Register observers early in the page load lifecycle and use buffered: true to capture entries that fired during the critical rendering path.

使い方

Select the performance metrics to observe: Core Web Vitals (LCP, INP, CLS, FID, FCP, TTFB) or individual entry types like paint, layout-shift, largest-contentful-paint, first-input, and navigation.
Configure threshold classification: each metric is automatically classified as good, needs-improvement, or poor based on Google Web Vitals thresholds. Optionally customize the thresholds for your specific requirements.
Choose a reporting method: log results to the console, send data via navigator.sendBeacon to an analytics endpoint, or provide a custom callback function for integration with your existing monitoring.
Copy the generated JavaScript snippet. The output includes a complete PerformanceObserver setup with multiple observers, buffered entry support, threshold classification, and optional sendBeacon reporting.

主な用途

Track Core Web Vitals in production and report them to an analytics endpoint using sendBeacon for reliable, non-blocking data transmission even during page unload.
Monitor LCP in real-time during development to verify that performance optimizations (image compression, font loading, lazy loading) are actually reducing LCP times.
Detect unexpected layout shifts (CLS) on a live site by logging every layout-shift entry with its shift score and affected nodes, helping identify the source of cumulative layout shifts.

用途

使用例

例

Production Core Web Vitals monitoring with sendBeacon

An e-commerce site deploys the generated PerformanceObserver snippet on its product pages. The observer tracks LCP, INP, CLS, FCP, and TTFB. Each metric is classified against Google thresholds: good LCP under 2500ms, needs-improvement 2500-4000ms, poor over 4000ms. Metrics are sent via navigator.sendBeacon to /analytics/cwv every 30 seconds. The team sets up dashboard alerts when any page exceeds 10 percent poor LCP or poor CLS over 0.25.

例

Development LCP debugging with detailed logging

A developer working on image optimization adds a PerformanceObserver for largest-contentful-paint entries with console logging. Each LCP entry shows the element tag, its URL for images, render time, and size. By comparing LCP entries before and after switching to next-gen formats and adding fetchpriority=high to the hero image, the developer confirms a 40 percent reduction in LCP time.

よくあるミス

Registering PerformanceObserver after page load without the buffered flag -- metrics like FCP and TTFB fire before most JavaScript executes. Always set buffered: true in the observer options to receive historical entries that were recorded before the observer was registered.
Observing layout-shift entries without checking hadRecentInput -- many layout shifts occur during user interaction (typing, clicking, resizing) and should not count toward CLS. Filter out entries where hadRecentInput is true to match the Google CLS definition.
Sending performance data synchronously on page unload instead of using sendBeacon -- regular fetch or XHR requests during unload may be cancelled by the browser. navigator.sendBeacon guarantees delivery by using the browser background processing queue.

検証

Open the generated HTML in Chrome DevTools on a page with sufficient content. Open the console and verify that PerformanceObserver logs each registered metric with its value, classification (good/needs-improvement/poor), and entry type. Scroll down, interact with the page, and confirm that INP and CLS entries appear after user interaction.
Configure the observer to use sendBeacon reporting and provide a valid endpoint URL. Load the page, then check the Network tab in DevTools for a beacon request containing performance data. Verify that the payload includes metric names, values, threshold classifications, and a timestamp.

FAQ

PerformanceObserverスニペットジェネレーターのFAQ

What performance metrics can PerformanceObserver monitor besides Core Web Vitals?

PerformanceObserver supports over 15 entry types including mark, measure, resource, navigation, paint, largest-contentful-paint, first-input, layout-shift, longtask, element, visibility-state, and event for INP. The generated snippet focuses on Core Web Vitals but you can extend it to observe any supported entry type by adding the appropriate type string to the observed entry types list.

How does PerformanceObserver handle multiple observers for the same metric type?

Multiple PerformanceObserver instances can observe the same entry type simultaneously without conflicts. Each observer receives a copy of the entries independently. This is useful for separating concerns -- for example, one observer sends data to analytics while another logs detailed debug information to the console. Each observer must be disconnected individually via observer.disconnect() when no longer needed.

Do PerformanceObserver entries persist across page navigations in a SPA?

No. PerformanceObserver entries are collected per navigation and cleared when the page is navigated away from. In single-page applications using client-side routing, you must reconnect observers after each route change. The generated snippet includes a helper function that reconnects all observers on route change events. For cross-origin navigations, performance entries from the previous page are not accessible.

What are the good/needs-improvement/poor thresholds used by the generated code?

The thresholds follow Google Web Vitals guidelines. LCP under 2500ms is good, 2500-4000ms needs improvement, over 4000ms is poor. FID under 100ms is good, 100-300ms needs improvement, over 300ms is poor. CLS under 0.1 is good, 0.1-0.25 needs improvement, over 0.25 is poor. INP under 200ms is good, 200-500ms needs improvement, over 500ms is poor. FCP follows LCP thresholds (2500ms/4000ms). TTFB under 800ms is good, 800-1800ms needs improvement, over 1800ms is poor. All thresholds are configurable in the generated snippet.