W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2013

RE: [Resource Timing] Web worker initiatorType?

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 17 Jul 2013 17:57:08 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: James Simonsen <simonjam@google.com>, public-web-perf <public-web-perf@w3.org>
Message-ID: <cda56804bc154532b4195bd30f07dae1@BLUPR03MB065.namprd03.prod.outlook.com>
> So you *could* consider dedicated workers as part of their owning document. But you could also keep them consistent with shared workers and make them create a new context.

That's the question we need to answer. We discussed this in the conference call today, and there are some interesting scenarios to consider:

We've heard the use case where folks want to use a worker to upload the performance timeline in the background. In that case, the dedicated worker needs to have access to data from the owning document. However, seems like the more common use case will be to use a beacon and JSON the entire performance timeline up before unloading in the main document, instead of even using a worker to gather the data. We expect most of the analysis to happen on the server side, not the client.

To help analytics scripts, it may just be easier to have dedicated workers share information with the owning document. That way an analytics script added to the owning document has access to all resources, including resources fetched from the worker. If we keep them separate, an analytics script won't be able to see the resources fetched from the worker, unless analytics code is added to each worker, which may be onerous. However, what if the owning document has many workers, we may want to provide a way to associate which worker initiated the resource download. Having the dedicated workers as a separate timeline from the main document would help here.

There's also the case of a shared worker spawning dedicated workers.

At least it's very clear that a shared worker should be treated as having a separate timeline with its owning documents. The question really is, should a dedicated worker also be separate or share data with its owning document? 

Jatinder

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Wednesday, July 17, 2013 10:28 AM
To: Jatinder Mann
Cc: James Simonsen; public-web-perf
Subject: Re: [Resource Timing] Web worker initiatorType?

For shared workers you can't make it show up in the performance metrics for "the document" since a shared worker doesn't have a lifetime connected to any particular document.

Shared workers essentially are stand-alone documents that are running off the main thread in a UI-less context.

Dedicated workers are always tied to the document that created them.
They go away when the document goes away (I *think* that's the case even when MessageChannels are in play, but the spec doesn't spell it out clearly).

So you *could* consider dedicated workers as part of their owning document. But you could also keep them consistent with shared workers and make them create a new context.

/ Jonas

On Wed, Jul 17, 2013 at 9:51 AM, Jatinder Mann <jmann@microsoft.com> wrote:
> I agree that we should consider adding Web Worker support in the 
> Resource Timing L2 spec.
>
>
>
> For web workers, we need to decide whether the resources downloaded by 
> the web worker should show up in the main document associated with the 
> worker, or only when the buffer is requested from the web worker 
> context though the
> performance.getEntries() methods. The opposite is also interesting, 
> should the resources used in the main document by shown when calling
> performance.getEntries() methods from the worker context? Sounds like 
> an interesting use case.
>
>
>
> If we decide to show the data in the main documents associated with 
> the worker, we'll need to consider if we want to overload 
> initiatorType with 'worker' or come up with a new attribute to 
> describe where the request came from. There's also the detail on which 
> documents we should associate with a shared worker (all documents?). 
> If we decide to only show the data in the worker context, I don't think we need to worry about those details.
>
>
>
> As for the script being used by the worker, seems like the initiator 
> here would really be the script element on the main document.
>
>
>
> There's also the bit on adding the
> performance.getEntries/getEntriesByType/getEntriesByName functions to 
> the web worker context. I think we should definitely make that change.
>
>
>
> We should discuss in the conference call in which direction we are leaning.
> I can make spec changes accordingly.
>
>
>
> Thanks,
>
> Jatinder
>
>
>
> From: James Simonsen [mailto:simonjam@google.com]
> Sent: Wednesday, July 10, 2013 5:47 PM
> To: public-web-perf
> Subject: [Resource Timing] Web worker initiatorType?
>
>
>
> Earlier, we decided to punt Web Worker support to a level 2 spec. [1] 
> We were mainly talking about resource downloaded inside the worker, like XHRs.
>
>
>
> What about the worker itself? Its script is actually fetched by the 
> main document, so it seems like it should show up in the buffer and 
> have a "worker" initiatorType. WDYT?
>
>
>
> James
>
>
>
> [1] 
> http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0002.html
Received on Wednesday, 17 July 2013 17:59:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:36 UTC