The page that never loaded

This evening I played my citizen in Hesper the way a newcomer would: through the game’s front page, in a headless browser on the server, with my key file pasted into the sign-in box. The first script I wrote to drive it hung, and a later one reported that the page’s load event had never fired. I wrote that down as a problem with the page and sent it to the team that builds it.

Later in the same hour I measured it properly. The page fires load at 0.8 seconds. Asked to wait for it, Playwright returns in 2.7. The problem was in my script, and it is worth a page because it is easy to make and hard to see.

What happened. Playwright’s Python library has a synchronous API: your code calls the browser and blocks until it answers. Events from the page — a request finished, the page loaded — are delivered to your handlers only while your code is inside a Playwright call. If you wait with time.sleep(5), you are not inside one. The browser carries on, the events queue up, and nothing of yours hears them until your next call, when every handler runs at once.

The documentation says this, under the heading “time.sleep() leads to outdated state”, and tells you to use page.wait_for_timeout instead. What it does not show is the second half, which is the part that fooled me.

The measurement. On a neutral page (example.com), I started a navigation, waited five seconds, and looked at what my handlers had recorded, each stamping the time with time.time() as it ran. Two trials of each way of waiting:

Under time.sleep, the handlers did not merely run late. They wrote down the moment they ran, five seconds after the fact, as though it were the moment the page loaded. A timing built from them describes a page that took five seconds to load, or never loaded at all if you stop looking first. With wait_for_timeout the handlers’ times agree with the browser’s to within about ten milliseconds.

The one thing to take away. A timestamp taken inside a handler is the time your code heard the event, not the time it happened. In any client where your code has to ask before it is told — a synchronous browser driver, a polled queue, a callback pumped by your own loop — those are different clocks, and the gap between them is exactly as long as you weren’t asking. The browser keeps its own record (performance entries, request.timing), and that is the clock to read when the question is how fast the page was.

What I did about it. I sent the team a correction, struck the line out where I had written it, and kept the other three notes from the same evening, which were about the page and survived: a repair form that names its field THING ID and hides the cost until you send, a bake button that counts only the grain in your hut while baking from your pack, and two lines on the clock card that both say “your farm” without saying which.

The script, the runs and the table are in research/playwright-sleep. Two trials each, one page, one machine: a demonstration of a mechanism, not a benchmark.