Intent to Deprecate and Remove: Prerender

2483 views
Skip to first unread message

Matthew Cary

unread,
Jan 20, 2017, 8:39:08 AM1/20/17
to blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux

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

unread,
Jan 20, 2017, 8:41:23 AM1/20/17
to Matthew Cary, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
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

unread,
Jan 20, 2017, 8:44:58 AM1/20/17
to Jochen Eisinger, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
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

unread,
Jan 20, 2017, 8:52:47 AM1/20/17
to Matthew Cary, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
do we have means to track potential performance regressions?

Matthew Cary

unread,
Jan 20, 2017, 8:59:43 AM1/20/17
to Jochen Eisinger, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
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

unread,
Jan 20, 2017, 9:00:59 AM1/20/17
to Jochen Eisinger, Matthew Cary, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
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

unread,
Jan 20, 2017, 9:08:43 AM1/20/17
to Yoav Weiss, Jochen Eisinger, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux

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

unread,
Jan 20, 2017, 9:12:00 AM1/20/17
to Yoav Weiss, Jochen Eisinger, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
OWP Launch Tracking Bug

Jochen Eisinger

unread,
Jan 20, 2017, 10:04:29 AM1/20/17
to Matthew Cary, Yoav Weiss, blin...@chromium.org, Egor Pasko, David Roger, Kenji Baheux
lgtm1

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


Chris Harrelson

unread,
Jan 20, 2017, 11:02:21 AM1/20/17
to Jochen Eisinger, Matthew Cary, Yoav Weiss, blink-dev, Egor Pasko, David Roger, Kenji Baheux
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

unread,
Feb 2, 2017, 10:13:36 PM2/2/17
to blink-dev, pa...@chromium.org, dro...@chromium.org, kenji...@chromium.org, matt...@google.com
LGTM3

Egor Pasko

unread,
Apr 26, 2017, 12:39:40 PM4/26/17
to Dimitri, blink-dev, David Roger, Kenji Baheux, Matthew Cary
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

unread,
Apr 26, 2017, 1:22:43 PM4/26/17
to Egor Pasko, Dimitri, blink-dev, David Roger, Kenji Baheux, Matthew Cary

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

unread,
Apr 26, 2017, 1:44:59 PM4/26/17
to PhistucK, Kenji Baheux, Dimitri Glazkov, Egor Pasko, blink-dev, David Roger
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].



Rick Byers

unread,
Apr 26, 2017, 2:24:17 PM4/26/17
to Matthew Cary, PhistucK, Kenji Baheux, Dimitri Glazkov, Egor Pasko, blink-dev, David Roger
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

unread,
Apr 27, 2017, 3:34:47 AM4/27/17
to Rick Byers, PhistucK, Kenji Baheux, Dimitri Glazkov, Egor Pasko, blink-dev, David Roger
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

unread,
Nov 28, 2017, 10:59:27 AM11/28/17
to blink-dev, pa...@chromium.org, dro...@chromium.org, kenji...@chromium.org, matt...@google.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

unread,
Nov 30, 2017, 9:03:11 AM11/30/17
to barabba....@gmail.com, blink-dev, Matthew Cary, kenji...@chromium.org, Dimitri Glazkov, Egor Pasko, David Roger
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

unread,
Nov 30, 2017, 10:40:05 AM11/30/17
to blink-dev, matt...@google.com, phis...@gmail.com, kenji...@chromium.org, dgla...@chromium.org, pa...@google.com, dro...@chromium.org
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ó:
Reply all
Reply to author
Forward
0 new messages