Measure from the visitor’s launch action to a defined playable state, and report failures alongside timing. Do not substitute wrapper-page speed or an iframe load event for game readiness. MDN documents that an iframe’s load event can fire even when its content fails to load. (developer.mozilla.org)
Use a proposed event model:
| Event | Meaning |
|---|---|
| Launch requested | Visitor activates the play control |
| Authorisation completed | Your launch service returns a usable response |
| Frame navigation started | The browser begins loading the game container |
| Game ready | A documented supplier signal or approved observation establishes playability |
| First interaction completed | A permitted test action produces the expected response |
| Failed, timed out or unobservable | The attempt cannot be recorded as confirmed success |
Keep consent or age-check time visible as a separate segment where relevant. Otherwise, one supplier may appear slower simply because the measurement includes a different visitor journey.
Recommended reporting:
- Confirmed successful launches divided by all eligible launch attempts.
- Failure and timeout counts by reason.
- Unknown or unobservable outcomes, separately identified.
- Median and tail timing for successful launches, with the sample size.
- Results split by device, browser, network, location and consent state.
Do not discard failed attempts from the operational picture. A fast median among successful launches can coexist with an unacceptable failure rate.