Add interoperable TTFB and ability to measure document duration.

[tunetheweb]

For sites using Early Hints there are two "TTFB"s depending on your definition of "first bytes":

• When the Early Hint bytes are received: Many argue these are the "first" bytes of the response.
• When the actual document bytes are received: Many argue this has always been the understanding of TTFB and this should not change just because Early Hints have been deployed. We don't count many other responses (TCP, redirects...etc) as "first bytes" so Early Hints should not be counted either.

In Chrome 115, firstInterimResponseStart was introduced as a way of measuring Early Hints response start, and responseStart was moved out to be the the document bytes were delivered.

While done with the best intentions and to address the above issue where the majority agreed with the second definition and wanted to return to this, the moving of responseStart turned out to be a bad idea as it created an interop issue between those browsers that supported firstInterimResponseStart and had moved responseStart (Chrome 115+) and those that had not made this change yet (everyone else, including Safari, Firefox, Chrome < 115, tooling like Lighthouse, CrUX...etc).

We recently agreed in the WebPerf WG to resolve the interop issue by revering responseStart to it's older definition (so first bytes, whether Early Hints or document) and adding a finalResponseHeadersStart timing to measure the document first bytes.

Chrome intends to implement this change from Chrome 132 (behind a flag initially).

We should update the web-vitals library to:

1. consolidate on the interop-compatible definition of TTFB (first bytes, whether Early Hints or document). This can be done ahead of the change in Chrome 132.
2. add support for "Document Duration" to TTFB attribution, for those that want to measure this time between the two definitions (note this time will be AFTER TTFB so is a little weird to include in TTFB breakdown, but I think this is the best place for it despite that).

As 1. will be a breaking change we will need a major release. As we have one in flight at the moment (v5), I'm aiming to add it to that rather than wait for v6, despite the fact a release candidate has already been released.