Why a 144 Hz Monitor Can Test at 60 Hz in a Browser
Understand browser refresh-rate results, read median and P95 frame intervals, and investigate why a high-refresh display can show a lower animation cadence.
You open a refresh-rate test on a monitor advertised as 144 Hz, press Start, and receive a result close to 60 Hz. The obvious suspicion is that the screen is configured incorrectly. That is one possibility, but the browser result alone cannot establish it. The page observes how often its animation callbacks arrive. It does not query the panel electronics or watch every physical screen refresh.
That distinction changes the investigation. A useful test should help you separate the display configuration, the browser's animation schedule, and the cost of rendering a particular scene. Treating those three as the same measurement can lead you to change unrelated settings or blame a healthy GPU.
This guide explains how to read the browser refresh-rate test, work through a repeatable comparison, and decide which additional evidence you need. The numerical examples are illustrative calculations, not measurements from a particular monitor or graphics card.
Three rates that answer different questions
Start by writing down what each number describes. A monitor's advertised maximum refresh rate tells you about a supported display mode under suitable conditions. The refresh rate currently selected by the operating system describes the configuration in use. Neither number is automatically the frequency at which every web page will update its animation.
The browser test measures intervals between requestAnimationFrame callbacks. These callbacks ask the browser for an opportunity to update an animation before a repaint. Their frequency generally follows display refresh, while background tabs are commonly paused. This makes them useful for observing animation cadence, with limits that matter when interpreting the result. MDN documents this callback behavior.
The Volume Shader BM Test adds a third quantity: the rate at which a specific WebGL rendering workload completes while following browser frame callbacks. It runs a more demanding scene than the small moving marker in the refresh-rate tool. A device might schedule that marker frequently while completing the shader workload less frequently.
For example, imagine a system configured for 144 Hz, a light browser animation measuring about 144 callbacks per second, and a shader run averaging 45 FPS. Those numbers can coexist. The shader result does not redefine the monitor's mode, and the light-animation result does not promise that every rendered scene will reach 144 FPS. Each observation belongs to its own workload and measurement method.
What the six-second test actually does
The refresh-rate tool runs an animation for approximately six seconds of callback time. It allows one second for warm-up, then collects about five seconds of consecutive callback intervals. The moving marker gives you visible confirmation that animation is progressing; the interval statistics come from callback timestamps.
During collection, keep the page visible and leave the window on the display you want to investigate. Avoid moving or resizing it partway through a run. Otherwise, your result combines different conditions into one summary, and you lose the ability to associate an unusual interval with a particular change.
If the document becomes hidden during collection, the tool cancels the measurement. The browser exposes visibility changes through the Page Visibility API, which allows pages to react when their visibility state changes. MDN explains the API and related background-page behavior. In this tool, cancellation means you should start another complete run after returning to the visible page.
After a completed test, you can download a JSON report. It contains the summary and the recorded interval sequence, along with a capture timestamp and a description of the method. Save that file if you are comparing settings. A screenshot is useful for a quick conversation, but the interval sequence gives you more room to inspect an unusual result later.
Read the median and mean together
The most prominent estimate is calculated by dividing 1000 by the median interval in milliseconds. The median is the middle interval after sorting the samples; with an even number of samples, the tool averages the two middle values. This estimate describes the central spacing of the observed callbacks.
The mean callback frame rate uses a different denominator: the arithmetic mean of all recorded intervals. Because long gaps contribute to that average, the two displayed rates can differ substantially. They are two summaries of the same sample, and their disagreement can be informative.
Consider this deliberately simplified sequence of ten intervals. Nine are 8 milliseconds long and one is 40 milliseconds long. Its median is 8 milliseconds, giving an estimated cadence of 125 Hz. The total is 112 milliseconds, so the mean interval is 11.2 milliseconds and the mean callback rate is about 89.3 FPS. These values describe a sequence with frequent short intervals and one larger interruption.
The higher number should not replace the lower one in your notes. Record both and ask whether this pattern repeats. A central interval close to your intended display mode, accompanied by a much slower mean, points you toward timing consistency. A median and mean both near 16.67 milliseconds describe a different observation: callbacks were generally spaced around that interval during the sample. You can use the FPS and frame-time calculator to check other reciprocal conversions.
P95, standard deviation, and long intervals
The P95 interval adds a view of the slower end of the sample. The tool sorts the positive intervals and selects the value at the rounded-up 95 percent position. For a hypothetical collection of 100 intervals, it uses the 95th sorted value. This is a nearest-rank percentile of callback intervals, not a measurement of the slowest five percent of GPU rendering work.
A P95 value near the median suggests that most of the sample stayed relatively close to its central interval. A larger separation suggests that a noticeable part of the sample had wider spacing. However, a small number of very large gaps can still sit above P95, so it is useful to inspect the downloaded intervals when the visible animation seemed interrupted.
The standard deviation describes how far intervals spread around their arithmetic mean. The tool calculates it over the collected sample using the population formula. Use it to compare repeated runs under similar conditions, rather than assigning a universal good-or-bad threshold to every device and display mode.
The long-interval counter uses a specific rule: it counts intervals longer than 1.5 times the median. If the median is 8 milliseconds, the threshold is greater than 12 milliseconds. One 40-millisecond interval adds one to that counter. It does not add an inferred number of missing physical screen refreshes.
This distinction is especially useful when sharing results. Write “three intervals exceeded the tool's threshold” instead of “the display dropped three frames.” The report has evidence for the first statement. It does not observe the entire display pipeline needed to establish the second. Its P95 value is also different from the sampled minimum FPS in the shader benchmark and should not be called a 1% low.
First check the active display mode
Before investigating browser internals, verify the operating system's current setting for the correct monitor. The number printed on a product page is a supported maximum, while your computer may currently be using another mode. Record the active resolution and refresh setting together so that a later change has clear context.
On Windows, Microsoft's support instructions describe choosing the display in Advanced display settings and checking the available refresh rates. The options depend on the display and its supported modes. Follow the instructions for your installed system rather than assuming the marketing specification is already selected. Microsoft's refresh-rate guide provides the current procedure.
If your intended option is unavailable, investigate the display connection and configuration using the documentation for your monitor, computer, and any adapter in the path. Do not infer a particular cable fault from the browser measurement. You first need evidence that the intended mode is unavailable or inactive at the operating-system level.
After changing a setting, run a new complete browser test. Keep the earlier report and label the new one. If the operating system changes from a lower mode to your intended mode and the browser estimate changes with it, you have a useful association. If it does not, the next question is why the browser's observed schedule differs under that configuration.
Isolate the browser, power state, and display arrangement
Begin with one visible window placed entirely on the target display. If you use several monitors, record which one holds the window. Avoid straddling the boundary between screens during measurement. A simple arrangement makes it easier to repeat a test, even when you do not yet know how your browser and system handle the full desktop configuration.
Next record the power state. For a laptop, distinguish battery operation from external power and note any power-saving mode you intentionally enabled. Repeat under one alternative state if that is the variable you want to investigate. A changed result provides a lead; it does not by itself identify the exact system policy responsible.
You can then compare a second browser while keeping the monitor and power state unchanged. Record browser names and versions. If one browser repeatedly produces a different cadence, keep that observation specific to those versions and settings. It would be too broad to conclude that the device or browser family always has that limit.
Finally, simplify background activity. Close an unrelated animation or video workload, repeat the test, and retain both results. Make each change separately. Changing the display mode, plugging in power, switching browsers, and closing applications together may produce a higher number, but it leaves you unable to explain which change mattered.
Avoid searching for a single magic setting before collecting this basic record. A small comparison table with a display name, selected mode, power state, browser version, median, and mean often tells you more than a collection of screenshots taken under unknown conditions.
Compare a light animation with the shader workload
Once you have a repeatable refresh-rate result, run the shader benchmark separately. Keep the same browser, display placement, and power state. Use the default shader and a consistent active duration. Reloading the benchmark page before each run restores its initial view; simply stopping and starting does not reset every camera setting.
The benchmark's drawing buffer is fixed at 1024 × 1024, and its current metrics summarize rendering in short reporting windows. Starting again after stopping clears the prior run's statistics. Export a result before you begin another run or change the applied shader. These practical details matter more than trying to make two unrelated headline rates match.
There is also a limit to scene matching: the benchmark rotates the view by a fixed increment per rendered frame. A faster run therefore progresses through viewing angles faster in wall-clock time. Even with the same starting view, you should describe these runs as controlled browser-workload comparisons rather than identical time-based camera traces.
Suppose the light test repeatedly gives a cadence near 120 Hz and the shader workload averages around 35 FPS. Rendering cost is one plausible contributor to that gap, but you still need further evidence to distinguish GPU work, scheduling, and other activity. If both tests sit close to 60, investigate the common scheduling and configuration conditions before interpreting the shader number as the GPU's maximum capability.
The WebGL report guide can help you record the browser's available graphics context and renderer information. It adds environment evidence to the comparison; it does not convert these two tests into a hardware ranking.
Work through a hypothetical diagnosis
Imagine that a user has a display advertised for 144 Hz and obtains the following illustrative results. The system settings initially show 60 Hz. The browser test reports a median of about 16.67 milliseconds and a similar mean. The shader benchmark averages 58 FPS. The first useful action is to investigate the selected display mode, because there is a directly observed configuration difference to explain.
Now imagine the user selects an available 144 Hz mode and repeats the same browser test. The median becomes approximately 6.94 milliseconds, with the mean close to it. A new shader run averages 76 FPS. The change supports the conclusion that the browser's light-animation cadence increased under the new display configuration. It also shows that this shader workload did not reach the light-animation cadence during that run.
A different outcome would require a different next step. If the system shows 144 Hz while the browser continues to measure near 60, preserve both observations. Try a second browser or a simpler display arrangement, one change at a time. The mismatch is useful evidence, but it still does not establish a defective display, an inactive GPU, or a particular browser policy.
Notice how the investigation advances through observations rather than assumed causes. At every stage, the next test answers a smaller question. That approach also helps someone else reproduce the result, because they can see which condition changed between each pair of reports.
When detailed profiling is more useful
A six-second summary is appropriate for checking whether the browser's cadence is broadly repeatable. It is less suited to explaining a particular interruption during a complex application. If your real concern is that a page freezes when a menu opens or stutters while loading data, reproduce that interaction and collect a performance recording.
Chrome DevTools provides a Performance panel for recording runtime activity and examining work on the timeline. Its official tutorial demonstrates finding animation bottlenecks and inspecting the activity associated with them. The Chrome runtime-performance guide explains the workflow.
Keep a profiling session separate from your baseline comparison. Label the recording as a diagnostic run and note the tools that were open. You are asking a more detailed question there: which tasks or rendering activity coincide with the interruption? The answer can guide a fix, but it should be checked with another ordinary run afterward.
The refresh-rate tool also cannot measure mouse-to-screen latency, pixel response time, or ghosting. A steady callback interval does not certify those properties. If one of them is your actual concern, choose a measurement method designed for it. Otherwise, it is easy to spend time optimizing a browser number while leaving the original visual complaint unanswered.
Save a result that someone else can understand
A useful note might read: “Browser version recorded, external display selected at 144 Hz, window entirely on that display, external power, three completed visible-page tests. Median intervals were close to 6.94 milliseconds; means were slightly longer. JSON reports are attached.” This gives another reader a testable description instead of a claim that the computer is simply running at 144 FPS everywhere.
If you changed a setting, include the before-and-after conditions and keep all comparable runs. If a run was interrupted, mark it as interrupted rather than silently mixing it into a result. The benchmark comparison guide explains how to organize repeated results without selecting only the highest number.
When a 144 Hz monitor tests at 60 Hz in a browser, begin with the active display setting, then examine browser cadence under controlled conditions. Add a heavier rendering workload only after you understand that baseline. The goal is a result you can explain and reproduce, with enough context to choose the next useful test.