- From: James Simonsen <simonjam@chromium.org>
- Date: Tue, 13 Nov 2012 13:32:31 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAPVJQi=FmjL2X8W=tUBTs+rKux=T0tER=uhe6v1eD7Nv6cid5Q@mail.gmail.com>
On Tue, Nov 13, 2012 at 11:02 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 11/13/12 10:56 AM, James Simonsen wrote: > >> Good point. We have two cases then for the same-document scenario: >> >> 1a. Requests are coalesced into one. >> 1b. Multiple requests are issued. >> >> Seems for a single document, there should be a 1:1 correlation between >> Resource Timing entries and network requests. >> > > Assmuing "network requests" can include things that come from a network > cache of some sort (a cache that returns bytes, not objects), I mostly > agree. > > There's various other complexity here, though, as caches get smarter. For > example, what happens if your document thinks it's making multiple network > requests but there's a cache that knows to not only return the same bytes > but also caches an object representation of some sort in a persistent > fashion (think compiled bytecode for a script) and can return that as > needed? > Since we're not making a request to the server, I'd say that wouldn't show up at all in Resource Timing. > What are we really trying to measure here? I think the goal is to show how much time resource requests were blocked on the network. So anything that doesn't go out on the wire doesn't need to be reported. We may need to beef up our definitions in the spec. James
Received on Tuesday, 13 November 2012 21:32:59 UTC