Is it good practice to have all sizes of favicons, and include all rel links in HTML?

Asked

Viewed 1,586 times

15

I’ve always used only the favicon.ico on the pages HTML, with it at the root and with its link rel in the HEAD:

<link rel='shortcut icon' href='https://site/favicon.ico'>

But recently, observing the server log, I saw that errors due to lack of other versions of favicons are a constant, mainly those of apple, generating logs as the below:

... [core:info] ... File does not exist: /home/meusite/www/apple-touch-icon.png

I was in doubt if these requests that do not complete can affect the server performance, and today I found a favicons generator which in addition to generating for various versions and sizes (apple, android etc), also generates various paths with <link rel> for each version, and some attributes meta, and even a json, as in the example below:

<link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
<link rel="icon" type="image/png" sizes="192x192"  href="/android-icon-192x192.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="96x96" href="/favicon-96x96.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="/ms-icon-144x144.png">
<meta name="theme-color" content="#ffffff">

However it seemed a lot to include in all HTML pages, and looking at the sources of some reference sites, I saw that none uses all these link rels and meta names suggested by the generator.

So the question is whether it’s really good practice to include all these images in /, and all these links rels and meta names in the HTML code of all pages of the site, both for usability and performance?

html favicon
  • 4

    I think in such cases the developer should ask "Which browsers do I need to support?" , "If in 1 of my 1000 users the icon appears with a bad resolution, is it a problem?". You have to balance the benefit cost into the balance

  • @Costamilam The idea is to support all browsers, and if for 1 of my 1000 users the icon does not appear to me is death! : ) But seriously, I hate the idea of the icon not showing up, I think it totally breaks the design, it gets kind of dirty haha thing. The point is, if I have, say, 200 pages on the site, it will be worth it (because a little should affect the overall performance of the site right) include this lot of HTML in the pages.

  • 1

    It is more things to load, but I consider little thing, it is not only not appearing, as you can see, in HTML you add of several sizes (16x16, 32x32, etc), Tavez one or two of each rel different solve your problem, may not look perfect in all Vices, but need?

  • 1

    Boy if it were me in charge of the project and it was really necessary I would do a javascript programming to catch the screen size of the user and based on the result obtained would create the tag at runtime and add it in DOM and good would always have 1 tag only

2 answers

18


I don’t think that answer will cover all the points, but I have a few tips for you...

The recommended is to use the Favicons in the root directory, pq is where the browser first searches for them. "Originally, the favicon was a file called favicon.ico placed in the root directory of a website." Source: https://en.wikipedia.org/wiki/Favicon#cite_note-10

But for example, if you have multiple sites within a host, each site with your favicon, their path is not in the parent root, and they can not fail to function. This is only an observation made in 2005 by the own W3C https://www.w3.org/2005/10/howto-favicon

So even if recommended, it’s not a rule to use favicon at the root.

See in this picture what happens when you put your pack favicon in a separate folder. On this site favicons are not at the root, they are at url/favicons and what happens is that when you directly access an image URL (url/imgs/image.png) for example the favicon does not appear in browser tab!

inserir a descrição da imagem aqui

If you put the favicon at the root of the site this will not happen! Tip from @costamilam

About the amount of variations I think this table helps clarify.

inserir a descrição da imagem aqui

Source: https://realfavicongenerator.net/favicon_compatibility#. Xpqmxihkjcs

Now as the Browser manages which of these versions it will use I can not say for sure, I believe that this is part of the site.webmanifest 

{
    "name": "",
    "short_name": "",
    "icons": [
        {
            "src": "/android-chrome-192x192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "/android-chrome-512x512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ],
    "theme_color": "#ffffff",
    "background_color": "#ffffff",
    "display": "standalone"
}

Or by browserconfig.xml

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
    <msapplication>
        <tile>
            <square150x150logo src="/mstile-150x150.png"/>
            <TileColor>#da532c</TileColor>
        </tile>
    </msapplication>
</browserconfig>

Another curious thing is that if there is a favicon with the extent .ico it seems to be the version preferred by the old browsers, the probably it will be chosen among the indexed versions to be displayed in the browser....

Another thing is that to keep the favicon cross-OS in addition to cross browser, you have to keep the pack of favicons available in the host, the indicated is that it is in the root as already mentioned. Keep in mind that when a user saves a "shortcut" to your site on the Android or iOS desktop, it is the favicon that will be used as icon on the desktop. So it’s good that you have versions for all resolutions.

inserir a descrição da imagem aqui

TIP: A way to control the cache is putting a versioning on href file, so you can easily control the caching of your favicon, and make sure which version you’re in favicon, for example doing so: href="favicon.ico?v=rv123"

<link rel="apple-touch-icon" sizes="144x144" href="apple-touch-icon.png?v=7koL0owN">
<link rel="icon" type="image/png" sizes="32x32" href="favicon-32x32.png?v=7koL0owN">
<link rel="icon" type="image/png" sizes="16x16" href="favicon-16x16.png?v=7koL0owN">
<link rel="manifest" href="site.webmanifest?v=7koL0owN">
<link rel="mask-icon" href="safari-pinned-tab.svg?v=7koL0owN" color="#5bbad5">
<link rel="shortcut icon" href="favicon.ico?v=7koL0owN">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="theme-color" content="#ffffff">

About the requisitions

I do not understand much of the subject, but a request that fails generates an error in the console, even being a favicon, but as a request that does not return anything affects the browser I can not say, but I believe that should "press" the site, because it keeps checking the connection and does not find anything...

inserir a descrição da imagem aqui

Here is a validator of favicons that you can test to see if your site is fully crossbrowser.

https://realfavicongenerator.net/favicon_checker

inserir a descrição da imagem aqui

  • But then it will be optional to use the rel link, since the browser searches first on /, will be all browser search even without referencing in html (if put in the /)?

  • 2

    @gustavox I think to be sure of this only going to search the documentation of each browser, because it is not a standard defined by W3C. What I can tell you is that in HTML4 it was already used to call favicon by the URL in absolute path http://example.com/myicon.png in the link quoted from W3C they have this example applied

  • 1

    About the requests, it is certain that they will use server resource, I think mainly for not finding the file right, but the doubt is whether this is insignificant or not... anyway thanks for the answer, helped a lot +1

  • 1

    Yeah, I’ll do some research and run some tests here, then I’ll return the results if I find anything relevant. Thanks!

  • 2

    @gustavox as I said is not a 100% full rss response, I lack knowledge to confirm some things..., but was worth the put force what find yes! It seems that there is even a technique to use favicon request to know how many people are logged in etc. rss

  • 1

    The browser does a GET, the server returns a 404 and ends there. It is an extra request, but I believe it to be insignificant, since, as said, it does not return anything, and the size of the answer ends up getting smaller (at least it should). Another detail, keeping the icon at the root (I don’t know if it looks for the nearest favicon or picks it directly from the root) causes when the user goes into some static file other than HTML (an image, for example), this icon will appear, even without having set anything up, if left in a separate folder, it may not appear

  • 1

    @Costamilam very interesting guy this image observation! Really if the guy gets into the urlDoSite/imagem.png if the favicon is not at the root it may not appear in the Browser Tab... I actually ran a test and confirmed your suspicion! I’ll even edit the answer, it was worth the call!

Show 2 more comments

5

it is even a good practice to include all these images in the / and all these Rels and meta links in the HTML code of all pages of the site

At the main favicon, it is better for compatibility between browsers not to use any HTML. A favicon.ico (16x16 and 32x32 sizes) at the root goes well -- a file . ico is a container for multiple icons . bmp or .png. This will work in any browser, since IE6, except Seamonkey.

Besides, it’s interesting you try to:

  • Touch icon for iOS 2.0+ and Android 2.1+ (size 152x152):
<link rel="apple-touch-icon-precomposed" href="path/to/favicon-152.png">
  • IE 10 Meter Tile icon (size 144x144):
<meta name="msapplication-TileColor" content="#FFFFFF">
<meta name="msapplication-TileImage" content="/path/to/favicon-144.png">
  • IE 11 Tile for Windows 8.1 Start Screen
<meta name="application-name" content="Name">
<meta name="msapplication-tooltip" content="Tooltip">
<meta name="msapplication-config" content="/path/to/ieconfig.xml">

In ieconfig.xml (sizes 128x128, 270x270, 558x270, 558x558, respectively):

<?xml version="1.0" encoding="utf-8"?>
    <browserconfig>
      <msapplication>
        <tile>
          <square70x70logo src="/path/to/smalltile.png"/>
          <square150x150logo src="/path/to/mediumtile.png"/>
          <wide310x150logo src="/path/to/widetile.png"/>
          <square310x310logo src="/path/to/largetile.png"/>
          <TileColor>#FFFFFF</TileColor>
        </tile>
      </msapplication>
    </browserconfig>

The paths don’t matter.

-

for both usability and performance?

In practice, it doesn’t make much difference in performance, but gains in "usability" or adaptability.

For example, if the apple touch icons not specified in HTML, iOS Safari will search the root directory for icons with the apple-touch-icon or apple-touch-icon-precomposed prefix. For example, if the device’s appropriate icon size is 57 57 pixels, iOS will search for the file names, in order:

  1. apple-touch-icon-57x57-precomposed.png
  2. apple-touch-icon-57x57.png
  3. apple-touch-icon-precomposed.png
  4. apple-touch-icon.png

Therefore, for iOS, it is not necessary to use HTML to touch icons -- and this is being your concern with the web server, but this type of request is beyond your control. Anyway, it’s a good idea to include both apple-touch-icon.png and apple-touch-icon-precomposed.png at the root for maximum compatibility.

To complete, since the HTML-free approach does not work in the Android browser (older versions), it is better to use apple-touch-icons in HTML (from major to minor, so older versions of iOS download the smaller icon instead of the larger one, as only the latter is used):

<!-- For Chrome for Android: -->
<link rel="icon" sizes="192x192" href="touch-icon-192x192.png">
<!-- For iPhone 6 Plus with @3× display: -->
<link rel="apple-touch-icon-precomposed" sizes="180x180" href="apple-touch-icon-180x180-precomposed.png">
<!-- For iPad with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="apple-touch-icon-152x152-precomposed.png">
<!-- For iPad with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-144x144-precomposed.png">
<!-- For iPhone with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="apple-touch-icon-120x120-precomposed.png">
<!-- For iPhone with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png">
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="apple-touch-icon-76x76-precomposed.png">
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png">
<!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png"><!-- 57×57px -->

I hope I helped. Please see this compilation and its references.

Browser other questions tagged html favicon

You are not signed in. Login or sign up in order to post.