Live data from Hacker News

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

pixelambacht.nl

81–90 of 156 posts

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

#81

The font on this page is terrible. Bad legibility!

Out of interest, what is your platform? Looks decent here.

I don't think this is a platform-specific thing. It's an 'artsy' font that takes away from the reading experience. While it might be fine for graphic design, it certainly doesn't seem like one that's suited for big blocks of text.

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

#83
Despite all the hand waiving about accuracy of the claims or the efficacy of CDN fronted caching, etc etc, it is good to see more initiatives around saving (especially mobile) bandwidth use. After moving from EE into full stack js I've been blown away as the duplication present

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

#86

If you're only using a small subset of FontAwesome (as I suspect many people do), I'd imagine at some point it'd make a lot of sense to use data-uri's to effectively embed them directly in an existing request, which would be faster than a CDN? I saw a talk by someone from Smashing Magazine where they basically did this for a subset of their WebFonts (downloading the entire font asynchronously afterward), then they ca…

For my blog, I embedded all my webfonts into my CSS using base64 data URIs. That CSS is 100k, but my server gzips it to 72k, which is not much bigger than the CSS without the fonts + the fonts separately. Because I don't have HTTP2 yet, fewer requests make it faster (especially considering HTTPS), despite the extra size.

If you’re talking about https://theandrewbailey.com/blog/ then your CSS with and without the base64 encoding looks like this:

  101K  9 Dec 18:30 with.css
   99K  9 Dec 18:31 with.min.css
   73K  9 Dec 18:31 with.min.css.gz
  6.8K  9 Dec 18:30 without.css
  5.2K  9 Dec 18:31 without.min.css
  1.8K  9 Dec 18:31 without.min.css.gz
Although this might be true:

> …72k, which is not much bigger than the CSS without the fonts + the fonts separately.

The issue here is that CSS is a render-blocking resource and fonts are not; ergo you’ve increased render-blocking assets from 1.8K to 73K, meaning the user has to download 4056% more bytes before they get to see anything at all. Base64 encoding assets is usually a huge anti-pattern. You’d be better off moving those fonts back out into separate requests.

I hope this comment is taken in the spirit it’s intended: I like making the internet fast :)

Have a great weekend!

(If you’re interested in further reading, look up anything to do with the critical rendering path.)

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

#87
post #78

Earlier quoted context omitted.

http://imgur.com/a/acTMh

Well I'm stumped. Would love to know how we are getting different results, and how your results (16KB) are _so_ much better than mine (110KB) Here is a codepen if someone else wants to try OTF results http://codepen.io/anon/pen/gLjLMv

Opening the link you provided above with Firefox and bringing up network motior, I get the same as you; 109.18 KB "transferred", 131.65 KB "size", and gzip was used according to headers. I thought that maybe "transferred" might be the size of the data after decompression, and "size" would be "transferred" plus headers, but then I checked Chromium and I see 110 KB there as well.

It seems very strange that the size reported by the parent is varying. Why would it do that? Are they all the same file or different ones?

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

#88
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 can put your mind at ease: I took a bit of poetic-mathematic license with that number. I figured that the big sites and the small sites together would average a perfect 1000 fresh-cache vistors a day, but in all probability I'm off by at least 3 or 291 visitors :)

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

#89

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.

Hey, glad you liked it! I tried to get in touch but I guess the message got lost in your noisy inboxes — must be a busy time for you folks. Ping me if there's anything I can help with!

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

#90
post #35
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…

By renaming the CSS file from `font-awesome.min.css` to `fa.min.css` they could save 660GB a day: 73,000,000 sites * 1000 visitors * 10 bytes / 1024^3

A calculator for you, because I'm in pitch-my-side-project mode ;)

https://instacalc.com/50060

Post reply on HN