transferSize and decodedSize attributes

[igrigorik]

• Adding two new attributes
• Updated processing model to set both values

Closes #3. WG thread: http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0060.html

[igrigorik]

@mnot can you sanity check proposed language in 9369559?

Also, I think we may need to refine our transferSize definition: https://rawgit.com/w3c/navigation-timing/size/index.html#dom-performancenavigationtiming-transfersize. Right now it says "response header fields + response message body", but I think we want to account for other overhead, like chunked coding, etc? Any suggestions for appropriate language?

[igrigorik]

Err, just realized that in our meeting we said we wanted encodedBodySize, not transferBodySize... However, now that I think about it, perhaps transferBodySize is better, since the message body may not actually be "encoded"? :)

[mnot]

Is overhead included (e.g., chunking in /1, framing in /2)? If so, "transfer"; if not, "encoded."

[igrigorik]

Ah, right, good call. Updated, PTAL: https://rawgit.com/w3c/navigation-timing/fe25907be3d04dcba46812a7fbd890b3024b80ce/index.html#dom-performancenavigationtiming-transfersize

[mnot]

Do we need to say anything about redirects in transferSize?

Yes, I'm getting picky.

[igrigorik]

@mnot personally, no... I think we should limit it to last request only.

That aside, any other thoughts or suggestions?

[mnot]

Should we explicitly say that we limit it to the last request only (i.e., previous messages aren't considered "overhead")? It feels like too much detail, but then again that's how bouncing baby bugs are born.

Anyway, LGTM.

[igrigorik]

@mnot hmm, taking another pass over the spec, stumbled over...

(redirectStart) If there are HTTP redirects or equivalent when navigating and if all the redirects or equivalent are from the same origin, this attribute MUST return a DOMHighResTimeStamp with a time value equal to the starting time of the fetch that initiates the redirect. Otherwise, this attribute MUST return a DOMHighResTimeStamp with a time value equal to zero. - source

So, at least as long as the redirect is within same origin, we do account for its timing overhead. Now I'm wondering if we should do the same for HTTP overhead -- the consistency seems like a plus. Thoughts?