Intent to Deprecate and Remove: <link rel=subresource>

1334 views
Skip to first unread message

Yoav Weiss

unread,
Jan 27, 2016, 4:50:24 PM1/27/16
to blink-dev

Primary eng email

yo...@yoav.ws / yoav....@akamai.com


Summary

Remove support for the "subresource" rel of HTMLLinkElement


Motivation

The "subresource" rel never really did what it was intended to do, as the resources that it downloaded were downloaded with low priority. On top of that it was never shipped in any browsers other than Chromium based ones, and its Blink implementation is buggy, and results in double downloads. Also, removing it from the code base would enable to lower the complexity of LinkLoader.


Compatibility Risk

The API has been around for a long while, but was only supported by Chrome, and is not critical in nature (i.e. lack of support doesn't break content). I believe removing it poses a very low to non-existent compatibility risk.


Alternative implementation suggestion for web developers

Web developers should use the "preload" rel that now supersedes "subresource".


Usage information from UseCounter

Usage was close to 0 up until a few months back. For some reason usage got bumped to 0.02% between October 15 and 17. From the nature of that jump, it is likely a single fairly large entity that decided to add "subresource" to their markup. Since the current implementation double downloads, this entity is likely to benefit from the removal of "subresource". In any case, content will not break, and 0.02% is still below our threshold for removal.


OWP launch tracking bug

crbug.com/581840


Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Requesting approval to remove too?

Yes, please!

Dimitri Glazkov

unread,
Jan 27, 2016, 4:52:23 PM1/27/16
to Yoav Weiss, blink-dev
LGTM1.

Rick Byers

unread,
Jan 27, 2016, 5:03:27 PM1/27/16
to Dimitri Glazkov, blink-dev, Yoav Weiss

LGTM2

Note that 0.03% isn't "our threshold for removal' - just a rule of thumb below which considering removal is probably worthwhile.  But since there's really no way this removal can break anyone, higher would be fine.

Ilya Grigorik

unread,
Jan 27, 2016, 6:50:04 PM1/27/16
to Rick Byers, Dimitri Glazkov, blink-dev, Yoav Weiss
(non-owner) LGTM and hooray.. finally!

Chris Harrelson

unread,
Jan 27, 2016, 8:26:56 PM1/27/16
to Ilya Grigorik, Rick Byers, Dimitri Glazkov, blink-dev, Yoav Weiss
LGTM3

--
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.

Joe Medley

unread,
Jan 29, 2016, 11:36:36 AM1/29/16
to Yoav Weiss, blink-dev
On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672

Can you please add one.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

Yoav Weiss

unread,
Feb 1, 2016, 6:56:48 AM2/1/16
to Joe Medley, blink-dev

Joe Medley

unread,
Feb 1, 2016, 11:40:02 AM2/1/16
to Yoav Weiss, blink-dev
Thank you.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

edeni...@yahoo.com.br

unread,
Jun 1, 2016, 7:11:26 PM6/1/16
to blink-dev

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:55:34 AM6/21/16
to blink-dev
Yes, please

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:56:00 AM6/21/16
to blink-dev, yo...@yoav.ws
Yes, please! 

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:56:17 AM6/21/16
to blink-dev, dgla...@chromium.org, yo...@yoav.ws, rby...@google.com
Yes, please!

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:56:30 AM6/21/16
to blink-dev, rby...@google.com, dgla...@chromium.org, yo...@yoav.ws, igri...@google.com
LGTM1.
Yes, please!

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:59:03 AM6/21/16
to blink-dev, yo...@yoav.ws
Yes, please!


On Saturday, 30 January 2016 00:36:36 UTC+8, Joe Medley wrote:

On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672

Can you please add one
 

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:59:26 AM6/21/16
to blink-dev, jme...@google.com


On Monday, 1 February 2016 19:56:48 UTC+8, Yoav Weiss wrote:
On Fri, Jan 29, 2016 at 5:36 PM, Joe Medley <jme...@google.com> wrote:

On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672

Can you please add one.

oro.ja...@gmail.com

unread,
Jun 21, 2016, 10:59:35 AM6/21/16
to blink-dev, edeni...@yahoo.com.br

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:00:07 AM6/21/16
to blink-dev, oro.ja...@gmail.com

Yes, please!

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:00:34 AM6/21/16
to blink-dev
Yes, please!


On Thursday, 28 January 2016 05:50:24 UTC+8, Yoav Weiss wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:00:47 AM6/21/16
to blink-dev, yo...@yoav.ws
Yes, please!

On Thursday, 28 January 2016 05:52:23 UTC+8, Dimitri Glazkov wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:00:57 AM6/21/16
to blink-dev, dgla...@chromium.org, yo...@yoav.ws, rby...@google.com
Yes, please!

On Thursday, 28 January 2016 06:03:27 UTC+8, Rick Byers wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:01:06 AM6/21/16
to blink-dev, rby...@google.com, dgla...@chromium.org, yo...@yoav.ws, igri...@google.com
Yes, please!

On Thursday, 28 January 2016 07:50:04 UTC+8, Ilya Grigorik wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:01:21 AM6/21/16
to blink-dev, igri...@google.com, rby...@google.com, dgla...@chromium.org, yo...@yoav.ws, chri...@chromium.org

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:02:30 AM6/21/16
to blink-dev, yo...@yoav.ws

On Saturday, 30 January 2016 00:36:36 UTC+8, Joe Medley wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:03:22 AM6/21/16
to blink-dev, yo...@yoav.ws


On Saturday, 30 January 2016 00:36:36 UTC+8, Joe Medley wrote:

On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672

Can you please add one.

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:03:30 AM6/21/16
to blink-dev, jme...@google.com

On Monday, 1 February 2016 19:56:48 UTC+8, Yoav Weiss wrote:

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:03:46 AM6/21/16
to blink-dev, yo...@yoav.ws


On Tuesday, 2 February 2016 00:40:02 UTC+8, Joe Medley wrote:
Thank you.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

On Mon, Feb 1, 2016 at 3:56 AM, Yoav Weiss <yo...@yoav.ws> wrote:
On Fri, Jan 29, 2016 at 5:36 PM, Joe Medley <jme...@google.com> wrote:

On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)


Actually we do put deprecation/removal items. For example: https://www.chromestatus.com/features/5736166087196672

Can you please add one.

oro.ja...@gmail.com

unread,
Jun 21, 2016, 11:04:00 AM6/21/16
to blink-dev, edeni...@yahoo.com.br


On Thursday, 2 June 2016 07:11:26 UTC+8, edeni...@yahoo.com.br wrote:
Yes, please! 

theot...@gmail.com

unread,
Jul 29, 2016, 11:07:40 AM7/29/16
to blink-dev

Theo Alves

unread,
Jul 30, 2016, 11:47:02 AM7/30/16
to blink-dev
Resumo
Remover o suporte para o rel "subrecurso" de HTMLLinkElement

Motivação
O rel "subrecurso" nunca realmente fez o que tinha a intenção de
fazer, como os recursos que baixado foram baixadas com baixa
prioridade. Em cima do que ele nunca foi enviado em quaisquer outros
do que aqueles baseados Chromium navegadores, e sua implementação
Blink é buggy e resulta em descargas duplas. Além disso, removendo-o
da base de código permitiria a reduzir a complexidade da LinkLoader.

Risco de compatibilidade
A API tem sido em torno de um longo tempo, mas só foi apoiado pelo
Chrome, e não é de natureza crítica (ou seja, falta de apoio não
quebrar conteúdo). Acredito que removê-lo representa uma muito baixa
ao risco de compatibilidade inexistente.

sugestão alternativa de implementação para os desenvolvedores web
Os desenvolvedores da Web deve usar o rel "pré-carga", que agora
substitui "sub-recurso".

informações de uso de UseCounter
Uso estava perto de 0 até alguns meses atrás. Por alguma razão o uso
got batido para 0,02% entre 15 de outubro e 17. A partir da natureza
desse salto, é provável que uma única entidade bastante grande que
decidiu acrescentar "sub-recurso" para a sua marcação. Desde a
implementação atual de downloads duplas, essa entidade é susceptível
de beneficiar da remoção de "sub-recurso". Em qualquer caso, o
conteúdo não irá quebrar, e 0,02% é ainda inferior a limiar de
remoção.

OWP bug tracking lançamento
crbug.com/581840

Entrada no painel recurso
No entry no painel recurso como eu não tenho certeza se devo
acrescentar um só para fins de remoção. Se eu devo, eu vou :)

O pedido de aprovação para remover também?
Sim por favor!
-
Você recebeu esta mensagem porque se inscreveu para um tópico no grupo
Grupos do Google "blink-dev".
Para cancelar a assinatura deste tópico, visite
https://groups.google.com/a/chromium.org/d/topic/blink-dev/Y_2eFRh9BOs/unsubscribe.
Para sair deste grupo e todos os seus temas, envie um e-mail para
blink-dev+...@chromium.org.

2016-07-29 12:07 GMT-03:00, theot...@gmail.com <theot...@gmail.com>:
>
>
> Em quarta-feira, 27 de janeiro de 2016 19:50:24 UTC-2, Yoav Weiss escreveu:
>>
>> Primary eng email
>>
>> yo...@yoav.ws <javascript:> / yoav....@akamai.com <javascript:>
>>
>> Summary
>>
>> Remove support for the "subresource" rel of HTMLLinkElement
>>
>> Motivation
>>
>> The "subresource" rel never really did what it was intended to do, as the
>>
>> resources that it downloaded were downloaded with low priority. On top of
>>
>> that it was never shipped in any browsers other than Chromium based ones,
>>
>> and its Blink implementation is buggy, and results in double downloads.
>> Also, removing it from the code base would enable to lower the complexity
>>
>> of LinkLoader.
>>
>> Compatibility Risk
>>
>> The API has been around for a long while, but was only supported by
>> Chrome, and is not critical in nature (i.e. lack of support doesn't break
>>
>> content). I believe removing it poses a very low to non-existent
>> compatibility risk.
>>
>> Alternative implementation suggestion for web developers
>>
>> Web developers should use the "preload <https://w3c.github.io/preload/>"
>> rel that now supersedes "subresource".
>>
>> Usage information from UseCounter
>> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
>>
>> Usage was close to 0 up until a few months back. For some reason usage
>> <https://www.chromestatus.com/metrics/feature/timeline/popularity/916>
>> got bumped to 0.02% between October 15 and 17. From the nature of that
>> jump, it is likely a single fairly large entity that decided to add
>> "subresource" to their markup. Since the current implementation double
>> downloads, this entity is likely to benefit from the removal of
>> "subresource". In any case, content will not break, and 0.02% is still
>> below our threshold for removal.
>>
>>
>> OWP launch tracking bug
>>
>> crbug.com/581840
>>
>> Entry on the feature dashboard <https://www.chromestatus.com/>
>>
>> No entry on the feature dashboard as I'm not sure if I should add one just
>>
>> for removal purposes. If I should, I will :)
>>
>> Requesting approval to remove too?
>>
>> Yes, please!
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/Y_2eFRh9BOs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> blink-dev+...@chromium.org.
>

girl.ch...@gmail.com

unread,
Jan 5, 2017, 7:44:03 PM1/5/17
to blink-dev


On Wednesday, January 27, 2016 at 11:50:24 PM UTC+2, Yoav Weiss wrote:

Summary

Remove support for the "subresource" rel of HTMLLinkElement


Motivation

The "subresource" rel never really did what it was intended to do, as the resources that it downloaded were downloaded with low priority. On top of that it was never shipped in any browsers other than Chromium based ones, and its Blink implementation is buggy, and results in double downloads. Also, removing it from the code base would enable to lower the complexity of LinkLoader.


Compatibility Risk

The API has been around for a long while, but was only supported by Chrome, and is not critical in nature (i.e. lack of support doesn't break content). I believe removing it poses a very low to non-existent compatibility risk.


Alternative implementation suggestion for web developers

Web developers should use the "preload" rel that now supersedes "subresource".


Usage information from UseCounter

Usage was close to 0 up until a few months back. For some reason usage got bumped to 0.02% between October 15 and 17. From the nature of that jump, it is likely a single fairly large entity that decided to add "subresource" to their markup. Since the current implementation double downloads, this entity is likely to benefit from the removal of "subresource". In any case, content will not break, and 0.02% is still below our threshold for removal.


OWP launch tracking bug

crbug.com/581840


Entry on the feature dashboard

No entry on the feature dashboard as I'm not sure if I should add one just for removal purposes. If I should, I will :)

theopa...@gmail.com

unread,
Feb 28, 2017, 12:41:17 PM2/28/17
to blink-dev

gilmaral...@gmail.com

unread,
May 6, 2017, 7:46:42 AM5/6/17
to blink-dev, yo...@yoav.ws


Em quarta-feira, 27 de janeiro de 2016 19:52:23 UTC-2, Dimitri Glazkov escreveu:
LGTM1.

On Wed, Jan 27, 2016 at 1:50 PM, Yoav Weiss <yo...@yoav.ws> wrote:

deven...@gmail.com

unread,
Jul 1, 2017, 1:42:07 PM7/1/17
to blink-dev

sadame...@gmail.com

unread,
Jul 7, 2017, 8:35:03 AM7/7/17
to blink-dev

thali...@hotmail.com

unread,
Aug 31, 2017, 3:49:44 PM8/31/17
to blink-dev


Em quarta-feira, 27 de janeiro de 2016 19:50:24 UTC-2, Yoav Weiss escreveu:

sonid...@yahoo.com.mx

unread,
Oct 2, 2017, 1:48:21 AM10/2/17
to blink-dev

ohen...@gmail.com

unread,
Oct 23, 2017, 4:21:31 PM10/23/17
to blink-dev


On Wednesday, January 27, 2016 at 4:50:24 PM UTC-5, Yoav Weiss wrote:

vrmur...@gmail.com

unread,
Nov 9, 2017, 5:58:18 AM11/9/17
to blink-dev

d.dyoungcal...@gmail.com

unread,
Apr 13, 2020, 12:24:49 PM4/13/20
to blink-dev


El miércoles, 27 de enero de 2016, 16:50:24 (UTC-5), Yoav Weiss escribió:

Iwan Lesmana Riza

unread,
Apr 14, 2020, 1:40:19 AM4/14/20
to d.dyoungcal...@gmail.com, blink-dev
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e48e9d6c-80eb-4bf9-aed6-31adad639cdd%40chromium.org.

sanad...@gmail.com

unread,
Jun 24, 2020, 4:58:09 PM6/24/20
to blink-dev
Reply all
Reply to author
Forward
0 new messages