Lifecycle events
PDF Server waits for a page lifecycle event before printing to PDF. By default it waits for load — all synchronous resources are loaded and rendered. For pages with async content (charts, fetch, web fonts), you can wait longer.
Choosing the event
Set it per template in params.json or globally with --wait-lifecycle-event / WAIT_LIFECYCLE_EVENT:
{ "pdf": { "waitLifecycleEvent": "networkIdle" } }Available events
| Event | Fires when… |
|---|---|
init | navigation begins |
DOMContentLoaded | HTML parsed, before subresources |
load | default — all sync resources loaded |
firstPaint / firstContentfulPaint | first pixels painted |
firstMeaningfulPaint / firstMeaningfulPaintCandidate | main content painted |
networkAlmostIdle | ≤2 network connections for a period |
networkIdle | no network activity for a period |
callback | the page explicitly signals readiness (see below) |
The callback event — signal readiness yourself
For fully custom “ready” logic (e.g. after a chart library finishes drawing), use callback. The renderer then waits until the page calls back to the internal server, rather than watching browser events.
{ "pdf": { "waitLifecycleEvent": "callback" } }In the page, fetch the callback URL when your content is ready:
<script>
// ...draw charts / load data...
window.addEventListener('load', () => {
fetch(window.location.pathname + '/callback');
});
</script>The renderer prints the PDF as soon as that request arrives (bounded by the render timeout). See the callback example in the Gallery.
The callback endpoint lives on the loopback-only internal server the browser is already talking to — the page reaches it via its own
window.location. See Internal callback server.