How does this work in a subscriber based model?

[justinph]

Some publishers rely on subscriptions models to pay their bills. The result is restricting access to content from users that are non-subscribers, e.g. displaying a paywall. Usually the information about whether a user is subscriber is represented by a cookie. A private prefetch, without cookies, would be unable to differentiate users and their subscription/access status.

Is there any thought on how private prefetch proxies might accomodate such a scenario?

I can envision a couple scenarios:

• For publishers that want to participate and want the pre-rendered benefits, the first click must be free
• The client does the necessary work on full navigation to determine the user's subscription/access, and this may result in large re-renders and associated performance impacts
• Publishers choose not to participate

[darobin]

I think there might be other ways to make it work. If the whole content is loaded and pre-rendered, on full navigation the decision as to whether to show a paywall or not can be made quickly. So the UX shouldn't be problematic. For CWV purposes, maybe there should be a way to exclude paywall operations from re-renders so that there is no business model penalty?

[justinph]

@darobin Yeah I think that makes sense. I conflated pre-rendering and pre-fetching a bit in my question, but I think it'd be good to think about in a general sense. Pre-fetching seems doable. Pre-rendering, not so much.

Most publishers with subscription models do send the entire asset to every visitor regardless of subscription status and then rely on client logic at render time to truncate or obfuscate the asset for readers who are deemed to be non-subscribers. But not every publisher does this; some have a harder paywall. Perhaps this latter model is just incompatible with prefetching and that's an unavoidable side effect.

[darobin]

For harder paywalls, I wonder if they couldn't "just" truncate at the fold and load the content below the fold dynamically.

[buettner]

Thanks for the interest Justin and Robin!

You are correct: if a request would carry a cookie on a normal user navigation, the browser can’t make a prefetch request without the cookie and then naively use the response. The subscriber example is one reason, and in general personalization based on cookies would not happen. Prefetches can only be used safely if the browser did not already have a cookie for the origin.

However, there is a related proposal to allow publishers to “opt-in” to uncredentialed prefetch/prerender, either because their page content does not differ based on cookies (though they may use them for other purposes), or because they have implemented a way to “upgrade” the page when the user navigates.

For the paywall scenario, we envisioned exactly what you folks mention on this thread -- on navigation, JS can check for the user cookie or make an XHR to the server and then hide/unhide the content. For personalization, a template of the page and any critical resources could be prefetched, and once the user navigates and the user cookie is sent, then the content will be fetched via XHR (this is similar to your hard paywall example).

[buettner]

Closing this issue as it's been quiet for 6 months. Feel free to re-open if you'd like to discuss more!