What the result means
The number is an effective browser-observed estimate.
requestAnimationFrame normally runs before a repaint, so its callback timing is useful for estimating the cadence delivered to this page. It is not a direct read of panel firmware, EDID, or a laboratory refresh-rate sensor.
Browser and system behavior can change the reading.
Compositor scheduling, CPU/GPU load, power saving, multiple monitors, variable-refresh behavior, and background throttling can all affect the callback sequence. Timing spread is shown as context rather than turned into a fake hardware score.
The timing data stays local.
BeanNest does not send measured Hz, frame intervals, sample timestamps, timing spread, display dimensions, or a monitor identity to analytics. The sample disappears when you reload or close the page.
Why does the number move at first?
The tool intentionally warms up and collects enough visible frames before calling the estimate stable. Early callback timing is more easily affected by page startup and scheduling noise.
Why is my result lower than the monitor's advertised Hz?
Check the active operating-system display mode first. Then consider browser workload, power settings, multi-monitor composition, cable/input limitations, and whether the panel is currently using a different mode.
Can this prove an exact hardware refresh rate?
No. It estimates the repaint cadence presented to this foreground browser page. Hardware certification requires information and measurement outside the normal web-page sandbox.
What happens when I switch tabs?
The current sample is invalidated. When the page becomes visible again BeanNest starts a fresh warm-up window so the hidden-tab pause is not reported as display timing.
