Support "sizes" attribute of <link rel="icon"...>
Project Member Reported by firstname.lastname@example.org, Feb 7 2012
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.
Feb 7 2012,
Mar 10 2013,
Apr 6 2013,
Dec 2 2013,
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.
Aug 18 2015,
Aug 18 2015,
Feb 15 2016,
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
Feb 14 2017,
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
Feb 15 2017,
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:  2. Data: depends on how popular the different extra sizes are on the web.  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. : https://bugs.chromium.org/p/chromium/issues/detail?id=324820#c7
Feb 21 2017,
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?
Feb 22 2017,
Let's use talo's feedback for prioritization.
Apr 21 2017,
Jan 9 2018,
I can confirm that the History API causes favicons to be loaded again. Does it need a separate issue?
Sign in to add a comment