How Stroop times responses

Two things on this site time you: the Stroop test on the homepage, and the timed tasks in a real study (IATs, priming, go/no-go and the rest). They use the same idea. The study engine does a good deal more around it.

The homepage Stroop test

1. The colour word is put on the page.
2. The browser calls the next requestAnimationFrame callback [3]. That callback's timestamp is taken as the onset: the frame the word was painted on.
3. Your key press or tap carries its own event timestamp.
4. Your response time is the event timestamp minus the onset. Both come from the same performance clock, so neither depends on the time of day or on how busy the page is when the code runs.
5. After ten trials, five where the word and its ink match and five where they don't, the interference figure is the mean of your correct different-ink answers minus the mean of your correct same-ink answers.

That's a demonstration, not a measurement. The homepage test runs inside the page's normal script, without the isolation, the refresh check or the frame monitoring described below, and ten trials is far too few to say anything about you. It's there so you can feel what the method does.

How a study times a trial

1. The trial loop runs outside the page's interface code, in a cross-origin isolated page. Whether isolation held is recorded on every block.
2. Every change to the screen is made inside a requestAnimationFrame callback. The stimulus onset is the timestamp of the next callback, the frame on which the change appeared.
3. The response time is the key event's timestamp minus that onset, both on the performance clock. With correction required, it runs to the correct key; the first, wrong key and its time are stored too.
4. Short exposures run as whole frames, and the achieved duration of every prime, blank, target and mask is stored with the trial.
5. Each block's instruction screen measures the refresh rate from consecutive frame intervals. If the median interval is over 34 ms (under about 30 Hz) or more than 10% of frames are dropped, the participant is asked to close other tabs and it measures again.
6. During trials, frame intervals are watched for jitter and dropped frames, and an interrupted trial (the tab lost focus, say) is queued again and re-run, so the broken copy never counts.
7. Every participant gets a timing grade from those figures, shown in the results with the browser and operating system.

A worked example

A trial's word is painted on the frame whose callback reads 1,204.6 ms. The participant's key event reads 1,917.2 ms. The response time is 712.6 ms. If their laptop adds a constant 60 ms between finger and event, every trial carries that 60 ms, both pairings' means rise by it, and their difference, which is what a D-score divides [2], doesn't move.

A 75 ms prime requested on a 60 Hz screen, where a frame lasts 16.7 ms, runs as 5 frames, so it is shown for 83.3 ms, and 83.3 ms is what the trial stores.

Three sample participants, graded by the same function the results page uses:

Good means under 1% dropped frames, under 1 ms of frame jitter, every timed duration within one frame of the request and no interrupted trials. Fair allows under 5% and under 3 ms, with at least 95% of durations within a frame. Anything else is Poor, and one switch in the results excludes Poor.

What a device's lag does

Between a key going down and the browser stamping the event, and between the frame being drawn and the light leaving the screen, every device adds delay. Bridges and colleagues (2020) [1] measured browser timing precision under about 10 ms in most setups, with constant lags that could average 80 ms or more depending on the device. A constant lag cancels in difference scores such as the IAT D-score and priming effects. It stays in absolute reaction times, so comparing raw milliseconds between people on different machines compares their machines too.

What we've checked, and what we haven't

We run the timed tasks under an automated browser and check two things: that recorded reaction times match a delay we injected, once the harness's own round trip is taken out, and that short exposures run as the whole frames they should. In headless Chromium both hold. Headless Chromium draws frames from its own steady timer instead of a real display, so that's the best case: it shows the arithmetic and the frame scheduling are right, and nothing about a participant's screen and keyboard.

We haven't yet measured display and keyboard latency on real devices, or run the check in Firefox and Safari. That needs a photodiode on the screen and a solenoid pressing the key, read by a microcontroller, and when it's done the results go in this note. Until then we make no comparison with lab software. If your study needs that, the implicit testing page says who to use instead.

Used on Implicit testing. Stroop is the all-in-one research and testing platform. Run usability tests, prototypes, surveys, tree tests, diaries and IATs in one study, and get results back transcribed, scored and charted, with every finding linked to the session it came from.