W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2015

Re: W3C Resource Timing API: Easy access to timing information for a particular XmlHttpRequest

From: Ilya Grigorik <igrigorik@google.com>
Date: Tue, 11 Aug 2015 17:10:22 -0700
Message-ID: <CADXXVKropqLscmGfTydyuuutwTvEx04HCGJY9sXOaw+rSBP15w@mail.gmail.com>
To: Red Daly <reddaly@google.com>
Cc: public-web-perf <public-web-perf@w3.org>, Vincent Chen <vchen@google.com>
On Thu, Jul 30, 2015 at 4:32 PM, Red Daly <reddaly@google.com> wrote:

> I don't believe the Resource Timing API
> <http://www.w3.org/TR/resource-timing/> includes a 100% clean method for
> getting the timing information corresponding to an XmlHttpRequest object.
> If this is the case, it might help users to include a simple lookup as part
> of the API.
>
> My use case:
> I'd like to get request timing information for a particular XmlHttpRequest
> so I can set timeouts for various stages of the request.  For example, I
> don't want my network timeout budget to include time spent waiting for
> other, unrelated connections to finish.
>
> It seems I can use the URL being requested with
> window.performance.getEntriesByName.  However, if there are multiple
> requests to the same URL, I don't know of a 100% reliable way of matching
> my XmlHttpRequest object up with the returned entries.  Perhaps it's
> possible by using the workerStart timestamp, but if so that seems clumsy.
>

I think there are two separate threads here, let me try to unpack..

(1) Setting timeout budgets for various stages of the request.

RT is designed to let you observe performance of the request *after* it
finished, not while it is being performed...
- we make no promises about when RT entries are surfaced
- RT entries are surfaced once request is finished

As such, I don't think RT lends itself to the use-case you have in mind.
That said, do check out the discussion in:
https://github.com/w3c/performance-timeline/issues/13#issuecomment-108097288

(2) Retrieving RT entry for particular fetch.

Yep, this is a gap, and we're working on resolving it. Effectively, we need
a unique key for each fetch -- URL is not sufficient. Some combination of
"fetch ID" (perhaps retrieved via fetch registry [2]) that same attribute
on RT + attribute filtering [3] will do the job.. But the exact plumbing is
still WIP.

ig

[1]
https://github.com/w3c/performance-timeline/issues/13#issuecomment-108097288
[2] https://github.com/whatwg/fetch/issues/65
[3] https://github.com/w3c/performance-timeline/pull/11
Received on Wednesday, 12 August 2015 00:11:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 August 2015 00:11:34 UTC