py-config initialization transition and concurrent request latency

Documented initialization order

According to the PyScript documentation, the py-config block is processed during the initial PyScript bootstrap on the main thread. The packages list is walked sequentially: each dependency is fetched, compiled, and its Python import‑time code executed before any py-async component’s user code runs. This initialization is deduplicated across all py-async tags on the page, so the packages are loaded only once.

What happens with concurrent py-async components

1. Bootstrap phase: main thread loads and initializes every package listed in py-config in the order they appear.
2. After bootstrap finishes, a single Pyodide worker (shared by all py-async tags) begins executing the user‑provided Python coroutines.
3. Each component’s code runs as soon as its turn arrives in the event loop; there is no per‑component re‑initialization of packages.

Serialization overhead behavior

Data crossing the JavaScript‑Wasm boundary must be marshalled. Measurements show that the cost per exchange is roughly constant, so total overhead grows approximately linearly with the number of exchanges per second. At high frequencies the copying and conversion steps can dominate latency, making frequent fine‑grained calls a performance bottleneck.

Main‑thread blocking bounds

The main thread is blocked only for the duration of synchronous Python chunks (code that runs without an await). The event loop yields control at each await point, so the length of a block is determined by how long the synchronous code runs before yielding, not by the number or configuration of Pyodide workers. Changing worker settings does not split or reduce a synchronous block’s blocking time.