Have a look at this slideshow:
http://www.jungledragon.com/all/slideshow/promoted
It loads one big image, and in the bottom there are 9 thumbnail images, which you can see when you toggle the thumbs icon button.
As a test in speeding up this slideshow, I'm including link prefetch statements for the large version of each thumb:
<link rel="prefetch" [large image url 1 here]" />
<link rel="prefetch" [large image url 2 here]" />
<link rel="prefetch" [large image url 3 here]" />
<link rel="prefetch" [large image url 4 here]" />
<link rel="prefetch" [large image url 5 here]" />
<link rel="prefetch" [large image url 6 here]" />
<link rel="prefetch" [large image url 7 here]" />
<link rel="prefetch" [large image url 8 here]" />
<link rel="prefetch" [large image url 9 here]" />
You'll find the above in the source of the page. The idea is that all large versions of the current batch (9 images) are preloaded so that when users navigate the slideshow, the large images often appear instantly.
Having implemented this, I've been testing the effects. The test instruction is simple:
Visit the slide show link
Wait for a few seconds (to allow the preloading)
Move to the next image a few times. If this works nearly instantly, prefetching was succesful. If an image load takes 2-3 seconds, it means it failed.
Alternatively, you can also open your browser's inspector window, network tab, and see both the preloading the the retrieval from cache. Note that if you do this test multiple times, you need to clear the cache each time.
Chrome results
The results in Chrome are spectacular. The prefetch hints are picked up aggressively. It's as good as it gets.
Firefox results
Firefox prefetches less aggressively and more slowly. Still, at least it does prefetch, and it works.
IE11 results
IE11 claims to support resource prefetching but it has zero effect. In Windows 8.1/IE11, none of the images are loaded instantly, it seems to prefecth nothing, also not by waiting a long time before navigating the slideshow. In IE's dev tools, I can confirm that the network tab shows no prefetch activity.
I learned later on that prefetching does not work with the dev tools open, but even when closed there is no prefetching going on, I can see that from the response times.
Any idea on why this works for Chrome and Firefox, yet not for IE11? It should be well supported but I cannot get it to work. This is a cross-domain fetch, both HTTP, not HTTPs, yet cross-domain prefetching should work according to the spec.
I have looked at the link you have provided and I believe the issue is the unusual and (probably) invalid placement of the link elements.
Microsoft state-
The link element can be used only within the head tag.
Within their MSDN documentation.
Mozilla Developer Network state-
Permitted parent elements Any element that accept metadata elements
This tallies with the official specification which further defines Metadata content-
Metadata content is content that sets up the presentation or behavior of the rest of the content, or that sets up the relationship of the document with other documents, or that conveys other "out of band" information.
base link meta noscript script style template title
The page head is able to contain metadata content whereas the body is only able to accept sectioning and flow content.
Just want to add that i just found out that prerender will not work if running your site through visual studio (using any other port than 443 or 80) with IE11/Edge. Chrome was working fine and i was trying to determine why ie/edge wasn't working. The only thing i could think of is the port. So i published to our web server and ie/edge started working. I would assume the same thing would hold true for prefetch but i haven't tried it.
Related
Everybody knows how to set up a favicon.ico link in their HTML:
<link rel="shortcut icon" href="http://hi.org/icon.ico" type="image/x-icon">
But it's silly that for only a several-byte-tiny icon we need yet yet another potentially speed-penalizing HTTP request.
So I wondered, how could I make that favicon part of a usable sprite (e.g., background-position=0px -200px;) that doubles as, say, a logo on the rest of the website, in order to speed up the site and save that precious and valuable HTTP request. How can we get this to go into an existing sprite image along with our logo and other artworks?
I think for the most part it does not result in another HTTP request as these are usually dumped in the browser's cache after the first access.
This is actually more efficient than any of the proposed "solutions".
A minor improvement to #yc's answer is injecting the Base64-encoded favicon from a JavaScript file that would normally be used and cached anyway, and also suppressing the standard browser behavior of requesting favicon.ico by feeding it a data URI in the relevant meta tag.
This technique avoids the extra http request and is confirmed to work in recent versions of Chrome, Firefox and Opera on Windows 7. However it doesn't appear to work in Internet Explorer 9 at least.
File index.html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<!-- Suppress browser request for favicon.ico -->
<link rel="shortcut icon"type="image/x-icon" href="data:image/x-icon;,">
<script src="script.js"></script>
...
File script.js
var favIcon = "\
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAABrUlEQVR42mNkwAOepOgxMTD9mwhk\
[...truncated for brevity...]
IALgNIBUQBUDAFi2whGNUZ3eAAAAAElFTkSuQmCC";
var docHead = document.getElementsByTagName('head')[0];
var newLink = document.createElement('link');
newLink.rel = 'shortcut icon';
newLink.href = 'data:image/png;base64,'+favIcon;
docHead.appendChild(newLink);
/* Other JavaScript code would normally be in here too. */
Demo: turi.co/up/favicon.html
You could try a data URI. No HTTP request!
<link id="favicon" rel="shortcut icon" type="image/png" href="data:image/png;base64,....==">
Unless your pages have static caching, your favicon wouldn't be able to be cached, and depending on the size of your favicon image, your source code could get kind of bloated as a result.
Data URI favicons seems to work in most modern browsers; I have it working in recent versions of Chrome, Firefox and Safari on a Mac. Doesn't seem to work in Internet Explorer, and possibly some versions of Opera.
If you're worried about old Internet Explorer versions (and you probably shouldn't be these days), you could include an Internet Explorer conditional comment that would load the actual favicon.ico in the traditional way, since it seems that older Internet Explorer doesn't support data URI favicons.
`<!--[if IE ]><link rel="shortcut icon" href="http://example.com/favicon.ico" type="image/x-icon" /><![endif]--> `
Include the favicon.ico file in your root directory to cover browsers that will request it either way, since for those browsers, if they're already checking no matter what you do, you might as well not waste the HTTP request with a 404 response.
You could also just use the favicon of another popular site which is likely to have their favicon cached, like http://google.com/favicon.ico, so that it is served from cache.
As commenters have pointed out, just because you can do this doesn't mean you should, since some browsers will request favicon.ico regardless of the tricks we devise. The amount of overhead you'd save by doing this would be minuscule compared to the savings you'd get from doing things like gzipping, using far-future expires headers for static content, minifying JavaScript files, putting background images into sprites or data URIs, serving static files off of a CDN, etc.
Killer Solution in 2020
This solution necessarily comes nine years after the question was originally asked, because, until fairly recently, most browsers have not been able to handle favicons in .svg format.
That's not the case anymore.
See: https://caniuse.com/#feat=link-icon-svg
1) Choose SVG as the Favicon format
Right now, in June 2020, these browsers can handle SVG Favicons:
Chrome
Firefox
Edge
Opera
Chrome for Android
KaiOS Browser
Note that these browsers still can't:
Safari
iOS Safari
Firefox for Android
Nevertheless, with the above in mind, we can now use SVG Favicons with a reasonable degree of confidence.
2) Present the SVG as a Data URL
The main objective here is to avoid HTTP Requests.
As other solutions on this page have mentioned, a pretty smart way to do this is to use a Data URL rather than an HTTP URL.
SVGs (especially small SVGs) lend themselves perfectly to Data URLs, because the latter is simply plaintext (with any potentially ambiguous characters percentage-encoded) and the former, being XML, can be written out as a long line of plaintext (with a smattering of percentage codes) incredibly straightforwardly.
3) The entire SVG is a single Emoji
N.B. This step is optional. Your SVG can be a single emoji, but it can just as easily be a more complex SVG.
In December 2019, Leandro Linares was one of the first to realise that since Chrome had joined Firefox in supporting SVG Favicons, it was worth experimenting to see if a favicon could be created out of an emoji:
https://lean8086.com/articles/using-an-emoji-as-favicon-with-svg/
Linares' hunch was right.
Several months later (March 2020), Code Pirate Lea Verou realised the same thing:
https://twitter.com/leaverou/status/1241619866475474946
And favicons were never the same again.
4) Implementing the solution yourself:
Here's a simple SVG:
<svg
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 16 16">
<text x="0" y="14">🦄</text>
</svg>
And here's the same SVG as a Data URL:
data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%3E🦄%3C/text%3E%3C/svg%3E
And, finally, here's that Data URL as a Favicon:
<link rel="icon" href="data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%3E🦄%3C/text%3E%3C/svg%3E" type="image/svg+xml" />
5) More tricks (...these are not your parents' favicons!)
Since the Favicon is an SVG, any number of filter effects (both SVG and CSS) can be applied to it.
For instance, alongside the White Unicorn Favicon above, we can easily make a Black Unicorn Favicon by applying the filter:
style="filter: invert(100%);"
Black Unicorn Favicon:
<link rel="icon" href="data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%20style='filter:%20invert(100%);'%3E🦄%3C/text%3E%3C/svg%3E" type="image/svg+xml" />
You could use a Base64-encoded favicon, like:
<link href="data:image/x-icon;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQEAYAAABPYyMiAAAABmJLR0T///////8JWPfcAAAACXBIWXMAAABIAAAASABGyWs+AAACbUlEQVRIx7WUsU/qUBTGv96WSlWeEBZijJggxrREdwYixMnByYEyOvgfsBAMG0xuDsZ/QGc3NDFhgTioiYsmkhBYGLSBkLYR0va8gSjvQXiIT7/l5ibfOd/v3pN7gSmVSMTj8ThRfzdYk8lkMpl83/+AVFVVVXU0eHiVJEmSpB8DIcpkMplsdhCYz+fzhQJROBwOh8PDQN+oQCAQCASIRFEURZHI45GkP0/e7Xa73e70AMJnjel0Op1OA6oaDB4eAkAw6PcDvZ5t6zrw/Hx2trAw/cHYZ426ruu6DtzcGEYuBzQa19etFvD4WKtls4AoRqMPDwBjjLGPrt84ilgsFovF6EOapmmaRiP6O/jbAIguL4vFYpHGqlKpVCoVomq1Wq1Wibxer9fn+w+Q9+cUiUQikQhNrfdgWZZlWf4yyGhj27Zt254MUK/X6/X6F0aiKIqiKIOCYRmGYRjGZADLsizLIgqFQqHV1SkAnp5OTn79ItK0qyuPZ7SxaZqmaU4GKJfPzxmbfAPc/f3pqaIQLS8vLtZqgOP0bYyJoiAARC5Xrwf4/Vtbb2+Th1YqlUqlErC01GgkEkCz2WxyHLC+LsuiCAiCJLlcgM+3vd3pcBzXaJTLR0dEs7Ptdv+D4TiOG/A6DsBxQKvV621sAGtru7vl8ngAjuvXv7xcXIgiwNjMjCj2h+k4fQfPA4LA8xwHCO323V2hABiG223bwPy8xwMAbvfcHGMAY32j47y+3t4OAsZpZ2dzEwAsy7IcBxAExhwHMIxOx3GAlZVUyjT/1WFIudzenstFlEpFo9M8o+Pj/X2eJzo4SCR4fnzdb2N4Pyv9cduVAAAAAElFTkSuQmCC" rel="icon" type="image/x-icon" />
I found an interesting solution on this page. It is in German, but you will be able to understand the code.
You put the base64 data of the icon into an external style sheet, so it will be cached. In the head of your website you have to define the favicon with an id and the favicon is set as a background-image in the style sheet for that id.
link#icon {
background-image:url("data:image/x-icon;base64,<base64_image_data>");
}
and the html
<html>
<head>
<link id="icon" rel="shortcut icon" type="image/x-icon" />
<link rel="stylesheet" type="text/css" href="/styles.css" />
...
</head>
<body>
...
</body>
</html>
Good point and nice idea, but impossible. A favicon needs to be a single, separate resource. There is no way to combine it with another image file.
Does it really matter?
Many browsers load the favicon as a low priority so that it doesn't block the page load in anyway, so yes it's an extra request, but it's not on any critical path.
A JavaScript solution is horrible because JavaScript code has been retrieved and executed, all the DOM elements below will be blocked from rendering and it doesn't reduce the number of requests!
The proper solution is to use HTTP pipelining.
HTTP pipelining is a technique in which multiple HTTP requests are written out to a single socket without waiting for the corresponding responses. Pipelining is only supported in HTTP/1.1, not in 1.0.
It's required that servers support it, but not necessarily participate.
HTTP pipelining requires both the client and the server to support it. HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required not to fail if a client chooses to pipeline requests.
Many browser clients don't do it, when they should.
HTTP pipelining is disabled in most browsers.
Opera has pipelining enabled by default. It uses heuristics to control the level of pipelining employed depending on the connected server.
Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.
Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino), support pipelining however it is disabled by default. It uses some heuristics, especially to turn pipelining off for IIS servers.
Konqueror 2.0 supports pipelining, but it's disabled by default.[citation needed]
Google Chrome does not support pipelining.
I would recommend you try enabling pipelining in Firefox and try it there, or just use Opera (shudder).
This is not really an answer to the question, but simply to compliment the answers given by Marcel and yahelc. I offer an elegant solution to the 404 favicon issue.
Some applications and browsers check for a favicon.ico file and if the icon is not found in the site root, you can simply respond to the request with the 204 response header.
Apache Examples:
Apache option one (and my favorite), a simple one-liner in your .htacces or .conf:
Redirect 204 /favicon.ico
Apache option two:
<Files "favicon.ico">
ErrorDocument 204 ""
</Files>
For further reading there is a nice blog post by Stoyan Stefanov.
It's a great idea, but if Google hasn't done it on their homepage, I'm betting it can't (currently) be done.
I'm sorry, but you can't combine the favicon with another resource.
This means you have basically two options:
If you're comfortable with your site not having a favicon - you can just have the href point to a non-icon resource that is already being loaded (e.g., a style sheet, script file, or even some resource that benefits from being pre-fetched).
(My brief testing indicates that this works across most, if not all, major browsers.)
Accept the extra HTTP request and just make sure your favicon file has aggressive HTTP cache-control headers set.
(If you have other websites under your control, you might even have them sneakily preload the favicon for this website - along with other static resources.)
P.S. Creative solutions that will not work:
The weird CSS data URI trick (linked to by commenter Felix Geenen) does not work.
Using JavaScript to perform a delayed injection of the favicon <link> element (as suggested by user yc) will likely just make things worse - by resulting in two HTTP requests.
You can use an 8-bit PNG image instead of the ICO format for an even smaller data footprint. The only thing you have to change is using "data:image/png" instead of "data:image/x-icon" MIME type header:
<link
href="data:image/png;base64,your-base64-encoded-string-goes-here"
rel="icon" type="image/png"
/>
"type" attribute can be "image/png" or "image/x-icon". Both work for me.
You can convert ICO to 8-bit PNG using GIMP or convert:
convert favicon.ico -depth 8 -strip favicon.png
And encode the PNG binary to a Base64-string using the base64 command:
base64 favicon.png
Here's the easiest way:
<!DOCTYPE html><html><head>
<link rel="shortcut icon" href="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAA
lwSFlzAAALEwAACxMBAJqcGAAAAVlpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4
OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3
JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9y
Zy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdG
lvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6dGlmZj0iaHR0cDovL25z
LmFkb2JlLmNvbS90aWZmLzEuMC8iPgogICAgICAgICA8dGlmZjpPcmllbnRhdGlvbj
4xPC90aWZmOk9yaWVudGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg
PC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KTMInWQAABLJJREFUWAnFV+trW2UY/yVN0j
S32q6bnWunQ1e11k3YXMUy8AbDoSBDv4mfFPTj/gD9ug/7B/woqCCISnGItcyppbgN
Rhn2st5G2yxt1svSJe1yPYnP703fcs7JSZo4YS9Ncs57eX6/5/Y+T12fX7hYdAHy92
iG+1GCU2X3/6V3k9sNl8uFUqnUkMiHJkDfuQV4M7WFbC4Hr8fTEAlPQ3RtmwleFI0z
mQxO95/EQP8pLEaj+PaHQbS3RmAUi7YTla8PRYDGLhgGPnz/HI719Srp0VgMhszRHf
WM/+wC+jy1tY2zb72uwOl7WmPi1gwCfr887609CdZtAfpZa0XNc/k8nug8gBPHjylF
uTY7N4/JmVmEQkFlBbWwx9eeBNyiKbVLZ7IKlEAtomEmm0Vvz1G0tLQoiKXoHXzz/Y
9qX75QgM/jhb/ZB5KtlRk1CdDM2+k0SKLn6SM4KBoXRHhsOY6J2XmsbWxgdv42Jqdn
cH3sJo4c7sKhg50oFku4s7yMuYUleJqahEizzDm7pCoBgt8XH7/Q8wzOvPmamLtz1w
UMvPjdu1hYjIrPp9He9hjOf/oJ9rW37e5hBiwuRXFpaBjR5RWEgkFHEq4vLlysuDkI
nhTwV068hPfeOau0oJ21KXUsKNvbvux7suKq734axNT0nLhOLCHuNI8KC1B4Wg7RnO
++fUaB03x0gxlYA1EYZcoxta73cJ3PD8SFuWxOnbdCl2k4EuCN9sbpATT7fMpsBLcP
DcR5gpuHBk8mU/jyq6+xcW8TYckMpziwSKagvKTX4x0deOpwt5JpBjKD1PM8eu064q
vraI2EHcEpw0pAqnK+YODA/n3wS6pxNEpAa58TK05IdoQl+AyjoGQ5fVkI0JbFoqEi
tlFgu/C01IeM3B2UY4s7y1YrAbXUeEm1SNx58Un8sDJKiNbsdiwEaD6m4JakoFPAOA
HZ57TleFs+2d2lMsotl1G1YSHATR5PEzYSCXXt8p2kGh36zED/y+o8qyNridOwEOBB
j5htI7GJ1bU1p/11zZX9XkJ31yF89MG5nTpScAxoCwFKZ86z8NxeWKwLrNom7YrjL/
bh/GcfY39Hu2RYJYkKAvR9KBjAjZv/CJHMThQ37gYS066IhMNgWmpSZtIVBHio2euV
AhLH+OSU2qsFmQ828jx69Rpi8VX4vJX9YgUBCmbBCIsVhv8cQTKVKt/jDsFIYvpjJ0
RLUuPYygqujF5FG3tEo7IkOxKgUObwvcR9DF2+omRTmE5NDco5/dFzSoGd4sWaMvjL
kCJZJQmsV7FZC9bziBSQv2+M4Y+RUbWki5IGZXPC1oy/eo4buY9W/PnX3zC/uFTuEa
VJcRoV1dC8iSRawyFcGv4dqe1tvHrqpFS1EFbX1zE+dQvT0hVlpNSyzvc+exR9zz8n
zUmbVL8ELv81grHxSbTK/lrtuWNDYibBZ14iSSEQlP6PGbIpZTadzkg/6Fdr1PaBvI
cCLYgIYa7TKsFAYNdtdpn6vaYF9CYCREQTxkBS/gPySZb42SvIvDhYNQRsQBlkal3i
R/cSWka137oI8LAOQF7VDDiDwHrw3Si/l9eFl5CtZzhmQa2DZlynfXut28/8C/JOMz
7+5SRKAAAAAElFTkSuQmCC">
</head></html>
What icon does it represent? Answer below!
As I have enabled the HTTP2 protocol of IIS, but the requests of the main javascript files were still queueing. According to the explanation of queueing by Chrome, I really don't know what cause this.
You can check at here: https://app.youjustgo.com/zh/
Queueing:
HTTP/2 means that more assets can be downloaded at once - not that they will be.
Browsers have various heuristics as to what to download and when.
For example, if an image is needed by a CSS file, then that image cannot be requested until the CSS file is downloaded and processed for example (ignoring preload). So in this case the CSS and the image will not download in parallel despite HTTP/2 allowing this.
Another issues is that <script> tags can change the content of the page, so unless it is explicitly marked as async (or defer) it is "render blocking". This means any JavaScript further down the page will not be run until the <script> tag is run. Now a browser could scan ahead and download the future scripts and just not run them until it needs to, if it wants, with the slight risk that it's a wasted download if the scripts subsequently are not actually needed. That's up to the browser and maybe Chrome decides it's not worth while to do this.
Looking at your specific site, your home page looks to be made up of basically only script tags. You could investigate the use of async or defer to allow more downloads to happen in parallel, but if you want the real performance improvement, you probably should go back to the basics of coding HTML, with CSS, and then enhancing it with JavaScript, rather than coding it all with JavaScript.
I'm also not sure of what the point of your preloading of your CSS is?
<link rel='preload' href='https://api.tiles.mapbox.com/mapbox-gl-js/v0.37.0/mapbox-gl.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel='preload' href='https://api.mapbox.com/mapbox-gl-js/plugins/mapbox-gl-directions/v3.0.2/mapbox-gl-directions.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="https://npmcdn.com/angular2-toaster#2.0.0/toaster.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick-theme.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
Preload is intended for assets that are not immediately apparent to the browser (like the image example above) to allow it to start downloading earlier. Here you are using it to preload CSS. The only advantage is it will not be render blocking and then you use the onload function to display it. However CSS normally is render blocking for a reason - otherwise your content looks unstyled. And because it is preloaded it's requested as high priority (which the CSS would have been requested as anyway), so not sure what advantage this is giving you to be honest. Very confused...
I am trying to put a favicon on my Flask page. When I try it on IE, it works, but when I try it on Chrome (which is my usual browser), it does not load.
Yet if I go to static/favicon.ico, the image loads. Here is my HTML code:
<link rel="shortcut icon" href="{{ url_for('static', filename='favicon.ico') }}">
I have tried clearing the cache but it didn't make a difference. What is the problem?
To explore:
Cache issue. Clearing the cache is sometimes not enough to get rid of the old favicon status. In other words, Chrome might remember that your icon was not working 5 minutes ago so it won't retry to load it, even while you fixed the icon a minute ago. Use the DevTools, Network tab, to make sure Chrome is loading your icon.
Errors in the console. Although unlikely since it works with other browsers, there might be a problem with the image URL or something. It's a good practice to check the console.
Link in body. WebKit is known to consider the head closed as soon as it encounters a body-only markup (eg. a div). And if the faulty markup is followed by head-only markups (eg. a link), these are ignored. To check this, use the DevTools to inspect elements and make sure you can find your favicon link markup. If it is not present whereas it is obviously in the HTML, you probably found the problem.
I had the same issue. But if you go through the documentation, it clearly says to add this line to the head:
<link rel="shortcut icon" href="{{ url_for('static', filename='favicon.ico') }}">
And then place the favicon.ico file in the static directory. Worked fine for me right away.
I have seen sites using tag to load images eg;
<link href='images.jpg' rel='somthing' type='something'>
what relevance does this have while designing a website?
What aspect of website does it help optimize( i am thinking it's used for optimization. Right me if i am wrong). Can someone explain this to me?
Some people use this for image/css/page prefetching. You can read about it here.
Basically, once a page is finished loading the browser will see these link tags and if the rel attribute is "next" or "prefetch" then the browser will start downloading whatever the href attribute points to and store it in the cache so that it will load very fast if the user clicks on it.
This method can be used to prefetch anything including images, style sheets, different web pages, etc. As long as the url used in the <link> matches the url used to normally load the resource, it will load that resource from the cache.
For example, if your page had this link Page 2 and you wanted to prefetch it, you would add this to your page <link rel="next" href="page2.html">.
Finally, this method of prefetching is preferred over the javascript methods because this type of prefetching is standards compliant, is handled by the browser, and can be disabled by the user if they have metered bandwidth or other connection limitations.
While a page loads, blocking scripts can interrupt, forcing other scripts to wait. rel=preload in a link element becomes a declarative fetch primitive that initiates an early fetch and separates fetching from resource execution.
<link rel="preload" href="/style/other.css" as="style">
<link rel="preload" href="/assets/font.woff2" as="font">
<link rel="preload" href="/img/header.png" as="image">
ref. https://w3c.github.io/preload/
take note that preload is PREliminary
Everybody knows how to set up a favicon.ico link in their HTML:
<link rel="shortcut icon" href="http://hi.org/icon.ico" type="image/x-icon">
But it's silly that for only a several-byte-tiny icon we need yet yet another potentially speed-penalizing HTTP request.
So I wondered, how could I make that favicon part of a usable sprite (e.g., background-position=0px -200px;) that doubles as, say, a logo on the rest of the website, in order to speed up the site and save that precious and valuable HTTP request. How can we get this to go into an existing sprite image along with our logo and other artworks?
I think for the most part it does not result in another HTTP request as these are usually dumped in the browser's cache after the first access.
This is actually more efficient than any of the proposed "solutions".
A minor improvement to #yc's answer is injecting the Base64-encoded favicon from a JavaScript file that would normally be used and cached anyway, and also suppressing the standard browser behavior of requesting favicon.ico by feeding it a data URI in the relevant meta tag.
This technique avoids the extra http request and is confirmed to work in recent versions of Chrome, Firefox and Opera on Windows 7. However it doesn't appear to work in Internet Explorer 9 at least.
File index.html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<!-- Suppress browser request for favicon.ico -->
<link rel="shortcut icon"type="image/x-icon" href="data:image/x-icon;,">
<script src="script.js"></script>
...
File script.js
var favIcon = "\
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAABrUlEQVR42mNkwAOepOgxMTD9mwhk\
[...truncated for brevity...]
IALgNIBUQBUDAFi2whGNUZ3eAAAAAElFTkSuQmCC";
var docHead = document.getElementsByTagName('head')[0];
var newLink = document.createElement('link');
newLink.rel = 'shortcut icon';
newLink.href = 'data:image/png;base64,'+favIcon;
docHead.appendChild(newLink);
/* Other JavaScript code would normally be in here too. */
Demo: turi.co/up/favicon.html
You could try a data URI. No HTTP request!
<link id="favicon" rel="shortcut icon" type="image/png" href="data:image/png;base64,....==">
Unless your pages have static caching, your favicon wouldn't be able to be cached, and depending on the size of your favicon image, your source code could get kind of bloated as a result.
Data URI favicons seems to work in most modern browsers; I have it working in recent versions of Chrome, Firefox and Safari on a Mac. Doesn't seem to work in Internet Explorer, and possibly some versions of Opera.
If you're worried about old Internet Explorer versions (and you probably shouldn't be these days), you could include an Internet Explorer conditional comment that would load the actual favicon.ico in the traditional way, since it seems that older Internet Explorer doesn't support data URI favicons.
`<!--[if IE ]><link rel="shortcut icon" href="http://example.com/favicon.ico" type="image/x-icon" /><![endif]--> `
Include the favicon.ico file in your root directory to cover browsers that will request it either way, since for those browsers, if they're already checking no matter what you do, you might as well not waste the HTTP request with a 404 response.
You could also just use the favicon of another popular site which is likely to have their favicon cached, like http://google.com/favicon.ico, so that it is served from cache.
As commenters have pointed out, just because you can do this doesn't mean you should, since some browsers will request favicon.ico regardless of the tricks we devise. The amount of overhead you'd save by doing this would be minuscule compared to the savings you'd get from doing things like gzipping, using far-future expires headers for static content, minifying JavaScript files, putting background images into sprites or data URIs, serving static files off of a CDN, etc.
Killer Solution in 2020
This solution necessarily comes nine years after the question was originally asked, because, until fairly recently, most browsers have not been able to handle favicons in .svg format.
That's not the case anymore.
See: https://caniuse.com/#feat=link-icon-svg
1) Choose SVG as the Favicon format
Right now, in June 2020, these browsers can handle SVG Favicons:
Chrome
Firefox
Edge
Opera
Chrome for Android
KaiOS Browser
Note that these browsers still can't:
Safari
iOS Safari
Firefox for Android
Nevertheless, with the above in mind, we can now use SVG Favicons with a reasonable degree of confidence.
2) Present the SVG as a Data URL
The main objective here is to avoid HTTP Requests.
As other solutions on this page have mentioned, a pretty smart way to do this is to use a Data URL rather than an HTTP URL.
SVGs (especially small SVGs) lend themselves perfectly to Data URLs, because the latter is simply plaintext (with any potentially ambiguous characters percentage-encoded) and the former, being XML, can be written out as a long line of plaintext (with a smattering of percentage codes) incredibly straightforwardly.
3) The entire SVG is a single Emoji
N.B. This step is optional. Your SVG can be a single emoji, but it can just as easily be a more complex SVG.
In December 2019, Leandro Linares was one of the first to realise that since Chrome had joined Firefox in supporting SVG Favicons, it was worth experimenting to see if a favicon could be created out of an emoji:
https://lean8086.com/articles/using-an-emoji-as-favicon-with-svg/
Linares' hunch was right.
Several months later (March 2020), Code Pirate Lea Verou realised the same thing:
https://twitter.com/leaverou/status/1241619866475474946
And favicons were never the same again.
4) Implementing the solution yourself:
Here's a simple SVG:
<svg
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 16 16">
<text x="0" y="14">🦄</text>
</svg>
And here's the same SVG as a Data URL:
data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%3E🦄%3C/text%3E%3C/svg%3E
And, finally, here's that Data URL as a Favicon:
<link rel="icon" href="data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%3E🦄%3C/text%3E%3C/svg%3E" type="image/svg+xml" />
5) More tricks (...these are not your parents' favicons!)
Since the Favicon is an SVG, any number of filter effects (both SVG and CSS) can be applied to it.
For instance, alongside the White Unicorn Favicon above, we can easily make a Black Unicorn Favicon by applying the filter:
style="filter: invert(100%);"
Black Unicorn Favicon:
<link rel="icon" href="data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2016%2016'%3E%3Ctext%20x='0'%20y='14'%20style='filter:%20invert(100%);'%3E🦄%3C/text%3E%3C/svg%3E" type="image/svg+xml" />
You could use a Base64-encoded favicon, like:
<link href="data:image/x-icon;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQEAYAAABPYyMiAAAABmJLR0T///////8JWPfcAAAACXBIWXMAAABIAAAASABGyWs+AAACbUlEQVRIx7WUsU/qUBTGv96WSlWeEBZijJggxrREdwYixMnByYEyOvgfsBAMG0xuDsZ/QGc3NDFhgTioiYsmkhBYGLSBkLYR0va8gSjvQXiIT7/l5ibfOd/v3pN7gSmVSMTj8ThRfzdYk8lkMpl83/+AVFVVVXU0eHiVJEmSpB8DIcpkMplsdhCYz+fzhQJROBwOh8PDQN+oQCAQCASIRFEURZHI45GkP0/e7Xa73e70AMJnjel0Op1OA6oaDB4eAkAw6PcDvZ5t6zrw/Hx2trAw/cHYZ426ruu6DtzcGEYuBzQa19etFvD4WKtls4AoRqMPDwBjjLGPrt84ilgsFovF6EOapmmaRiP6O/jbAIguL4vFYpHGqlKpVCoVomq1Wq1Wibxer9fn+w+Q9+cUiUQikQhNrfdgWZZlWf4yyGhj27Zt254MUK/X6/X6F0aiKIqiKIOCYRmGYRjGZADLsizLIgqFQqHV1SkAnp5OTn79ItK0qyuPZ7SxaZqmaU4GKJfPzxmbfAPc/f3pqaIQLS8vLtZqgOP0bYyJoiAARC5Xrwf4/Vtbb2+Th1YqlUqlErC01GgkEkCz2WxyHLC+LsuiCAiCJLlcgM+3vd3pcBzXaJTLR0dEs7Ptdv+D4TiOG/A6DsBxQKvV621sAGtru7vl8ngAjuvXv7xcXIgiwNjMjCj2h+k4fQfPA4LA8xwHCO323V2hABiG223bwPy8xwMAbvfcHGMAY32j47y+3t4OAsZpZ2dzEwAsy7IcBxAExhwHMIxOx3GAlZVUyjT/1WFIudzenstFlEpFo9M8o+Pj/X2eJzo4SCR4fnzdb2N4Pyv9cduVAAAAAElFTkSuQmCC" rel="icon" type="image/x-icon" />
I found an interesting solution on this page. It is in German, but you will be able to understand the code.
You put the base64 data of the icon into an external style sheet, so it will be cached. In the head of your website you have to define the favicon with an id and the favicon is set as a background-image in the style sheet for that id.
link#icon {
background-image:url("data:image/x-icon;base64,<base64_image_data>");
}
and the html
<html>
<head>
<link id="icon" rel="shortcut icon" type="image/x-icon" />
<link rel="stylesheet" type="text/css" href="/styles.css" />
...
</head>
<body>
...
</body>
</html>
Good point and nice idea, but impossible. A favicon needs to be a single, separate resource. There is no way to combine it with another image file.
Does it really matter?
Many browsers load the favicon as a low priority so that it doesn't block the page load in anyway, so yes it's an extra request, but it's not on any critical path.
A JavaScript solution is horrible because JavaScript code has been retrieved and executed, all the DOM elements below will be blocked from rendering and it doesn't reduce the number of requests!
The proper solution is to use HTTP pipelining.
HTTP pipelining is a technique in which multiple HTTP requests are written out to a single socket without waiting for the corresponding responses. Pipelining is only supported in HTTP/1.1, not in 1.0.
It's required that servers support it, but not necessarily participate.
HTTP pipelining requires both the client and the server to support it. HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required not to fail if a client chooses to pipeline requests.
Many browser clients don't do it, when they should.
HTTP pipelining is disabled in most browsers.
Opera has pipelining enabled by default. It uses heuristics to control the level of pipelining employed depending on the connected server.
Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.
Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino), support pipelining however it is disabled by default. It uses some heuristics, especially to turn pipelining off for IIS servers.
Konqueror 2.0 supports pipelining, but it's disabled by default.[citation needed]
Google Chrome does not support pipelining.
I would recommend you try enabling pipelining in Firefox and try it there, or just use Opera (shudder).
This is not really an answer to the question, but simply to compliment the answers given by Marcel and yahelc. I offer an elegant solution to the 404 favicon issue.
Some applications and browsers check for a favicon.ico file and if the icon is not found in the site root, you can simply respond to the request with the 204 response header.
Apache Examples:
Apache option one (and my favorite), a simple one-liner in your .htacces or .conf:
Redirect 204 /favicon.ico
Apache option two:
<Files "favicon.ico">
ErrorDocument 204 ""
</Files>
For further reading there is a nice blog post by Stoyan Stefanov.
It's a great idea, but if Google hasn't done it on their homepage, I'm betting it can't (currently) be done.
I'm sorry, but you can't combine the favicon with another resource.
This means you have basically two options:
If you're comfortable with your site not having a favicon - you can just have the href point to a non-icon resource that is already being loaded (e.g., a style sheet, script file, or even some resource that benefits from being pre-fetched).
(My brief testing indicates that this works across most, if not all, major browsers.)
Accept the extra HTTP request and just make sure your favicon file has aggressive HTTP cache-control headers set.
(If you have other websites under your control, you might even have them sneakily preload the favicon for this website - along with other static resources.)
P.S. Creative solutions that will not work:
The weird CSS data URI trick (linked to by commenter Felix Geenen) does not work.
Using JavaScript to perform a delayed injection of the favicon <link> element (as suggested by user yc) will likely just make things worse - by resulting in two HTTP requests.
You can use an 8-bit PNG image instead of the ICO format for an even smaller data footprint. The only thing you have to change is using "data:image/png" instead of "data:image/x-icon" MIME type header:
<link
href="data:image/png;base64,your-base64-encoded-string-goes-here"
rel="icon" type="image/png"
/>
"type" attribute can be "image/png" or "image/x-icon". Both work for me.
You can convert ICO to 8-bit PNG using GIMP or convert:
convert favicon.ico -depth 8 -strip favicon.png
And encode the PNG binary to a Base64-string using the base64 command:
base64 favicon.png
Here's the easiest way:
<!DOCTYPE html><html><head>
<link rel="shortcut icon" href="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAA
lwSFlzAAALEwAACxMBAJqcGAAAAVlpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4
OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3
JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9y
Zy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdG
lvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6dGlmZj0iaHR0cDovL25z
LmFkb2JlLmNvbS90aWZmLzEuMC8iPgogICAgICAgICA8dGlmZjpPcmllbnRhdGlvbj
4xPC90aWZmOk9yaWVudGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg
PC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KTMInWQAABLJJREFUWAnFV+trW2UY/yVN0j
S32q6bnWunQ1e11k3YXMUy8AbDoSBDv4mfFPTj/gD9ug/7B/woqCCISnGItcyppbgN
Rhn2st5G2yxt1svSJe1yPYnP703fcs7JSZo4YS9Ncs57eX6/5/Y+T12fX7hYdAHy92
iG+1GCU2X3/6V3k9sNl8uFUqnUkMiHJkDfuQV4M7WFbC4Hr8fTEAlPQ3RtmwleFI0z
mQxO95/EQP8pLEaj+PaHQbS3RmAUi7YTla8PRYDGLhgGPnz/HI719Srp0VgMhszRHf
WM/+wC+jy1tY2zb72uwOl7WmPi1gwCfr887609CdZtAfpZa0XNc/k8nug8gBPHjylF
uTY7N4/JmVmEQkFlBbWwx9eeBNyiKbVLZ7IKlEAtomEmm0Vvz1G0tLQoiKXoHXzz/Y
9qX75QgM/jhb/ZB5KtlRk1CdDM2+k0SKLn6SM4KBoXRHhsOY6J2XmsbWxgdv42Jqdn
cH3sJo4c7sKhg50oFku4s7yMuYUleJqahEizzDm7pCoBgt8XH7/Q8wzOvPmamLtz1w
UMvPjdu1hYjIrPp9He9hjOf/oJ9rW37e5hBiwuRXFpaBjR5RWEgkFHEq4vLlysuDkI
nhTwV068hPfeOau0oJ21KXUsKNvbvux7suKq734axNT0nLhOLCHuNI8KC1B4Wg7RnO
++fUaB03x0gxlYA1EYZcoxta73cJ3PD8SFuWxOnbdCl2k4EuCN9sbpATT7fMpsBLcP
DcR5gpuHBk8mU/jyq6+xcW8TYckMpziwSKagvKTX4x0deOpwt5JpBjKD1PM8eu064q
vraI2EHcEpw0pAqnK+YODA/n3wS6pxNEpAa58TK05IdoQl+AyjoGQ5fVkI0JbFoqEi
tlFgu/C01IeM3B2UY4s7y1YrAbXUeEm1SNx58Un8sDJKiNbsdiwEaD6m4JakoFPAOA
HZ57TleFs+2d2lMsotl1G1YSHATR5PEzYSCXXt8p2kGh36zED/y+o8qyNridOwEOBB
j5htI7GJ1bU1p/11zZX9XkJ31yF89MG5nTpScAxoCwFKZ86z8NxeWKwLrNom7YrjL/
bh/GcfY39Hu2RYJYkKAvR9KBjAjZv/CJHMThQ37gYS066IhMNgWmpSZtIVBHio2euV
AhLH+OSU2qsFmQ828jx69Rpi8VX4vJX9YgUBCmbBCIsVhv8cQTKVKt/jDsFIYvpjJ0
RLUuPYygqujF5FG3tEo7IkOxKgUObwvcR9DF2+omRTmE5NDco5/dFzSoGd4sWaMvjL
kCJZJQmsV7FZC9bziBSQv2+M4Y+RUbWki5IGZXPC1oy/eo4buY9W/PnX3zC/uFTuEa
VJcRoV1dC8iSRawyFcGv4dqe1tvHrqpFS1EFbX1zE+dQvT0hVlpNSyzvc+exR9zz8n
zUmbVL8ELv81grHxSbTK/lrtuWNDYibBZ14iSSEQlP6PGbIpZTadzkg/6Fdr1PaBvI
cCLYgIYa7TKsFAYNdtdpn6vaYF9CYCREQTxkBS/gPySZb42SvIvDhYNQRsQBlkal3i
R/cSWka137oI8LAOQF7VDDiDwHrw3Si/l9eFl5CtZzhmQa2DZlynfXut28/8C/JOMz
7+5SRKAAAAAElFTkSuQmCC">
</head></html>
What icon does it represent? Answer below!