igrigorik
commented
6 years ago Workers and pages have independent lifecycles, time origins, and timelines. E.g. a single worker can be servicing multiple documents, each of which will have a different time origin from the worker. Which is to say, there is no clean or simple mapping of NT entries to workers.
As you already noted, it is possible to achieve what you're looking for: the document needs to postMessage the entries and timestamps to the Worker, alongside the time origin timestamp we introduced in HR-Time L2 to address this very case. On that note, when iterating on the time origin timestamp design we considered various solutions (including mapping entries to Worker) and landed on current design due to the complexities outlined above.
Closing as wontfix: the guidance here is to use postMessage with performance.timeOrigin to translate between time origins. Please feel free to reopen if you disagree. :-)
It can be useful to have Navigation Timing data in the Worker context. One example is to create heuristics based on DNS time and HTML download time when more accurate browser heuristics are not available the the netinfo API.
Right now this can be done by PostMessaging this information from the Document, but it would have been easier if it was exposed directly in Worker.