Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SVG favicons have some cool benefits

austingil.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: SVG favicons have some cool benefits

#61

Post by allyourhorses »

toast0 wrote: post #44
allyourhorses wrote: post #34

re: cacheability of favicons, this is basically a non-issue as the bandwidth-delay product of even a 10mbit/50ms connection is already 62 kB. Anything below this size on such a connection is likely to render faster than a separate request round-trip. This raises to almost 1.2 MB with a 100mbit/100ms connection.

Early on in a connection, congestion window is much more limiting than bandwidth delay product. Do you really want to spend that limited bandwidth on your favicon that you might have already sent to the user before, maybe even in the same browsing session? It's way better to put it as a separate image, maybe their browser will delay loading it because they're mostly useless. But, you can actually make a favicon usefu…

> Do you really want to spend that limited bandwidth on your favicon that you might have already sent to the user before, maybe even in the same browsing session?

That's a really going point, but if the site's coming down over classic HTTP then still possibly yes, as separate requests are liable to require additional rounds of cold start. The other detail is that I don't think I've worked with a favicon much exceeding 1500 bytes before.

Another option would be pushing the into the footer, but HTML 5 seems to require only in the header. I wonder if browsers really enforce that.

Re: SVG favicons have some cool benefits

#62

Post by chrismorgan »

amelius wrote: post #59
chrismorgan wrote: post #46

Earlier quoted context omitted.

What you’re describing sounds like automated hinting. It’s a nice idea, but in practice it’s going to mess up too much stuff to be worth it, even if performance weren’t a problem.

I'm not so sure. Have you seen what the (loosely speaking) "inverse" operation (ML based superresolution) is capable of? E.g.: https://www.pixelmator.com/blog/2019/12/17/all-about-the-new...

Machine learning is singularly well-suited for superresolution, because you can trivially downsample and train it on that inverse operation, so training at scale is really easy.

But pleasing hinting—even operating on raster rather than vector sources—can’t be trained in the same way, because it’s inherently more subjective; it may be possible to come up with an alternative approach to training, but I suspect it’ll still be much more prone to inducing significant errors.

And of course, performance in all these things is such that they’re not going to be shipped in browsers; from your link, that model is thousands of times more expensive than the (admittedly-inferior) alternatives. (What’s their disk space like? I’m not familiar with how big such ML models end up.)

Re: SVG favicons have some cool benefits

#63

Post by account42 »

CharlesW wrote: post #42
matylla wrote: post #14

Complex SVG Favicons will usually be larger in term of bytes than highly compressed PNG icons. We did an extensive study of Favicons served on the top 500 websites [1]. If you want to stick with the old-school PNG icons, we open-sourced `icopack` - our internal tool for efficient packing of individual PNGs into a highly-optimised ICO files [2]. [1] https://optidash.ai/blog/optimizing-favicons-for-the-worlds-... [2] h…

> Complex SVG Favicons will usually be larger in term of bytes than highly compressed PNG icons. The post you linked to doesn't include the word "SVG". Is there a separate article that compares using one SVG file vs. using multiple images? It's hard to imagine that using a typical suite of PNG images at different sizes is going to be more efficient (and future-proof) than a single SVG file run through svgo.

> It's hard to imagine that using a typical suite of PNG images at different sizes is going to be more efficient (and future-proof) than a single SVG file run through svgo.

That's the wrong comparison though - each browser will typically only download one favicon size.

Re: SVG favicons have some cool benefits

#64

Post by account42 »

Cyykratahk wrote: post #49
matylla wrote: post #14

Complex SVG Favicons will usually be larger in term of bytes than highly compressed PNG icons. We did an extensive study of Favicons served on the top 500 websites [1]. If you want to stick with the old-school PNG icons, we open-sourced `icopack` - our internal tool for efficient packing of individual PNGs into a highly-optimised ICO files [2]. [1] https://optidash.ai/blog/optimizing-favicons-for-the-worlds-... [2] h…

Great article Earlier this year I created my own ICO editor for fun [1]. I learned a lot about reading and writing binary files, and decoding BMP data. While testing the editor on existing site favicons I kept finding that they were all uncompressed BMP data, and came to a similar conclusion to your article after checking the icons used on the Alexa top 100 sites. I guess this is a combination of the ICO format being…

PNG support in .ico files was introduced in Windows Vista and I expect Internet Explorer just supports whatever the OS does. There might still be holdovers (both sites and tools) from when people cared about XP support.

Re: SVG favicons have some cool benefits

#65

Post by account42 »

chrismorgan wrote: post #20

People keep on talking about (prefers-color-scheme: dark), but it isn’t what they want it to be—never has been, and probably never will be (though I will admit that prefers-color-scheme could theoretically be special-cased for favicon rendering). For example, in Firefox, I use the dark theme for the UI, but that’s completely unrelated to the content, and prefers-color-scheme matches the content, not the chrome. Conte…

That sounds like a browser bug - if its rendering the icon in the browser chrome it should also use the color scheme setting matching the chrome.

Re: SVG favicons have some cool benefits

#66

Post by account42 »

mjsir911 wrote: post #26
chrismorgan wrote: post #20

People keep on talking about (prefers-color-scheme: dark), but it isn’t what they want it to be—never has been, and probably never will be (though I will admit that prefers-color-scheme could theoretically be special-cased for favicon rendering). For example, in Firefox, I use the dark theme for the UI, but that’s completely unrelated to the content, and prefers-color-scheme matches the content, not the chrome. Conte…

> For example, in Firefox, I use the dark theme for the UI, but that’s completely unrelated to the content, and prefers-color-scheme matches the content, not the chrome. Content I keep normal, light. Of note is https://bugzilla.mozilla.org/show_bug.cgi?id=1529323 which is requesting to change this behaviour to align prefers-color-scheme to the UI theme if there is no overriding behaviour. I prefer this because now ra…

> There's no user friendly way to set firefox's prefer-color-scheme: dark if the OS does not have the capabilities to do that.

And even if the OS does have that capability, Firefox will ignore it for prefers-color-scheme if you have enabled enhanced tracking protection. Instead, Firefox will always claim prefers-color-scheme: light - the least they could have done is indicate no preference.

Re: SVG favicons have some cool benefits

#67

Post by account42 »

svieira wrote: post #37
legulere wrote: post #36

I find the most interesting part how < and especially “ don’t need to be escaped inside the href attribute. How does the HTML parser know when the attribute stops?

I don't think it's actually valid - the examples just aren't base64-encoding in order to make it possible to read them easily. Edit: Yeah, you at least need to change the `"` to `'` in the inline SVG before it will parse correctly (tested in Firefox)

You need to escape special characters, but you do not need to base64-encode SVG, which gives it a slight advantage over binary formats in data URLs.

Re: SVG favicons have some cool benefits

#68

Post by toastal »

What's annoying to me having created a prefers-scheme and fully-responsive favicon is getting docked by Lighthouse for not having matching dimensions for each value of these PWA dimensions. The favicon changes layout and does a nice job, but our the tool is dumb so I have to optimize for Google's tool instead of a single, maintainable file.

Re: SVG favicons have some cool benefits

#69

Post by soheil »

tyingq wrote: post #51
soheil wrote: post #40

Earlier quoted context omitted.

There won't be any overhead once the file is cached. Your method requires the favicon to keep getting downloaded on every page load.

Both Chrome and Firefox (maybe others) have a separate cache for favicons that acts differently than the regular browser cache. I don't know if it caches data uris but it does cache more aggressively. I know some places like Stackoverflow add a cache-busting parameter to favicon.ico to get past it.

How would a data uri exactly get cached? It’s served inline with every page request.

Re: SVG favicons have some cool benefits

#70

Post by toast0 »

javajosh wrote: post #53
toast0 wrote: post #44

Earlier quoted context omitted.

Early on in a connection, congestion window is much more limiting than bandwidth delay product. Do you really want to spend that limited bandwidth on your favicon that you might have already sent to the user before, maybe even in the same browsing session? It's way better to put it as a separate image, maybe their browser will delay loading it because they're mostly useless. But, you can actually make a favicon usefu…

Good argument - unless the href length approaches the size of the resource itself! I don't understand what you're saying about the utility of the favicon with HSTS. It's not something I'm expert in, so perhaps I'm missing something? What does "push browsers to load them" mean?

If you want to tell browsers that your whole domain (*.example.com) should be https only, you need them to load something from the top level domain (example.com), they're loading is hosted on (say www.example.com or news.example.com). Any resource from https://example.com/ can serve an HSTS header with includeSubdomains, but it might as well be the favicon.
Post reply on HN