TTFB (under)reporting 0ms on Safari + utm/gclid params

[blue2blond]

I talked with Barry (tunetheweb) during performance.now conference help desk about the TTFB reporting 0ms under these conditions.

This can be seen in the following attachments as well, showing RUM data (I've got more domains if needed).

mobile P80 data of the last 7 days @ [redacted] (soon to be replatformed, date unknown)

mobile P80 data of the last 28 days @ [redacted]:

As we started using the attribution build recently, I'm able to say that this happens both with and without the attribution build (both classic script).

Safari at the top, Google Chrome at the bottom. So:

• 0ms at high percentiles for Safari while Chrome is showing totally different data
• only happens with ad/campaign related query string parameters.
• both for unique and returning visitors
• Gclid is typically throwing a redirect in the mix, but utm-parameters don't always do this, so I'm clueless here (Rick (rviscomi) asked me to file an issue already, but could ask an Apple-minded colleague to test it as well once in the office).

[philipwalton]

Thanks for the report. I couldn't repro this myself using any of those query params, so I don't think the issue actually has anything to do with query params; also it looks like even in your data the page param is working fine.

Given the types of param that you're seeing the issue with, I suspected it had something to do with how those visitors are arriving at your site and not what the final URL shows.

Also, given that these are all marketing params, that lead me to believe the root cause might be an issue with cross-origin redirects, and when I tested a page I know has a cross-origin redirect, I was able to reproduce the issue (not with the web-vitals JS library, but with the web API itself in Safari).

Here are the steps I did to repro:

1. Open Safari and navigate to: https://developers.google.com/web/updates/2018/07/page-lifecycle-api
2. This should automatically redirect you to: https://developer.chrome.com/blog/page-lifecycle-api/
3. Run the following code in the console:

performance.getEntriesByType('navigation')[0].responseStart; // 0

I'm not sure if this is a bug or intentional, but it looks like Safari reports 0 for most values in the Navigation Timing API if there was a cross-origin redirect.

How do you think the web-vitals library should handle these cases? Should we not report TTFB at all for pages with cross-origin redirects in Safari? I know that's not great, but I think it would be better than reporting 0. WDYT?

[blue2blond]

Ah, I should've moved forward/shared my initial and only theory then, as that was what I shared during the perf.now helpdesk session 🙈

I would be inclined to go with "not report TTFB" as well, as percentiles would otherwise be massively skewed.
And when not having browser- or param-filters in your RUM, it would be time-consuming to research (while people tracking this information at least care about + want to address performance, so let's prevent them from spending time on the wrong leads)

[tunetheweb]

@philipwalton what are we doing for bfcache and prerender? If filtering out 0 TTFB then will filter those too presumably? Or do we report the actual TTFB there?

[philipwalton]

IF filtering out 0 TTFB then will filter those too presumably? Or do we report the actual TTFB there?

To clarify, I don't think we should filter out 0 TTFB values, I think we should filter out visits where the navigation entry's responseStart value is 0, because that should not be possible and if it is happening then we know the browser is just not giving us the timing information we need to accurately measure the metric.

what are we doing for bfcache and prerender?

For bfcache we're just reporting 0 (and not looking at the navigation entry at all), and we can continue doing that. For prerender the responseStart value should still be non-zero, even if the final TTFB value we report is 0.