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
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

issue 324820

Sign in to add a comment

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

Project Member Reported by, Feb 7 2012

Issue description

For now the "sizes" attribute of <link 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, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 3 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
The absence of support of the "sizes" attribute has a side effect: . Whenever the present issue is fixed, bug 324820 can probably be closed, too.

Comment 5 by, Aug 18 2015

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

Comment 6 by, Aug 18 2015

Blocking: chromium:324820

Comment 7 by, Feb 15 2016

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, by not supporting sizes we end up loading all favicons listed. Our best-practices documentation ( 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:
Project Member

Comment 8 by, 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 - Your friendly Sheriffbot
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:


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.

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