1) I may be looking for static content cdn(s) in the future for a personal project (would love recommendations!)
2) I would love to know how much money people are spending infrastructurally (at least in the beginning) to kickstart their projects
1) Static CDNs
We live in a wonderful time where CDNs are essentially free for small projects. I use CloudFlare for almost everything, simply because it’s so easy to set up, it gives you a free SSL endpoint, it allows you to use naked domain names (faviconkit.com instead of www.faviconkit.com) and it just works well. The HTML is hosted on Github Pages, which is also free.
1a) Number of edge servers
CloudFlare: 151 https://www.cloudflare.com/network/
CloudFront: 117 https://aws.amazon.com/cloudfront/details/
KeyCDN: 30+ https://www.keycdn.com/global-cdn
Google Cloud CDN: 90+ https://cloud.google.com/cdn/
There are a few unique aspects of Favicon Kit specifically - the setup here is a tiny little bit more "sophisticated", which is why I chose Key CDN for the API itself.
2) Money spent on infrastructure (at least in the beginning)
+ Favicon Kit used to run on Heroku until recently, so I spent a few bucks on their hosting and CI plan. (It now runs on AWS Lambda)
+ I have a paid Github account.
+ CloudFlare is free.
+ KeyCDN so far cost me < 100€
Favicons change very, very rarely, so they are perfect candidates for caching; fast extraction and caching are core features of Favicon Kit.
It was mainly the fact that Cloudflare does not cache by MIME type, but by file extension (https://support.cloudflare.com/hc/en-us/articles/200172516-W...) and/or would require page rules (https://support.cloudflare.com/hc/en-us/articles/11500320685...) to honor cache-control headers. (It‘s been a while since I’ve made that decision, so I hope I'm remembering the reasons correctly!)
KeyCDN was simple to set up and their pricing was equally simple and very reasonable, so I ended up staying with them.
I hope this answers your question, JohannesH!
(Though, I will say, the URIs returned for Twitter and the image sizes don't actually align in those cases. The first is actually 192ˣ192 pixels, and the second is 32ˣ32 pixels. That seems odd. Maybe they should have endpoints like domain/large, domain/medium, domain/small?)
The number after the domain is meant to be "this or the next greater size"; the actual size depends on what the source web site offers.
The large icon can take a while to load and you can end up in an inconsistent state where you see a mix of the old and new input.
A great example is 1Password, when you type in the url of an account, it fetches the favicon and displays it when listing your accounts, making is very easy to quickly scroll and recognize what you want.
It seems like something silly to depend on an external service for.
In addition to the other use cases already mentioned here, imagine an e-mail client such as GMail that - in lack of a photo of the sender - at least shows the sender’s company logo (which in many cases is the domain’s Favicon). In such scenarios Favicon Kit can serve as a fallback for services like Gravatar.
For me, I know having small icons helps me scroll through my bookmarks and identify resources I want to reference. Even if the shape of the icon is poor at a small resolution, I think my brain picks up on the color association. So just for the sake of finding things in my bookmarks, I can't imagine getting rid of favicons.
Having an icon for bookmarks and tabs is totally, 100% great - don't get me wrong. but they should be off by default.
Did it actually give you a broken image? It’s supposed to return a "B" on a grey background in such a case.
In Firefox (and possibly other browsers), the browser will not attempt to render images returned with a 404 status. Changing it to return a 200 status should work.
My intention was to be a good HTTP citizen and return the correct status code with a decent representation.
Returning 200 for "not actually found what you wanted, but here's something else you can use" seems odd, but maybe I'm just being too pedantic here and the pragmatic way would be better.
Thanks for pointing out the Firefox issue again, it would have probably never occured to me that FF behaves that way. That hint saved me a lot of time "fixing" the parser.
I’ll check this on the weekend; very curious what‘s causing this. Will fix & let you know.
Thanks for your feedback and suggestion!
There are/have been a few free and open source alternatives out there. I built Favicon Kit because I wanted something fast, scalable and - most of all - reliable.
Most of the free alternatives vary in features, disappear after a while or just become inactive (even besticon’s Heroku demo).
Favicon Kit wants to be the sustainable, reliable, solid, production-grade service for favicons.
There will eventually be a paid plan which guarantees availability for paying customers.