Intent to Deprecate and Remove: Prerender

[Matthew Cary]

Contact emails

pa...@chromium.org, dro...@chromium.org, matt...@chromium.org

Summary

Disable prerendering in chrome. This will not break any sites, but may cause a performance regression.

Motivation

Prerender is difficult to maintain and wastes resources compared to its performance benefit. More efficient ways to achieve the same performance goal are in development, but as they will behave quite differently from prerender we need to resolve any unknown external dependencies by deprecating prerender cleanly.

Compatibility and Interoperability Risk

As prerender is a best-effort performance feature only, there is no compatibility risk. The most performance sensitive use of prerender we know of (invoking prerender through the CCT mayLaunchURL API) will not be immediately deprecated.

Usage Information

Detailed usage statistic are available only through Google internal UMA counters. In summary, of the times link-rel prerender is triggered, under 15% are used. Approximately 0.2% of all navigations trigger prerender (these counts are from UMA users, a possibly-biased subset of all chrome users). Link-rel prerenders are the non-CCT externally facing prerender API.

Launch Tracking Bug

http://crbug.com/678332

Requesting approval to remove too?

Yes, although as there is no API change there is no practical difference between deprecation and removing.

[Jochen Eisinger]

What will happen if a site includes a <link rel=prerender> or a corresponding header? Will we ignore that, or treat it as preload, or still prerender?

[Matthew Cary]

It will be ignored. We are concurrently starting up an experiment for the prefetching feature mentioned above that will be invoked instead on a <link rel=prerender>. This new feature will essentially perform an extended prefetch by running the preload scanner on the main resource; see the linked doc for all the details.

[Jochen Eisinger]

do we have means to track potential performance regressions?

[Matthew Cary]

We will be running the deprecation through an experiment and can track if the regressions are significant.

That said, it is clear that this will regress performance. According to our data (as mentioned in the usage information), we believe the performance regression will be minor. It may be that there are specific cases with large impact which will need special handling that will be discovered only through the deprecation process.

[Yoav Weiss]

On Fri, Jan 20, 2017 at 2:52 PM Jochen Eisinger <joc...@chromium.org> wrote:

do we have means to track potential performance regressions?

On Fri, Jan 20, 2017 at 2:44 PM Matthew Cary <matt...@google.com> wrote:

It will be ignored. We are concurrently starting up an experiment for the prefetching feature mentioned above that will be invoked instead on a <link rel=prerender>. This new feature will essentially perform an extended prefetch by running the preload scanner on the main resource; see the linked doc for all the details.

Just to verify, <link rel=prerender> will stay supported, just ignored for now and later rerouted to the no-state prefetch backend?

 

On Fri, Jan 20, 2017 at 2:41 PM, Jochen Eisinger <joc...@chromium.org> wrote:

What will happen if a site includes a <link rel=prerender> or a corresponding header? Will we ignore that, or treat it as preload, or still prerender?

On Fri, Jan 20, 2017 at 2:39 PM 'Matthew Cary' via blink-dev <blin...@chromium.org> wrote:

Contact emails

pa...@chromium.org, dro...@chromium.org, matt...@chromium.org

Summary

Disable prerendering in chrome. This will not break any sites, but may cause a performance regression.

Motivation

Prerender is difficult to maintain and wastes resources compared to its performance benefit. More efficient ways to achieve the same performance goal are in development, but as they will behave quite differently from prerender we need to resolve any unknown external dependencies by deprecating prerender cleanly.

Compatibility and Interoperability Risk

As prerender is a best-effort performance feature only, there is no compatibility risk. The most performance sensitive use of prerender we know of (invoking prerender through the CCT mayLaunchURL API) will not be immediately deprecated.

Usage Information

Detailed usage statistic are available only through Google internal UMA counters. In summary, of the times link-rel prerender is triggered, under 15% are used. Approximately 0.2% of all navigations trigger prerender (these counts are from UMA users, a possibly-biased subset of all chrome users). Link-rel prerenders are the non-CCT externally facing prerender API.

Launch Tracking Bug

http://crbug.com/678332

The issue seems to be Google only (or restricted to public access in some other way)

 

Requesting approval to remove too?

Yes, although as there is no API change there is no practical difference between deprecation and removing.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Matthew Cary]

Just to verify, <link rel=prerender> will stay supported, just ignored for now and later rerouted to the no-state prefetch backend?

Yes, exactly. link rel=prerender has always been best-effort so ignoring it does not break the API.

Launch Tracking Bug

http://crbug.com/678332

The issue seems to be Google only (or restricted to public access in some other way)

Oops, that's the internal google experiment/launch bug. Let me create an OWP bug.

 

 

Requesting approval to remove too?

Yes, although as there is no API change there is no practical difference between deprecation and removing.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Matthew Cary]

OWP Launch Tracking Bug

http://crbug.com/683142

[Jochen Eisinger]

lgtm1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

LGTM2

lgtm1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri]

LGTM3

[Egor Pasko]

Update: M58 is rolling to Stable with Prerendering disabled for 99% of users

AMP viewer prerenders and the PrerenderingOffliner are excluded in this phase, they will continue working as usual.

During the following month we are planning to re-enable Prerendering briefly for ~5% of users as an experiment and to compare it against nostate-prefetch (http://goo.gl/EJjTCM).

Summary about effects observable from Beta:

1. Prerenders affect about 3% of page loads on Desktop and about 0.3% on Android

2. nostate-prefetch First Contentful Paint is usually in the middle between Prerendered and would-have-Prerendered

3. We did not have enough data on Beta to evaluate the effect on performance in depth

On Fri, Feb 3, 2017 at 4:13 AM, Dimitri <dgla...@chromium.org> wrote:

LGTM3

--

Egor Pasko

[PhistucK]

On Wed, Apr 26, 2017 at 7:39 PM, 'Egor Pasko' via blink-dev <blin...@chromium.org> wrote:

AMP viewer prerenders and the PrerenderingOffliner are excluded in this phase

:| ​Is this a hard coded domain restriction?​

☆PhistucK

[Matthew Cary]

The offliner is an internal feature that uses the prerendering code path [1] for rendering offline pages. The AMP viewer is prerendered via a custom tabs API that's restricted to first-party apps; that is for the official chrome build restricted to com.google, but could be accessible in other builds [2].

[1] https://cs.chromium.org/chromium/src/chrome/browser/prerender/prerender_manager.cc?rcl=57934e7bb8f2c9c787b61ee7f3b41dbc11f1760d&l=302

[2] https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/customtabs/CustomTabsConnection.java?rcl=57934e7bb8f2c9c787b61ee7f3b41dbc11f1760d&l=105

[Rick Byers]

Right.  Said another way, prerender still exists in some form as a browser feature, but it is not a web platform feature whatsoever (for any sites - we generally avoid having any site-specific web-platform behavior).

[Matthew Cary]

Thanks, Rick, that is a more clear way to say it.

Also note that those two last uses of prerender will also disappear soon as there are alternatives in development (eg, here). We would have liked to deprecate everything at once, but we'll take a piecemeal solution :)

[giovanni...@gmail.com]

Any update? Will Chrome ignore prerender meta tag or not? I think it is useful as SEO, I implemented it in many websites with speed improvements. Please, do not ignore it :)

[PhistucK]

I believe Rick meant that in Chrome, it will not be a supported web platform feature. That does not mean it is not included in a specification.

☆PhistucK

On Thu, Nov 30, 2017 at 3:51 PM, <barabba....@gmail.com> wrote:

Not a web platform feature? It's in the spec: https://www.w3.org/TR/resource-hints/#prerender

[barabba....@gmail.com]

Not a web platform feature? It's in the spec: https://www.w3.org/TR/resource-hints/#prerender

El miércoles, 26 de abril de 2017, 20:24:17 (UTC+2), Rick Byers escribió: