New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 112941 link

Starred by 15 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Blocking:
issue 324820



Sign in to add a comment

Support "sizes" attribute of <link rel="icon"...>

Project Member Reported by wangxianzhu@chromium.org, Feb 7 2012

Issue description

For now the "sizes" attribute of <link rel="icon"...> (http://www.w3.org/TR/html5/links.html#rel-icon) is ignored. The page designer might want to provide icons with different sizes and let the browser select the most proper one.
 
Labels: -Type-Bug Type-Feature
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 3 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
The absence of support of the "sizes" attribute has a side effect: https://code.google.com/p/chromium/issues/detail?id=324820 . Whenever the present issue is fixed, bug 324820 can probably be closed, too.

Comment 5 by tkent@chromium.org, Aug 18 2015

Labels: -Pri-2 -Cr-Blink Pri-3 Cr-Blink-HTML Cr-Blink-HTML-Link
Status: Available

Comment 6 by tkent@chromium.org, Aug 18 2015

Blocking: chromium:324820

Comment 7 by pdr@chromium.org, Feb 15 2016

Cc: esprehn@chromium.org
Labels: Hotlist-Loading
I think we should raise the priority on this bug because it has real costs for mobile users today.

As philippe.bernard pointed out in https://crbug.com/324820, by not supporting sizes we end up loading all favicons listed. Our best-practices documentation (https://developer.chrome.com/multidevice/android/installtohomescreen) recommends listing multiple favicon entries for mobile resolutions. The end effect is that it is not possible to have pixel-perfect favicons without wasting both memory and bandwidth. For an example of this issue in the wild you can use the Alphabet homepage: https://abc.xyz
Project Member

Comment 8 by sheriffbot@chromium.org, Feb 14 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: talo@chromium.org
Re: impact

1. Loading: virtually no impact on Loading performance since favicon requests happen after everything else is done (and after the onload event). Source: [1] 

2. Data: depends on how popular the different extra sizes are on the web.  [1] also suggests that we might not be fetching all sizes afterall (TBC). 

Worst case scenario:
Baseline
16x16

Android
36x36
48x48
72x72
96x96
144x144
192x192

Assuming we only needed the high res one (192x192):
 * 39k pixels wasted
 * at 24bits, uncompressed => 114 KB
 * at ~2:1 compression => 50KB

Average size of a page load (first visit): ~3MB (per HTTPArchive)
Leading to an estimated 1.6% inflation of the weight of a page load.

+Talo to see if this would register in terms of EM concerns.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=324820#c7
kenjibaheux, I'd just like to point out a few small disagreements and different observations.

Even though loading happens after the onload event, there may be other resources that a web application has requested after that - usually either dynamically loaded media or something through XHR. Unnecessary favicon requests compete with those requests. And even if they don't, every byte counts on mobile and can even cost $.

It does seem that Chrome ignores `<link rel="apple-touch-icon" ...`, which is good because those files can be much bigger, and there are many more of them.

From my research, I think it's more useful to look at latency, rather than the small percentage of inflation. I'm seeing some examples where each request takes about 250-350KB, even on a CDN and a decent wifi connection. Almost all of that time is spent in making the HTTP connection and waiting for a response, so it's independent of file size. With 2 or more wasted requests, that can add up to a small but significant amount of itme.

Also, I see that these files get requested all over again if you change the page URL with the History API. Maybe that should be filed as a separate issue?
Labels: -Hotlist-Recharge-Cold
Let's use talo's feedback for prioritization.

Comment 12 Deleted

Comment 13 by tkent@chromium.org, Apr 21 2017

Status: Available (was: Untriaged)
I can confirm that the History API causes favicons to be loaded again. Does it need a separate issue?
Status: Assigned (was: Available)

Sign in to add a comment