Measure the game becoming usable, not just the surrounding article loading. Keep wrapper-page performance and game performance in separate records.
Google’s LCP documentation explains that the JavaScript API does not include iframe elements in the same way as the overall user-experience metric. A favourable wrapper-page LCP result therefore should not be substituted for a game-ready measurement. (web.dev)
A bounded pilot design
Use this proposed starting design, scaled to the buyer’s requirements and authorised testing limits:
| Dimension | Pilot specification |
|---|---|
| Games | At least 20, including every must-have; add more if the essential list exceeds 20 |
| Selection | Mix studios, release ages, delivery routes and heavier/lighter assets; publish the selection rationale |
| Browsers/devices | Three buyer-relevant combinations, including real-device iPhone Safari and Android Chrome where relevant |
| Locations | Two authorised US test locations selected for the intended audience; identify them precisely |
| Networks | Two recorded profiles, with bandwidth, latency and packet-loss settings stated |
| Repeats | Three cold-cache attempts per game/environment, spread over more than one test window |
| Additional cases | Warm cache, privacy choices, token expiry, denied access, quota limits and game withdrawal |
The core grid is 20 × 3 × 2 × 2 × 3 = 720 launch attempts, before additional cases. This is an experimental design, not a completed test or a nationwide availability claim. Desktop mobile emulation must be labelled as such and not substituted silently for real-device observations.
For the suggested thresholds, require at least 30 observations in each mandatory browser/location/network cohort. Report the actual counts and the uncertainty created by small or dependent samples; do not turn a short pilot into an annual uptime guarantee.
Define the events before testing
Record:
- User initiates Play.
- The launch request is issued.
- A validated game-ready signal arrives, or readiness is confirmed through the documented observation method.
- The first ordinary demo round completes.
- The ten-round test completes or fails.
A ready event is feasible where a supplier supports one: Gamzix’s integration documentation describes game:ready as occurring after game loading and successful WebSocket establishment. That is a supplier-specific event contract, not a universal slot standard. (api-doc.gamzix.com)
If no supported signal exists, label the measurement observed ready, explain the visual/interaction criterion and retain evidence. Do not relabel iframe load as game-ready. (developer.mozilla.org)
What should the failure investigation distinguish?
- Publisher policy versus supplier policy:
frame-srccontrols which frames the publisher page may load;frame-ancestorscontrols which parents may embed the supplied resource. Inspect both before assigning blame. (developer.mozilla.org) - Measured versus inaccessible timing: detailed cross-origin Resource Timing values can be restricted without the appropriate
Timing-Allow-Originresponse header. A zero or unavailable field is not proof of instantaneous loading. (developer.mozilla.org) - Privacy-state failure versus general outage: test the same supported flow with the declared browser privacy settings and approved preference states. Cookie blocking can affect third-party components, so record those conditions with the result. (developer.mozilla.org)
For scoring, retain all eligible attempts in the launch-success denominator. Report expected policy denials separately and test whether their fallback is correct. Keep failures alongside latency percentiles, which otherwise describe only the successful subset.
Never bypass geoblocks, domain controls or authentication to manufacture a passing result. Obtain permission for automation and testing volume, and redact credentials and personal data from shared network logs.