Add Callback to Prerender State

[giorgiopellegrino]

Hello,

It is critical for our Luxottica team to develop a script that receives a callback or promise that indicates the current state of the prerender. In particular, we would like to know if it is currently in "Ready" or "Not triggered" state.

This is crucial to optimizing the performance of our website, as we want to implement specific actions based on the state of the prerender. For example, if the prerender is "Ready", we would like to prefetch on iOS devices (using https://getquick.link/) in order to improve loading times for real users. This would allow us to optimise the LCP indicator.

Please provide us with the necessary information to access the prerender status through a callback or promise, so we can implement our optimization actions.

We look forward to your kind response.
@gilbertococchi

Giorgio Pellegrino
Web Performance Consultant at Luxottica Group S.P.A.

[domenic]

Thanks for filing this! However, can you expand on the use cases more? The one you mention is

For example, if the prerender is "Ready", we would like to prefetch on iOS devices (using https://getquick.link/) in order to improve loading times for real users.

However, iOS devices do not support prerendering, and all their web browsers are controlled by Apple, which so far has not shown any interest in implementing these technologies. So, nothing we could do would help you there.

[giorgiopellegrino]

Dear @domenic ,

I apologize if my previous communication was unclear.

We need you to provide a callback that is called when a prerender’s status is returned, and that emits a state of "ready", "failure" or "not triggered". In this way, if the state is not "ready", we are considering the option to start a prefetch. We want to avoid the use of speculation rules for prefetch because Quicklink also allows prefetch on iOS devices.

Would it be possible to provide a callback in the code that returns the status indicated in the development tools such as those mentioned below?

STATUS READ
STATUS NOT TRIGGERED

I remain available for any clarification or additional questions.

Best regards,

Giorgio

[domenic]

Hi Giorgo,

We need to take a step back here and discuss use cases. You are jumping straight to a possible API. But we can't ship APIs without knowing why we are shipping them. We start with use cases, then talk about various possible solutions. One of them might be the API you propose, but there may be many others, and we need to have a larger discussion with the various communities involved before settling on the best one.

Can you outline your use case? What are you trying to do today, that is not possible with the current set of APIs? What is the desired end-user experience that you are trying to create, which you cannot create today? Maybe we can brainstorm together on whether there's a way to use existing APIs to accomplish what you're working toward.

Keep in mind that we don't have any control over iOS, so it's best to focus your use cases on platforms like desktop Chrome and Android Chrome.

I hope this helps,
-Domenic

[giorgiopellegrino]

Dear @domenic ,

I would like to provide you with a more detailed description of our use case and current project.
In collaboration with Google, represented by @gilbertococchi, we have started a series of AB tests on Luxottica's e-commerce page.

About the Prerender, the test involves directing

• 50% of the traffic to a version of the Ray-Ban.com product page (PDP) in which the custom product page (PCP) is prerendered,
• 50% of the traffic does not undergo such prerendering

Considering that Chrome could decide to not execute the Prerender according to some limits (as reported in this article https://developer.chrome.com/docs/web-platform/prerender-pages#chrome_limits) and since we noticed a big loss of users not viewing the prerendered page, we evaluated the option of applying the PCP prefetch in the PDP as a fallback.

Currently, our main problem is the inability to determine in real-time whether the prerendering has been done correctly ('Ready' status) or not. Therefore, we are requesting the possibility of adding a callback to the API to monitor this operation. This forms the core of our use case.

We are available for further details and insights and would be happy to discuss this topic with our contact person @gilbertococchi.

Thank you for your kind attention.

Giorgio

[domenic]

Thanks. So I think what I'm hearing is that the use case is falling back from prerender to prefetching. Is that correct? If so, we're exploring having that happen automatically, which is being discussed in the similar issue #162.

For a variety of reasons, this automatic fallback is much more likely to be implementable than something which exposes the state of the prerendered page. But it sounds like it will work just as well for accomplishing your use case. Is that correct?

[ErikWitt]

We have a slightly different use case that would also rely on feedback to the speculation rules (not necessarily a callback).

Our use case would be tracking the result to derive some insights:

1. In which scenarios does the browser not prerender (plus a potential reason why)
2. What are the most common reasons for a prerender to fail (we have seen a few already like ad blocker, e.g. ublock but it is hard to know what the scale of these issues is)
3. How many pretenders where issued (to compute precision easier)

This would help to fine tune our prediction and use of speculation rules.

Right now it is sometimes hard to know why a page is not prerendered. Is it our prediction system, did Chrome not attempt the prerender, did the prerender fail, ...

In production we see that around 50% of navigation we would deem prerenderable are actually delivered as prerendered page views. Very hard to categorise why the other 50% are not