Skip to content
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

Exposing eagerness in Performance APIs #316

Open
ErwinHofmanRV opened this issue May 10, 2024 · 2 comments
Open

Exposing eagerness in Performance APIs #316

ErwinHofmanRV opened this issue May 10, 2024 · 2 comments

Comments

@ErwinHofmanRV
Copy link

Not in issue, but just checking to see if such feature/flag would be realistic and feasible:

As a RUM provider (built on top of the web-vitals JS library) we're collecting navigation types, including prerendered. And we're seeing some nice data already. But that doesn't apply to all site owners..

To allow site owners to find the sweet spot of applying prerendering, it would be convenient if site owners could see the effectiveness (by filtering the data) per eagerness.

In other words, would it be possible to expose the eagerness with which a page was prerendered by the browser?
This way, next to exposing the navigation type, we can also drill down insights per eagerness-level.

Attached is a percentile chart of prerendering-only navigations of a single (Magento) shop:
prerendering-effectiveness

It basically says:

  • 15% of prerendered navigations is fully successful (0ms ttfb)
  • Another 60% (up to 75th percentile) is below their usual TTFB
  • As of 75th percentile (so, remaining 25%) prerendering isn't helping at all (users clicking really fast after prerender started combined with server response not coming from cache and being slow)

Their moderate level might not be the best fit with their CDN/full page caching strategy as they typically struggle with high TTFB.
By allowing RUM tools to filter per eagerness, site owners can compare effectiveness and adjust their Speculation Rules implementation.

@tunetheweb
Copy link

Wouldn't you be better just looking at performance metrics based on performance.getEntriesByType?.('navigation')[0]?.activationStart?

That would show the lead time that the prerender had. Short ones implies not eager enough. Of course that may be because user clicked on a link quickly despite it being very eager, but I'm not sure how knowing the eagerness setting would help in that case as can't make it any more eager in that case anyway.

@jeremyroman
Copy link
Collaborator

Yeah, would be interested in knowing more about the value this would deliver. It's at least in principle something that could be exposed in the same-origin case.

But it seems like you'd want to know more than the eagerness if you wanted to dig into this. Maybe, for example, there typically is enough lead time for clicks on the banner image but not usually enough on the "More info" element. Knowing that the navigations that need improvement come from some particular site feature would seem to me, naively, to be the most useful thing -- and then you know (possibly in combination with some experiment group) what eagerness was used for that anyway. Today I think a query parameter (like utm_content) is the most typical way of learning that.

On the other hand, it may well be that sites aren't always set up to pass this information along, and finding some useful proxy for this is worthwhile in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants