You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
It basically says:
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.
The text was updated successfully, but these errors were encountered: