fix: align frozen frame threshold with Android Vitals (700ms) - #142
Merged
yduartep merged 7 commits intoAug 14, 2026
Merged
Conversation
Raise the default frozen frame threshold from 100ms to 700ms to match Android Vitals and OpenTelemetry Android slow rendering instrumentation. Stop emitting duplicate app_frozen_frame measurements on Android by reporting slow and frozen frames through polling only. Co-authored-by: Cursor <cursoragent@cursor.com>
aranhave
reviewed
Jul 30, 2026
aranhave
left a comment
aranhave
left a comment
Contributor
There was a problem hiding this comment.
Nice update! 🔥 Just left a few small questions.
| - Filters out noise and reports user-perceptible jank | ||
| - **Frozen Frame Detection**: Individual frames exceeding threshold | ||
| - Default: 100ms | ||
| - Default: 700ms |
Contributor
There was a problem hiding this comment.
Should we update the example below too? It shows two frozen frames with frozen_duration: 450.5, which isn't possible once each frozen frame must exceed 700ms.
Contributor
Author
There was a problem hiding this comment.
Fixed in bfdb40c: the invalid frozen_duration: 450.5 example was removed along with the docs/mobile-rum/ comparison docs.
Snapshot frozen count and duration atomically on Android/iOS, add polling regression tests, extract default frame constants, remove cross-SDK comparison docs, and drop Flutter comparison comments from the RN SDK. Co-authored-by: Cursor <cursoragent@cursor.com>
Document that frozen/slow frame monitoring guidance will live in frontend-o11y-knowledge-workbench once that epic is complete. Co-authored-by: Cursor <cursoragent@cursor.com>
Break the cross-SDK documentation line to satisfy the 80-character markdownlint limit in CI. Co-authored-by: Cursor <cursoragent@cursor.com>
Re-add the Documentation section accidentally dropped in the markdownlint README fix commit. Co-authored-by: Cursor <cursoragent@cursor.com>
…e-threshold-with-android-vitals # Conflicts: # docs/mobile-rum/feature-parity-matrix.md # docs/mobile-rum/index.md
aranhave
reviewed
Jul 31, 2026
aranhave
left a comment
aranhave
left a comment
Contributor
There was a problem hiding this comment.
Thanks for working through the earlier feedback. I found three things that still need a look: the frozen-metric race, the demo timing and the public docs move.
Record and snapshot frozen count/duration under the same lock on Android and iOS, update demo heavy-load freezes to 750ms, and document frame monitoring in the public package README instead of removed comparison docs. Co-authored-by: Cursor <cursoragent@cursor.com>
aranhave
approved these changes
Aug 3, 2026
aranhave
left a comment
aranhave
left a comment
Contributor
There was a problem hiding this comment.
Thanks for working through these. The locking, demo timing, and public RN docs are all addressed now :) . LGTM 👍
yduartep
deleted the
fix/align-frozen-frame-threshold-with-android-vitals
branch
August 14, 2026 06:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The SDK previously treated any frame taking longer than 100ms as frozen. Industry tooling — including Android Vitals, OpenTelemetry Android slow rendering instrumentation, and common RUM competitors — uses 700ms as the frozen frame threshold (between slow jank at ~16ms and ANR at ~5s).
This PR aligns React Native frame monitoring with that standard and fixes duplicate reporting on Android.
Frozen frame threshold: 100ms → 700ms
Updated the default
frozenFrameThresholdMsacross the full stack:FrameMonitoringInstrumentation)FrameMonitor,FaroReactNativeModule)RefreshRateVitals,FaroReactNativeModule)The threshold remains configurable via
frameMonitoringOptions.frozenFrameThresholdMs.Effect: frames between 100ms and 700ms are no longer reported as
app_frozen_frame. They may still appear as slow frame events inapp_frames_ratewhen they meet the slow-frame grouping rules.Android: polling-only reporting for frozen/slow frames
On Android, frozen frames were previously reported twice:
onFrozenFramenative eventgetFrameMetrics()Slow frames already avoided this — native emitted
onSlowFrames, but JS never listened and only polled.This PR makes frozen frames consistent with slow frames and iOS: native accumulates metrics; JS polls every
refreshRatePollingInterval(default 30s) and emitsapp_frozen_frameonly whenfrozenFrames > 0. No zero-count payloads are sent.Android refresh rate events (
onRefreshRate) are unchanged.Documentation
Updated mobile RUM docs and demo copy to reflect the 700ms default and polling-based Android reporting.
Made with Cursor