Refresh rate test

How the measurement works

Before it draws each frame, a browser calls the animation callbacks a page has registered and hands them the time the frame started. This page registers one, does nothing else with it, and keeps the time between one call and the next. On most browsers and systems the calls follow the display: one per refresh, for the screen the window is on. That makes counting them a good stand-in for the display's current mode, measured from inside the browser.

The refresh rate on the big readout is worked out over the last five seconds: the refreshes that passed, frames drawn plus frames missed, divided by the time they took. Averaging over thousands of frames is what keeps it exact where single frames are not. Some browsers round each timestamp to a millisecond, which alone makes a 144 Hz frame look like 6 or 7 ms, yet the average still lands on 144. The named rate underneath compares the reading with the rates displays are sold at. It says "matches" within half a percent, and "close to" within three.

No rate is shown until thirty frames stand behind it, and the first second after the page loads, or after a hidden tab comes back, is left out of the dropped frame count, because a browser that is still starting up runs unevenly. The summary at the bottom fills in after about three seconds of steady measurement and then updates once a second. If you change the screen's mode, the readings follow within five seconds, and Restart measurement throws everything away and begins again.

How to read the numbers

• Refresh rate: how often your browser is drawing a new frame, in hertz. Real modes are rarely round: many "60 Hz" screens run at 59.94, and a "144 Hz" mode often reads 143.98 or 144.0. That small gap is normal.
• Average frame rate: frames actually drawn each second. It equals the refresh rate while nothing is dropped and falls below it when frames are missed.
• Median frame time: the middle one of the recent times between frames, so a few slow frames don't move it. It is 1000 divided by the rate: 16.67 ms at 60 Hz, 6.94 ms at 144 Hz, 4.17 ms at 240 Hz.
• Jitter: how much the frame times of on-time frames vary, as a standard deviation. On a browser with a fine clock, a steady display usually stays under half a millisecond. A clock that rounds to a millisecond adds up to about half a millisecond of its own.
• Dropped frames: refreshes that passed with no new frame. A gap about twice the median counts as one, three times as two. Under half a percent of refreshes looks smooth, and over three percent shows as stutter.

On the graph, a steady display is a flat line inside the amber band. A line that wanders between levels instead of sitting on the median means the rate is changing, as with variable refresh rate, or that the computer is busy. Red bars are frames that were dropped, and the taller the bar, the longer the wait.

Why the reading can be lower than your display's setting

The page reports what the browser renders. Several things sit between that and the rate on the monitor's box:

• The window is on another screen. Frames follow the display the window is on. Drag it fully onto the monitor you want to test and reload the page. A window split across two screens follows one of them.
• The system is set lower. Each display has its own refresh rate in the system settings, and a new monitor often starts at 60 Hz. A cable or port with too little bandwidth can hide the higher choices.
• Safari's 60 fps limit. Safari, and every browser on iPhone and iPad because they use the same engine, can hold pages to 60 frames a second on faster screens. In Safari's feature flags, turning off "Prefer Page Rendering Updates Near 60fps" lifts it. If this browser reads 60 and your screen is faster, try a different browser on the same computer.
• Power saving. Low Power Mode on iPhone, iPad and Mac, battery saver on Windows and Chromebooks, a browser's energy saver, and a laptop lowering its panel on battery all hold pages to 30 or 60 frames a second.
• A background tab. Browsers slow or stop animation in a tab you can't see. The measurement pauses when the tab is hidden and starts fresh when you're back, so the time away never counts as a slow frame.
• Variable refresh rate. With G-Sync, FreeSync, Adaptive-Sync or ProMotion, a display changes its rate to follow what is on screen. A page that draws every frame usually holds it near the top of the range, but the system may lower it, and the reading can drift or land between the usual rates.
• A limit in the browser or the compositor. Switched-off hardware acceleration, a frame rate cap set by a flag or a command line option, and a remote desktop or screen capture in use can all hold frames to a lower rate.

What the browser can and can't tell

A page can time the frames it draws. It can't ask the monitor for its maximum refresh rate, its variable refresh range or its overclock, and it can't see the frames that reach the panel. So a reading above what you expected is genuine, and one below it means the browser is drawing slower, not that the panel can't go faster. The summary lists the maximum rate and the variable refresh range as not tested for that reason.

Refresh rate is also not response time. The rate is how often the picture can change, and how quickly pixels finish changing is a separate property, which the motion blur test looks at.

The frame skipping check

A browser can draw every frame while the display still skips some, which can happen when a monitor is overclocked past what it handles. Only a camera sees that. The optional check lights one cell of a row per frame. Photograph it with a shutter speed of about a tenth of a second, and a run of lit cells with no gap means the display showed every frame. It flickers quickly, so it starts only when you press its button, and a warning comes first.