What the four seconds are measuring
Press start and the page asks the browser for animation frames, then times the gaps between the timestamps the browser hands to each callback. MDN describes that argument as a DOMHighResTimeStamp, 'a decimal number, in milliseconds, but with a minimal precision of 1 millisecond', on the same time origin that performance.now() reports. The same page explains what requestAnimationFrame does with the callback: it asks the browser to call it 'before the next repaint', and 'the frequency of calls to the callback function will generally match the display refresh rate'. One callback therefore arrives for each screen refresh, so the gap between two of them is one frame period. A 60Hz panel hands out a callback about every 16.7 ms and a 144Hz panel about every 6.9 ms, and a 1 ms floor on the timestamp is small next to either.
The reading is the median of those gaps, converted with rate = 1000 / period. Frame gaps have a long tail on one side and none on the other, because a browser can present a frame late but never before the panel is ready for it. A mean would let a handful of late frames pull the number down, so the tool goes with the median, drops any frame arriving later than 2.5 times it, and counts those separately as slow frames. Nothing is averaged across page loads or stored: the four-second window runs once, in this tab, and the numbers are gone when it closes.
Why the reading can sit below the number on the box
What the browser receives is the mode the operating system is driving at that moment, which is not automatically the panel's ceiling. MDN's wording leaves room for that: the callback frequency will 'generally' match the display refresh rate, not always. If the system is running a 165Hz panel in a 60Hz mode, the browser gets 60Hz callbacks and this page reports 60. A reading under the specification therefore describes the mode in force, and says nothing about the hardware's ceiling. Telling those two apart is a job for the operating system's display settings, which this page never sees.
That is why the closest standard rate is printed alongside the raw figure, which stays visible. A reading of 59.8 Hz against a 60Hz setting is measurement noise, and the tool says so by flagging it a match. A reading of 47 Hz is not close to anything, and the flags say that too.
One case the tool handles and does not report: if the tab is not in front, MDN notes that "requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden iframes". A paused stream of callbacks would look like a catastrophically slow display, so the measurement is abandoned if the tab goes to the background, and it will not start at all in a hidden tab.
Reading the spread, not just the headline number
A single rate hides the shape of the frame stream, and two displays can produce the same median from very different streams. The table under the reading lists the most common frame periods in the sample, rounded to a tenth of a millisecond. An alternating pattern is visible there: a display presenting at 120Hz while the browser acts on roughly half of those refreshes shows up as 8.3 ms and 16.7 ms gaps in roughly equal numbers.
The 95th percentile fills in the other half. On a steady display it sits close to the median and the flag reads steady; when it is well above the median, frames are arriving unevenly, and the tool reports the ratio so the size of that gap is a number you can read. Uneven frames have more than one cause, and the page does not pretend to settle which one applies. A variable refresh display produces them by design when the rendered content needs less than the maximum rate, and a machine that cannot keep up produces them too. The dropped-frame count separates the two: a steady median with a growing pile of dropped frames points at the machine, while a median that never settles on a tenth of a millisecond points at the display.
What this page cannot measure
The panel ceiling is out of reach. The browser is told what mode it is in, never the highest one the hardware supports, so a 240Hz monitor running at 60 looks exactly like a 60Hz monitor from in here.
Frame rate is a different figure, and also invisible from here. Wikipedia's entry on refresh rate defines the term as "the number of times per second that a raster-based display device displays a new image" and adds that it "can be independent of frame rate", which describes how many images the device driving the display generates each second. A game rendered at 40 frames per second on a 144Hz panel produces 144 refreshes and 40 new images, and a web page has no window into the second number.
The reading also describes the browser rather than the whole machine. If the browser is limited by its own throttling while another program hogs the processor, the gaps grow and the measurement says so. That is a real observation about the frame stream, but it is not a statement about the panel, which is why the tool counts the slow frames out loud and shows that count beside the rate.
Worked examples
A median gap of 16.67 ms gives 1000 / 16.67 = 60.0 Hz, which lands on the 60Hz standard rate and is flagged a match. The same conversion runs the other way in Wikipedia's "Refresh rate" article, checked 2026-10-16, which records one monitor at 144 Hz reducing frame persistence to approximately 6.9 ms against 16.7 ms at 60 Hz.
Medians of 13.33 ms, 8.33 ms and 6.94 ms come out at 75.0, 120.0 and 144.1 Hz. The last of those sits 0.06% above 144, which is inside the tolerance the tool allows before it stops calling a reading a match.
A 60Hz display that misses one refresh in three hands the browser gaps of about 16.7 ms and 33.3 ms in equal numbers. The median of that mix is 25 ms, so the page reports 40 Hz, and the 95th percentile lands at 33.3 ms. That reading is not an error even though the panel is running at 60Hz: 40 frames per second is what the browser is actually being given.