PerformanceServerTiming entry always has a duration field even when the original header did not

[andydavies]

The PerformanceServerTiming entry always has a duration field even if the original Server-Timing header did not

For example, if the response contains this header

Server-Timing: cdn-cache; desc=REVALIDATE

Then the corresponding entry will be:

PerformanceServerTiming
  description: "REVALIDATE"
  duration: 0
  name: "cdn-cache"

This makes is impossible to know just from the API whether the header had no duration, or whether it had a duration and it was 0

[clelland]

I think you're correct there -- the duration getter starts with

If this's params["dur"] does not exist, return 0.

I'm guessing that you'd prefer that duration was nulllable, and null in that case. Is that correct? As it's an interface and not a dictionary, I don't think we can omit it.

We also set it to 0 currently, if the value in the header cannot be parsed as a float; DOMHighResTimeStamp doesn't have any error-signalling values that we can use. In an error case, is it better to continue to return 0, or to return null in that case as well?

[andydavies]

Yeh, duration being nullable would work for our use case.

I'll have a think about the invalid value case and I'm not sure on the answer ATM. I think null would be my preference but will ask the rest of the team

[nicjansma]

Agreed that a nullable duration would be ideal here so we can distinguish.

Personally I think if the number can't be parsed, duration being set to null would be fine as well.