A new experiment: Delay Loading is a page whose `load` event is genuinely deferred by a configurable number of milliseconds. It's a slow-loading target to embed when you need to see how a parent reacts to a child frame that finishes loading late — for example the iframe proxy.
The page renders a hidden image pointing at /api/delay?ms=<delay>. That endpoint delays the HTTP response by the requested time before returning a 1×1 transparent GIF. Because the browser's load event waits for every sub-resource to settle, the document's load event — and any embedding iframe's onload — doesn't fire until the delay has elapsed.
The image is non-render-blocking, so the page's UI and a live countdown paint immediately while the load event is still pending. The image markup is server-rendered via getServerSideProps, so the request starts during the initial document load rather than after hydration. When the load event finally fires, the page shows how long it took.
Use the delay (ms) input and hit Apply & reload, or set it directly in the URL:
/delay-loading?delay=5000Values are clamped to the 0–60000 range (0 loads normally with no deferral). The delay is encoded in the permalink so the exact timing is shareable. Changing it reloads the page, since the deferral can only be applied on a fresh document load.
Point the proxy's debug harness at this page (the url parameter must be an absolute URL, and since it is itself a query value, it must be URL-encoded):
/iframe-proxy?debug=true&url=https%3A%2F%2Fhypothesis.sh%2Fdelay-loading%3Fdelay%3D5000The proxy emits its loaded event off the inner iframe's load event, so a delaying target makes that relay arrive only after the configured delay — versus immediately for a normal page. On load this page also posts a { event: "delay-loaded", delayMs } message to its parent, which shows up in the proxy's debug panel.
Full details are in the docs.