Perceived performance is a separate property from measured performance, and it is the one that produces the complaint. A page that paints in under a second and then reflows twice is slow in the only sense that matters to the person reading it.
What to put in the public brief
- Desktop or mobile, and roughly which market
- That connection type will be asked about
- That screen recording is required
- How many pages
- Roughly how long
Keep the URL private.
What to put in the private instructions
Ask them to say when they thought it was ready
Out loud, during the recording. Then compare that against when it actually settled.
Ask what moved after they started reading
Layout shifts are felt as slowness even when nothing was slow, and they are the most common cause of a fast site feeling wrong.
Ask them to tap something immediately
Before the page has fully settled. Whether the tap registers, and whether it hits what they aimed at, is a real and rarely tested failure.
Ask what connection and where
Home wifi, mobile data, which country. Without it the report is not reproducible.
Proof worth requiring
Ask for
The recording, their stated ready moment, what shifted afterwards, the device, and the connection type and location.
Do not ask for
A stopwatch measurement. You have better tooling for durations, and asking a person to time a page produces a worse number than you already have alongside a worse description than they would otherwise give.
When this task type is the wrong tool
If lab tools already show a genuine problem, fix that first. This is for the gap between good scores and bad impressions.
If people leave before the page finishes at all, that is a connection or hosting problem in the market concerned, and no amount of perception work addresses it.