Overview#
Flashduty RUM supports collecting and reporting Web Vitals-related performance metrics to help you comprehensively monitor and optimize website performance. Through these metrics, you can understand the actual experience of users when visiting your website and make targeted optimizations.Web Vitals Metrics Overview#
Largest Contentful Paint (LCP): Measures the loading performance of the main content
Interaction to Next Paint (INP): Measures overall interaction responsiveness
Cumulative Layout Shift (CLS): Measures visual stability
First Contentful Paint (FCP): Measures the time of first content rendering
In addition to core metrics, it also supports other auxiliary metrics:First Input Delay (FID): Measures page interactivity
Time to First Byte (TTFB): Measures server response speed
These metrics are automatically collected when users visit pages and reported to the Flashduty platform through the SDK. You can view detailed performance data in the analysis dashboard.Interaction to Next Paint and Largest Contentful Paint are not collected for pages opened in the background (for example, in a new tab or a window without focus).
Metric Calculation Methods#
1. Largest Contentful Paint (LCP)#
Calculation: The time from page load start (navigationStart
) to the rendering completion of the largest visible content element (such as images, text blocks).
Use case: Monitor loading speed of homepages or key pages, identify resource loading bottlenecks.
2. First Contentful Paint (FCP)#
Calculation: Measures the time from when a user first navigates to a page until any part of the page's content is rendered on the screen.
Use case: Used to measure perceived loading speed, helps reassure users that something is happening.
3. Interaction to Next Paint (INP)#
Calculation: Measures the delay time from all user interactions (clicks, taps, keyboard inputs) to the next frame rendering.
Use case: Evaluate overall interaction responsiveness of the page, optimize high-latency interaction scenarios.
4. Cumulative Layout Shift (CLS)#
Calculation: Calculates the score of all unexpected layout shifts (shift distance × impact area).
Use case: Identify page jumps caused by dynamic content or advertisements.
Calculation: The time difference from the user's first interaction to when the browser processes the event.
Use case: Optimize response speed for interaction-intensive pages (such as forms, navigation menus).
Monitoring Single Page Applications (SPA)#
For Single Page Applications (SPA), the RUM browser SDK distinguishes between two navigation types through the loading_type
attribute: initial_load
and route_change
.1.
History Single Page Applications
If an interaction on a webpage causes the URL to change but the page does not refresh completely, the RUM SDK will start a new view
using loading_type:route_change
. RUM uses the History API to track URL changes. 2.
Hash Single Page Applications
The RUM SDK automatically monitors frameworks that rely on hash (#
) navigation. The SDK listens for HashChangeEvent
and issues a new view
. Events from HTML anchors that do not affect the current view context are ignored.
For SPA applications, if you need to monitor performance after route changes, it is recommended to use the Custom Performance Monitoring feature to measure performance metrics of specific components or interactions.Use the customVital
API to monitor the performance of specific components or interactions, suitable for:Critical component rendering time.
User interaction response time.
Business process duration.
Example: Measuring Component Rendering#
Example: Directly Report Duration#
Use the addTiming
API to record key timestamps, suitable for:Loading of critical elements (such as first-screen images).
User's first interaction (such as first scroll).
Business node timestamps.
Example: Asynchronous Scenario#
Considerations#
1. Naming Conventions#
Avoid spaces and special characters in metric names.
Use descriptive naming (such as login_form_render
).
Maintain naming consistency.
Control the number of custom metrics.
Set sampling rates reasonably.
Common Issues#
1. Abnormal Page Loading Time#
Check slowly loading resources (images, scripts).
Investigate third-party script blocking.
Analyze long-running JavaScript.
2. Inaccurate Activity Status Determination#
Confirm whether there are frequent background requests.
Check the handling of long connections or streaming requests.
Use excludedActivityUrls
to exclude interference.
3. Custom Metrics Issues#
Verify that metric names comply with conventions.
Ensure timers are started and stopped correctly.
Check timestamp accuracy in asynchronous scenarios.
4. Empty Web Vitals Metrics Collection#
Background pages: Pages opened in new tabs or unfocused windows, causing INP and LCP to be uncollectable
SPA route changes: During loading_type:route_change
, Core Web Vitals metrics (LCP, CLS, INP, FCP) will not be re-collected
Integration method: Page loads completely before SDK is fully initialized
Page lifecycle: Page is closed or navigated away before metrics collection is complete
Browser compatibility: Older browser versions do not support certain Web Vitals APIs
Empty page content: Page has no measurable content elements (such as blank pages)
Next Steps#