New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should prefetch be exposed? #163
Comments
The first option seems fine to me. What's the navigationStart when prefetch is used? |
It's still after the user clicks the link (or otherwise starts a navigation), in my view. |
I want to +1 to what Dan said in the WebPerfWG that resource timing seems to be a more appropriate place for this. I assume we can't use existing timing attributes to implicitly expose whether a page is fetched? If not, then I wonder if another option could be to introduce a new timing attribute to do expose that implicitly? |
I think it's possible. For sake of argument...
Looking from the outside, a successful (adopted) prefetch looks the same to having a resource in memory / disk cache. |
Yoav and I will review the previous discussion and will present options in a future WebPerf WG call to move this forward. |
So it seems like we have multiple options here:
I tend to agree that an indicator on the ResourceTiming entry (which NavigationTiming will inherit) may be a better fit. This seems related to w3c/resource-timing#303 as well as directly exposing if a resource was fetched from the cache (compared to today's jumping through hoops with /cc @noamr |
Discussed on Apr 28 WebPerf WG call: https://w3c.github.io/web-performance/meetings/2022/2022-04-28/index.html Summary:
|
We're working on navigational prefetch and think it would be useful for developers to, at a minimum, be able to tell whether the page was prefetched (so they can look at their analytics through this lens).
It seemed to me that the navigation timing API (and friends) might provide a natural place for this to be exposed, assuming we can do so in a way that suitably private, since it feels like information about navigation load performance much like the rest of PerformanceNavigationTiming.
A few sketches of what this could look like:
Boolean describing the navigation itself
Interface attached to the navigation
Separate event describing the prefetch, possibly with its (negative) start time adjusted to preserve privacy (at least if cross-origin). Implies including all the redirect, transfer size, TLS negotiation, etc timing info. ordinarily available for other resources.
We should of course consider whether information must be censored/omitted in some/all cases to avoid cross-site tracking vectors, but I actually suspect this is not a major issue since a site can always associate a prefetch with the associated navigation (e.g., by embedding a unique identifier in the response).
@npm1 @horo-t @buettner
The text was updated successfully, but these errors were encountered: