Negative TTFB on Firefox

[jenntilton-qz]

I'm seeing instances of negative values of getTTFB(), exclusively on Firefox, despite the docs claiming that Firefox is a supported browser.

Seems related to this issue.

If it helps, I found that these Navigation Timing attributes are also negative in these cases.

connect_end
connect_start
domain_lookup_start
fetch_start
redirect_end
redirect_start
request_start
response_end
response_start
secure_connection_start
time_to_first_byte

[philipwalton]

What version of the library are you using?

As you might have seen from the Firefox bug you linked to, I commented in that thread that I fixed this issue in v1.1.0. Based on the following code, it shouldn't be possible to report a negative number for any of those values:
https://github.com/GoogleChrome/web-vitals/blob/v1.1.0/src/getTTFB.ts#L42-L44

[kevinmoch-qz]

Same team here as the above questioner -- can confirm we are and have been on v1.1.1.

[philipwalton]

Update: I was looking at the data from a few sites I maintain, and I noticed the negative values as well. It looks like the issue is not the above performance timing bug, but instead a bug with Navigation Timings (as all Firefox versions with negative TTFB I checked support the newer Navigation Timing API).

Row	TTFB	browser	browser_version	operating_system
1	-3998.0	Firefox	87.0	Android
2	-893.0	Firefox	78.0	Macintosh
3	-258.0	Firefox	86.0	Windows
4	-229.0	Firefox	86.0	Windows
5	-157.0	Firefox	78.0	Windows
6	-151.0	Firefox	87.0	Linux
7	-147.0	Firefox	86.0	Macintosh
8	-94.0	Firefox	86.0	Linux
9	-88.0	Firefox	86.0	Windows
10	-82.0	Firefox	78.0	Windows
11	-80.0	Firefox	87.0	Windows
12	-78.0	Firefox	87.0	Android
13	-69.0	Firefox	86.0	Windows
14	-59.0	Firefox	88.0	Windows
15	-53.0	Firefox	87.0	Macintosh
16	-48.0	Firefox	87.0	Macintosh
17	-44.0	Firefox	78.0	Linux
18	-38.0	Firefox	88.0	Windows
19	-25.0	Firefox	85.0	Windows
20	-14.0	Firefox	87.0	Windows

(Note: the total results for Firefox in this query was 3155, which means the negative results represent 0.63%)

I'll file a bug about this with Firefox.

[kevinmoch-qz]

Appreciate this. For our part, we're filtering out the negative values for the time being.

[philipwalton]

Yes, I think it probably does make sense to just not report if the value is negative. I think I'll add that logic to the library itself.

[philipwalton]

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1709427

[bradfrosty]

@nicjansma wrote a great blog post about Navigation Timing in Practice several years back. It might be a bit out of date, but there's some useful context in there including a list of browser bugs (at the time) such as responseStart being reported prior to navigationStart (Ctrl-F for "Browser Bugs").

+1 for adding to the library. His suggestion was:

If you’re analyzing NavigationTiming data, you should ensure that all timestamps increment according to the timeline. If not, you should probably question all of the timestamps and discard.