Live data from Hacker News

Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

pixelambacht.nl

51–60 of 156 posts

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#51

This is a great article. Some of these are already on the agenda for FA5, but there's some new stuff there for us too. We'll dig in and it's a TODO on the FA5 roadmap now. :) Another thing I'm super excited about is stray points in vectors. We found some new tools for Illustrator that make this a LOT easier and will have a very real impact on bandwidth as well. Super fun.

(Oh and FA5 Pro CDN will allow loading just the icon categories you need. And for real granular control, FA5 Pro includes a desktop subsetter for all backers too.)

Edit: Fixed wording for clarity.

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#53
post #28

Is the 2000TB/day number reasonable, or just clickbait? It's all based on coming up with two numbers that when multiplied say that this resource is downloaded 73 billion times a day. That's 20 times / day for every internet user (even those using it on a 2G connection once a year). Given a reasonable caching period of 1 month, that'd mean the average user visits 600 different sites a month. That seems like much more…

I don't know where they came up with the 73 million sites umber, but let's assume there are that many sites using font awesome.

Most sites are obscure, and rarely get any visitors at all. Maybe 10 a month, or none.

Popular sites that receive a lot of traffic are also visited very frequently by the same user, so the font will be in the cache.

In addition, plenty of sites use a CDN for fontawesome.

I guess that number is off by several orders of magnitude.

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#54
post #45

Earlier quoted context omitted.

It's one of those things that works "in a perfect world", but in the real world it just doesn't work out that well. For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone…

> For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone provides a new one) the group is split again. All this common web stuff that is distributed by several CDNs (as w…

Yeah have thought about this a few times myself. Maybe missing something that makes it impossible/risky? Or maybe its just the tendency to ignore simple solutions.

This not only solves the CDN issue but it also solve the issue of having to rename the files manually everytime someone do a change. It just makes caching that much saner.

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#55
post #45

Earlier quoted context omitted.

It's one of those things that works "in a perfect world", but in the real world it just doesn't work out that well. For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone…

> For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone provides a new one) the group is split again. All this common web stuff that is distributed by several CDNs (as w…

Because anything that can cross domains instantly allows anyone to probe your browser to see what is in your cache.

So to take it to a bit of a rediculous (but still possible) point, I could probably guess what your HN user-page looks like to you. So from there I could serve that in an AJAX request to all my visitors with this content-based hash and if I get a hit from someone, I can be pretty damn sure it's you.

And that only really solves one or 2 of those issues. The versioning, compression schemes, formats, number of fonts, and sizes of browser caches will still cause this system's cache to be a revolving door, just slightly more effective.

And as for the security concerns of using a CDN. Subresource-integrity (which someone else here linked already) allows you (you being the person adding the tag to your site) to say what the hash of the file you expect is, and browsers won't execute it if it doesn't match. So that lets you include 3rd party resources without fear that they will be tampered with.

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#56
post #45

Earlier quoted context omitted.

It's one of those things that works "in a perfect world", but in the real world it just doesn't work out that well. For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone…

> For starters, leveraging caching via a common CDN pretty much requires everyone to be using a single version from a single CDN. If you can't agree on that, then every time a new version comes out the web is split and the caching doesn't work, and every time someone decides to use another CDN (or someone provides a new one) the group is split again. All this common web stuff that is distributed by several CDNs (as w…

The mechanism here (if not the intent) is pretty similar to subresource integrity[1].

[1]: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#57

Wouldn't the most obvious solution be to open-source FA fonts and include them in Linux, Windows, Mac OS, iOS and Android? If they were installed on all systems then we wouldn't really have this issue at all. Given the ubiquity of some fonts this doesn't seem impossible. Or and sorry to say cause I like FA, screw them and see if Apple/MS/Google can have an open standard icon font that doesn't suck.

They're available under the OFA license. They're already shipped with Linux, eg. here:

https://admin.fedoraproject.org/pkgdb/package/rpms/fontaweso...

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#58
post #28

Is the 2000TB/day number reasonable, or just clickbait? It's all based on coming up with two numbers that when multiplied say that this resource is downloaded 73 billion times a day. That's 20 times / day for every internet user (even those using it on a 2G connection once a year). Given a reasonable caching period of 1 month, that'd mean the average user visits 600 different sites a month. That seems like much more…

I don't know where they came up with the 73 million sites umber, but let's assume there are that many sites using font awesome. Most sites are obscure, and rarely get any visitors at all. Maybe 10 a month, or none. Popular sites that receive a lot of traffic are also visited very frequently by the same user, so the font will be in the cache. In addition, plenty of sites use a CDN for fontawesome. I guess that number…

73 million sites comes from our friends at Meanpath (their search engine isn't running anymore, sadly). They showed us on 7.3% of websites. Best guess is there are about a billion sites on the internet. Thus, 73 million.

Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts

#60

Stuff like this is like rearranging chairs on the titanic - 26 kilobytes is a drop in the bucket compared to the bloat created by all the other shit people slap on to their sites - ad scripts for example

That is just a terrible analogy. Saving 20% of bandwidth, if you really want to make a accurate analogy to an event when 1500 people died, would be like saving the lives of 300 people.

Saying "Screw it, More people died in other places" is missing the point. The article even admits this is not the #1 place to optimize... but that doesn't mean you should scoff at it.

Post reply on HN