Responsiveness. What you feel while every core is busy.
A throughput figure says how much work a machine does. This one says how it feels to use while it does it: how late the page's own thread runs, how long an input takes to reach a paint, and how many frames the display misses, with every core but one loaded, each beside the same figure measured idle.
An illustration of the shape, not a measurement. The test reports your own figures.
Idle
5 s, probes only
Load
20 s, every core but one
Probes
Ping every 50 ms, input every 200 ms, every frame
Duration
25 seconds
Run it
The responsiveness test. 25 seconds, in this tab.
5 seconds idle, then 20 with every core but one loaded. Keep this tab in front and your hands off.
What you will get
How late the page’s own thread runs while every core but one is busy, how long an input takes to reach a paint, and how many frames the display misses, each beside the same figure measured idle. Nothing is uploaded.
Three probes, idle and then under load.
Everything a page does to respond to you happens on one thread: the event, the script, the style, the paint. When the rest of the machine is busy, that thread can run late even though the work it has is small. The test measures the lateness directly, then measures it again with the load on.
- The ping
- Every 50 ms the page posts a setTimeout(0) and a MessageChannel message to itself and records how long each takes to come back. The request was for no delay at all, so everything measured is delay: the browser's scheduling, and the operating system's, with every other core busy.
- The input
- Every 200 ms a synthetic pointer event is dispatched at the panel and the time until the next animation frame runs is recorded. That is the shortest path from an input to a paint, which is what a click or a keystroke waits on. It is synthetic on purpose: your own input would add to it, so keep your hands off.
- The frames
- Every animation frame's interval is recorded. The idle baseline's median interval is taken as the display's nominal, so a 120 Hz display is judged at 120 Hz, and an interval over 1.5 times the nominal counts as a missed frame.
- The load
- The CPU stage's own workload, imported rather than copied, on every logical core but one. The one left free is the page's thread, so what the test sees is how well the browser and the operating system keep that thread served when the rest are saturated, which is the situation a render, an export or a compile puts you in.
Three figures, each beside its idle reading.
No score. Every figure is the loaded reading with the idle reading next to it, so the difference is the load's and not the browser's.
Main-thread delay
The median and the 95th percentile of the pooled ping delays, in milliseconds. The verdict reads the loaded p95: under 50 ms is responsive, which is our line, about three frames at 60 Hz; 200 ms and over is unresponsive, borrowing Google's Interaction to Next Paint line; between the two is hesitant.
Input to paint
The 95th percentile of the synthetic input's time to the next frame, in milliseconds. It is read against Google's Interaction to Next Paint good line of 200 ms, which is a line for real interactions on real pages and is quoted here as the comparison point, not as a standard this figure was defined by.
Frames missed
The share of frame intervals over 1.5 times the display's nominal interval, as a percentage, with the frame count stated. A display that keeps its rate while every core is busy has a compositor with room; one that drops to half rate does not.
Flags
If workers could not start and the load ran on the page's own thread, the probes measured a thread measuring itself and the result is marked as a fallback and not comparable. If the tab was hidden for more than a second, the clock paused, nothing was recorded while hidden, and the result says so.
An illustration of the shape, not a measurement. The test reports your own figures.
Hardware
What it needs. Three tiers, no fine print.
Minimum
Any recent browser
Chrome, Edge, Firefox or Safari on a laptop or desktop. Web Workers are needed for the load to run off the page's thread.
Recommended
Plugged in, hands off
Any input of your own during the run is added to the synthetic one. On battery, some laptops slow the whole machine, which raises the idle reading as well as the loaded one.
Optimal
The display at its normal rate
A browser that has been throttled to a lower rate by the operating system's power saver reports that rate as the nominal, and misses frames against it.
Questions
Responsiveness, answered
- What does a responsiveness test measure?
- How late a page runs when the machine is busy. The test times three things on the page's own thread, idle for 5 seconds and then for 20 seconds with every core but one loaded: how long a zero-delay timer and a message take to come back, how long a synthetic input takes to reach the next paint, and how many display frames are missed. Each loaded figure is shown beside its idle one.
- Why every core but one?
- Because the page's thread needs a core to run on, and what the test asks is how well the browser and the operating system keep that thread served when every other core is saturated. Loading every core would measure starvation instead, which is a different question and a less useful one.
- Where do the 50 ms and 200 ms lines come from?
- 50 ms is ours: about three frames at 60 Hz, where a delay stops being invisible. 200 ms is Google's Interaction to Next Paint good line, a published line for real interactions on real pages. The input figure is read against it as a comparison point; the main-thread verdict borrows it as its upper line and says so.
- Why is the input synthetic?
- Because a real one cannot be scheduled. A synthetic pointer event dispatched on a timer takes the same path from event to the next frame, arrives at a known time, and does not depend on how fast you click. Your own input during the run would be added to it, so the page asks you to keep your hands off.
- Is this part of the main SystemCheck run?
- No. It runs on this page only, on its own, and it does not change the score or the report. The main run's CPU stage records a scheduling figure for diagnostics; this test is the user-facing version of that question, asked properly.
- What can it not see?
- Which process took the time. A delay is the browser's scheduling, the operating system's, and every other program's, summed; the test cannot say whether an antivirus scan or the browser itself held the thread. It also measures the page's thread, not the operating system's own input pipeline, so a mouse that feels slow for a driver's reason will not show here.