Live data from Hacker News

We analyzed 425k favicons

iconmap.io

91–100 of 131 posts

Re: We analyzed 425k favicons

#91
post #72

Earlier quoted context omitted.

This is bad math, not researched heavily but in 2020 discord had 300 million users. 285kb goes a long way with wasted energy and bits flowing through the pipes. I agree generally with what your saying though gzipped sizes are what's being sent some CPU usage somewhere to unzip. less bytes == less waste?

PNG basically includes gzip in the file format, so you're not reducing the amount of CPU used, you're just moving where it happens.

Includes but doesn't always use. PNG also includes filters which can dramatically decrease sizes, especially when combined with compression.

That's why tools like OptiPng basically brute force all the combination of options. Depending on the image content different combinations of filters and compression will get the best file size.

Re: We analyzed 425k favicons

#92

Aside: This article is a decent usecase for the esoteric `image-rendering: pixelated;` css property.

My website, gameboyessentials.com, would not exist without this esoteric CSS property. I wanted to show Game Boy images in their exact resolution (160 by 144). With image-rendering: pixelated; I have crisp pictures on my site whose sizes are counted in bytes.

Re: We analyzed 425k favicons

#94
post #17

> In fact, I recommend that browsers ignore these hints because they are wrong much of the time. I don't agree. That's the kind of coddling that encourages incompetence. Instead of compensating for others' mistakes, just let their stuff break. I wonder if Safai on iOS ignores the hints. When I tested, I was surprised to see that pressing the share icon, which holds the option for `Add to Home Screen`, would cause a d…

That may be your viewpoint but browsers have historically always taken the other viewpoint. Take HTML parsing for example. You can miss closing tags and a ton of other stuff, and it'll all work on a best-effort basis. The browsers job is to do the best it can, that's what users want. No one would use a browser that breaks at the smallest tiniest error in the source code.

> browsers have historically always taken the other viewpoint.

except for the short-lived XHTML fad which tbh I kind of miss every day

Re: We analyzed 425k favicons

#95

It such a shame that Safari does not support SVG favicons. It's the only major browser which doesn't: https://caniuse.com/link-icon-svg All current browsers support PNG.

Will it look good on a browser tab? Seems like the res would be too low.

It's a vector graphic; its resolution is whatever you render it at. "S" as in, "Scalable".

Sure, there is some nuance in that you wouldn't want some fine detail to get lost at the displayed size, but presumably you know you're making a favicon when you do so.

Or, you're the NFL & you're going to supply a 4 megapixel image IDK.

Re: We analyzed 425k favicons

#96

Huh, there's a row of identical icons of 3 blue circles (search for cashadvancewow[dot]com) and all the domains using them are loan-related. Interesting way to do forensics on clone sites (although trying a few of them, they're not showing any icons right now, and the URL /favicon.ico 404's) And I checked a few of the sites, I just got lorem-ipsum style landing pages. I wonder what's the point, or are the scammers us…

There are multiple runs of "just a bit too abstract" icons that point into the abyssal cesspools of the Internet. Most of them seem to be about loans, so I'm going to avoid announcing that too loudly if I ever need a loan, since clearly, there are some scumbags out there.

Re: We analyzed 425k favicons

#97

Earlier quoted context omitted.

If they had used static content, it would remain 100% accessible to them, but also vastly more secure. Dynamic content generation on the fly for a blog is unnecessary complexity that invites attacks.

wouldn't that preclude a few popular features like a rich text editor?

I thought about "serverless" blog.

Here's some rough scheme I came up with (I never implemented it, though):

1. Use github pages to serve content.

2. Use github login to authenticate using just JS.

3. Use JS to implement rich text editor and other edit features.

4. When you're done with editing, your browser creates a commit and pushes it using GitHub API.

5. GitHub rebuilds your website and few seconds later your website reflects the changes. JavaScript with localStorage can reflect the changes instantly to improve editor experience.

6. Comments could be implemented with fork/push request. Of course that implies that your users are registered on GitHub, so may not be appropriate for every blog. Or just use external commenting system.

Re: We analyzed 425k favicons

#98

Earlier quoted context omitted.

That may be your viewpoint but browsers have historically always taken the other viewpoint. Take HTML parsing for example. You can miss closing tags and a ton of other stuff, and it'll all work on a best-effort basis. The browsers job is to do the best it can, that's what users want. No one would use a browser that breaks at the smallest tiniest error in the source code.

> browsers have historically always taken the other viewpoint. except for the short-lived XHTML fad which tbh I kind of miss every day

XHTML is still supported and works even with HTML5 tags.

Re: We analyzed 425k favicons

#99
post #79

Earlier quoted context omitted.

Ugh, HEAD is not being universally supported, at least for static content? Okay, I accept that this has value then. As for the MIME type, for image types I'd say it's more than stable enough. Certainly much, much more stable than the 6.7% error rate mentioned in the article here, I'd be surprised if it was even 1%. If you double click on an image on your desktop for example, you can in almost all cases expect that it…

You might be overthinking this. I agree with the philosophy that stricter is better, but in this case what do you expect broken hints to do? They’re not used for rendering, they’re used for figuring out what to fetch. A HEAD request would be far less efficient than knowing ahead of time what to fetch: 1 request versus 2N+1 requests. What you suggest sounds all fine but the entire web is user input for a browser, so n…

Just don't ignore filename extension. favicon.svg is SVG and that's about it. If you don't support SVG, don't download it. If you want to store png in favicon.svg, don't do that.

Re: We analyzed 425k favicons

#100
Less analysis, but a couple years ago I posted a script to download and then generate mosaics from favicons: https://smalldata.dev/posts/favicon-mosaic/

example image: https://smalldata.dev/images/mosaic.jpeg

script to get the favicons: https://gist.github.com/philshem/e59388197fd9ddb7dcdb8098f9f...

Post reply on HN