Previous discussions:
Highlights of raised issues and questions:
Philippe: While trying to write a proposal, I realize that we have two different byte sizes that could be returned: 1. the byte size of the response; 2. the byte size of the response's body - source
Boris: My question was what "response body" means. Is it the entity/payload
body or the message body?
If we're counting the size of the headers, then using the size of the
entity/payload body would be the most sensible thing, since that's what
goes on the wire with the headers. But other comments in this thread
suggest that's not what Chrome does... - source
Boris: Specifically, given some data that is sent with Content-Encoding:gzip
and Transfer-Encoding:chunked over an SSL connection, are we measuring
the size of the HTTP "message body" (which in this case is gzipped,
note), or the "payload body" (which has the extra bytes for the chunked
encoding) or the actual HTTP messages (which include headers in addition
to the data) or the size of the TCP packets (which include SSL overhead
bits and the HTTP messages in encrypted form, plus the TCP handshake
itself) or something else?
More interesting is what the status code should be reported as if the
browser did a conditional request and got back a 304. Is the status
code 304 or whatever the status code for the cached response is? - source
Hiroshi: What's the value, when download is failed? It's really important. - source
Alois: We would have to check whether size over wire is available in all browser implementations. Some use abstraction layers that do not allow to get this information. Most likely the number to get is size of content when browser gets it. - source
Investigating what and how different browser developer tools shows the following...
Chrome (docs)
- "Size" is the combined size of the response headers + response body, as delivered by the server.
- 304 Size shows response headers size
- "Content" is the size of the resource's decoded content. If the resource was loaded from the browser's cache, this field will contain the text (from cache).
- 304 Content shows decoded content size, same as 200 response case.
Firefox (docs)
- "Size" is the size of response body as delivered by the server (excludes headers)
- 304 Size shows size of response body of original request (as loaded from cache)
- Requests loaded from cache are not shown in network waterfall
Safari (docs)
- "Transferred" is the combined size of the response headers + response body, as delivered by the server.
- 304 Transferred shows response headers size.
- If loaded from cache, set to 0.
- "Size" is the size of the resource's decoded content.
- 304 Size shows size of the resource's decoded content.
- If loaded from cache, shows size of the resource's decoded content.
IE (docs)
- "Received" is the total amount of data that's received, in bytes: response headers + resource's decoded content (courtesy of WinINet).
- Shows size of the resource's decoded content + headers.
- 304 Received shows size of received bytes (HTTP headers only).
tl;dr: no consistency. Safari is arguably the most useful, consistent, and sane.
Taking a step back, I believe we should to surface two metrics:
- Transfer size (
transferSize
): this attribute must return the size, in octets received by the client, consumed by the response header fields and the response message body. This SHOULD include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but SHOULD NOT include lower-layer protocol overhead (such as TLS or TCP).
- Headers are included to account for protocol overhead and size of transferred request/response meta data (e.g. cookies and other headers).
- Response body is as sent by the server - e.g. compressed size.
- Decoded size (
decodedSize
): this attribute must return the size, in octets, of the message body used, after removing any applied content-codings.
decodedSize
is always present, regardless of whether resource is fetched from the network, or comes from cache; decodedSize
does not reflect the "on the wire" size.
- Comparison with
transferSize
allows to identify compression savings based on GZIP, SDCH, and/or other compression/delta-update mechanisms.
- Allows the site to capture/measure size of synthesized Service Worker responses.
The values are reported as follows:
- Full fetch (200):
transferSize
= request/response headers size + request/response body size
decodedSize
= decoded response body size
- Conditional / revalidation fetch (304):
transferSize
= request/response headers size (body size = 0)
decodedSize
= decoded response body size (from cache, same value as 200)
- Cache fetch:
transferSize
= 0
decodedSize
= decoded response body size (from cache, same value as 200)
In short, decodedSize
always indicates the decoded response body size, and transferSize
is the total number of bytes transferred over the network.
Other notes:
- I don't believe we need to expose HTTP response codes; they're unnecessary.
- Above approach allows the application to identify responses served from cache.
- IE may not have transfer size data due to WinINet, but I don't believe we should exclude it for that reason alone. Transfer size is an important metric to track; IE can report 0's (until they fix WinINet :)).