It would be really sweet to be able to oversample page loads that took more than some threshold to load (eg, page load took more than 10 seconds, 30 seconds, whatever).
We could do some post-processing on these to understand whether they were a result of client side network issues or something more fundamental on our end, and potentially ignore them in the former case.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Imarlier | T181413 Refactor NavigationTiming extension so that it can be used to oversample based on criteria | |||
| Declined | None | T181956 Collect extra data and oversample views with higher page load times |
I wonder if we could do something smart here with the Resource Timing API? Or what kind of things do we want to catch? Like if the latency looks the same for all resources there's no need to collect the data?
My 2 cents here: I think it will be worth checking where are your percentiles 90 and 99 now (per country probably). If data jumps a lot there it is telling of something going on at the long tail of the timeseries, either there is not enough data or there are some hidden effects we are not seeing. Now, if those numbers are very stable it is really not worthy to spend time troubleshotting what might be complete outliers to the series.
We plan on ramping up the RUM sampling factor by a lot, which reduces the need for this somewhat. However, we'd still like to also do a non-default beacon with extra information that might help learn why it is slow, for example, a compressed breakdown of Resource Timing information.
The ResourceTiming beacon could be something we then only send from a fraction of users and slow page views.
I think this is an interesting idea, maybe as @Krinkle said it will be fixed automatically by higher sampling, but lets keep this issue until we know.
We don't see an actionable outcome from these measurements right now, so we will focus on other priorities