Measure the journey from a visitor’s Play action to an explicitly defined usable state. A successful HTTP response or iframe load event is insufficient.
MDN states that an iframe’s load event is triggered even when its content fails to load, while the iframe error event is not a dependable failure signal. Therefore, do not name an onload counter “successful games played”. (developer.mozilla.org)
Which events should you distinguish?
Use this proposed event model:
| Event | Definition |
|---|---|
demo_offered |
The publisher presents an eligible Play option. |
demo_requested |
A visitor asks to launch the game. |
launch_created |
The publisher obtains the required launch information. |
frame_loaded |
The browser reports the iframe document event; not proof of gameplay. |
game_ready |
A documented supplier signal or approved observation establishes readiness. |
interaction_completed |
A permitted test confirms a meaningful game interaction. |
launch_failed |
A known failure, timeout or unusable state is recorded. |
availability_denied |
The game is deliberately unavailable under the applicable policy. |
Record the clock start, readiness definition and measurement method. If you lack a trustworthy readiness signal, report the limitation explicitly.
How can you measure a cross-origin game?
A supplier-supported postMessage integration can carry events across origins. Validate the message’s origin, source and payload against the documented protocol; do not trust arbitrary messages because they contain a familiar event name. MDN specifically warns about failing to check origin and source. (developer.mozilla.org)
Detailed cross-origin resource timings also have limits. Timing-Allow-Origin determines access to timing attributes that otherwise may be reported as zero. A zero value is not proof of instantaneous delivery, and network timing is still not a gameplay-ready signal. (developer.mozilla.org)
Without supported instrumentation, use authorised browser tests and visual evidence, labelling the results as observed readiness rather than complete production telemetry.
What belongs in an HTML5 slot embed performance test plan?
Choose profiles from your audience and requirements. The following is a proposed matrix:
| Dimension | Minimum planning question |
|---|---|
| Game selection | Have all launch titles received a baseline check, with deeper coverage for must-haves? |
| Devices | Which actual iPhone, Android and desktop environments matter? |
| Browsers | What versions and settings were used? |
| Network | What bandwidth, latency and connection conditions were measured or configured? |
| Privacy state | Does the page behave correctly before interaction, after refusal and after acceptance? |
| Location | Which permitted physical/test locations were used, and what did the supplier detect? |
| Cache | Are cold, warm and expired-launch states covered? |
| Lifecycle | What happens after rotation, backgrounding, resuming and reconnecting? |
| Failure | Are blocked territory, withdrawn title, exhausted quota and timeout handled? |
| Presentation | Can users find instructions, exit the demo and understand that it is non-wagering? |
For scale awareness, five representative games × three device profiles × two network profiles × two privacy states × two permitted locations × two repetitions equals 240 launch attempts. That is an illustrative test design, not an industry minimum or a guarantee of statistical reliability.
Playwright supports browser testing and device emulation. Its emulation changes parameters such as viewport, user agent and touch behaviour; identify those runs as emulated rather than claiming they prove behaviour on physical handsets. (playwright.dev)
Do not treat an emulated geolocation setting as proof that traffic originated from a particular US state. Record the actual test arrangement, obtain permission for any external test infrastructure, and do not bypass access controls.
What should every failure ticket contain?
Use a standard proposed template:
Publisher page and internal game ID:
Supplier and supplier game ID:
UTC timestamp:
Device / OS / browser:
Physical or authorised test location:
Network and privacy state:
Expected result:
Observed result:
Reproduction steps:
Sanitised request/console evidence:
Screenshot or recording:
Launch credential age, without exposing credentials:
Last known successful test:
Business priority and affected pages:
Named supplier escalation contact:
Which metrics support a defensible decision?
Report at least:
- Confirmed ready sessions divided by all measured launch requests.
- Failed, timed-out, cancelled and unknown outcomes separately.
- Readiness time for successful measured sessions, with the sample size.
- Availability denials by reason, separately from technical failures.
- Results by game, device and location—not just a blended total.
Do not quietly remove unknown outcomes from the denominator and imply complete measurement. Do not present a small pilot as a production uptime SLA.
What should pass before release?
Set project-specific acceptance criteria before testing. A useful proposed baseline is:
- Every published game has the required evidence and baseline test result.
- Every must-have game passes its critical audience profiles.
- No unresolved high-severity rights, privacy, security or promotional issue remains.
- Failure states are understandable and do not redirect users unexpectedly.
- The team can disable a title without a code deployment.
- Readiness and monitoring limitations are disclosed in the release record.
- Product, engineering and the relevant risk reviewer sign off their own areas.
Choose performance thresholds against the experience you intend to offer. This research did not establish a universal acceptable slot-demo load time.