core(time-to-first-byte): use receiveHeadersStart

[connorjclark]

I added receiveHeadersStart to network timings in https://chromium-review.googlesource.com/c/chromium/src/+/4556570 . It will be available in M116.

This PR changes ttfb calculation to use timing.receiveHeadersStart instead of timing.receiveHeadersEnd. Using the end time potentially misreports ttfb in uncommon cases where the server either intentionally delays some headers (say, it push out some link headers early then does the rest after some thinking); or sends so many headers that they arrive over multiple packets. In either case, we care about the network connection latency, so we want to exclude such delays.

[adamraine]

This is good. Should we update the usages of receiveHeadersEnd in server-reponse-time.js and network-analyzer.js as well?

[connorjclark]

Should we update the usages of receiveHeadersEnd in server-reponse-time.js

As the server-response audit is documented, yeah we should change it there too. It seems the intention was to be a synonym for ttfb.

Without considering the current state of the audit, I'd consider "server response" to be pretty ambiguous, you could argue it can be the first byte of the headers or the first byte of the response body. I don't have a good argument for one way or the other, except that: if it was meant to be the first byte of the headers, why wasn't the audit called TTFB?

network-analyzer.js?

transferSize includes bytes from the header, so I think changing that too is right. good catch.

[connorjclark]

Let's defer the network analyzer changes until after we update the Lantern database. #15150

[adamraine]

if it was meant to be the first byte of the headers, why wasn't the audit called TTFB?

According to this comment, server response time is just one part of TTFB:

lighthouse/core/lib/dependency-graph/simulator/network-analyzer.js

Lines 227 to 228 in 333a667

	// When connection was fresh...
	// TTFB = DNS + (SSL)? + TCP handshake + 1 RT for request + server response time

[brendankenny]

Yeah, TTFB is startTime to responseStart, possibly including unload handling, redirects, etc.

Server response time tries to measure the end of that duration from when the first request byte is sent (requestStart).

responseStart is when the browser "receives the first byte of the response (e.g., frame header bytes for HTTP/2 or response status line for HTTP/1.x)", so receiveHeadersStart is what we want.

[connorjclark]

Thanks for the breakdown @brendankenny! I'll prepare another PR to update server-response-time.

[brendankenny]

What other uses are there? Would it be helpful to make a tracking bug to make sure they all get moved over?

[connorjclark]

Analyzer is the only other one, and that is tracked here #15150