The FOSS web community should participate in a global feature freeze and stop creating new libraries and frameworks for a year or two to work on stuff like this instead. Just so much opportunity everywhere.
Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
11–20 of 156 posts
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#12There are some really valid points in here and I dislike the idea of using the whole font when only a few icons are required. But, isn't subsetting going to result in users now caching your subset instead of a cached copy of everything? I would think that does more harm than everyone grabbing a fully cached copy once from a cdn.
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 provides a new one) the group is split again.
But then split that across all the fonts, formats, and compression schemes available and you'll see that the chance that a visitor has seen that font, at that version, from that CDN, using that compression scheme, in that format at any point in the past EVER is actually significantly smaller than you'd think.
Which brings us into the next point. Even if you've seen it before, the chances that you'll have it cached is pretty small. Browser caches are suprisingly small in the grand scheme of things, and people tend to clear them more often than you think. Add in privacy browser mode and "PC cleaner" programs and the average person's caches lasts much shorter than at least I expected it to.
But even worse are mobile caches. IIRC older android had something like a 4MB cache!!! And until very recently safari had something like a 50mb limit (and before that didn't cache ANYTHING to disk!). Now it's better, but you are still looking at a few hundred MB of cache. And with images getting bigger, big GIFs being common, huge amounts of AJAX requests happening all the time in most web pages, you'll find that the browser cache is completely cycled through on a scale of days or hours not weeks or months.
IMO it's at the point where the "dream" of using a CDN and having a large percentage of your users already have the item in their cache isn't going to work out, and you are better off bundling stuff yourself and doing something like "dead code elimination" to get rid of anything you don't use. And that method only becomes more powerful when you start looking at custom caching and updating solutions. A few months ago I saw a library that was designed to only download a delta of an asset and store it in localstorage so updates to the application code only need to download what changed and not the whole thing again. Sadly I can't seem to find it again.
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#13If 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 cached their WebFonts in LocalStorage, but it seems like it make even more sense for an icon font where you're using a very small subset.
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#14Unfortunately I think a lot of the points in this article are lost if you assume that the CDN's serving up the TTF for FontAwesome are using GZIP compression.
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#15There are some really valid points in here and I dislike the idea of using the whole font when only a few icons are required. But, isn't subsetting going to result in users now caching your subset instead of a cached copy of everything? I would think that does more harm than everyone grabbing a fully cached copy once from a cdn.
The distribution of icons used is probably not uniform, so it's not like a worst case scenario of all misses all the time. Just the less popular ones.
Even if you subset is the same as mine, if each of us is doing the subsetting ourselves, we won't share the same URL, hence the browser will still fetch it twice.
On the other hand, it seems that FA themselves are building a CDN with subsetting, so they could in fact provide those shared subsets. Unfortunately (but understandably) it's paid, so most of us can't use it.
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#16If 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…
That is what I did for the shields.io logo: https://raw.githubusercontent.com/badges/shields/master/logo...
Unfortunately it is still a bit big. Simply converting it to SVG would probably be smaller. I'd welcome a simple tool that does that!
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#17If 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…
That is what I did for the shields.io logo: https://raw.githubusercontent.com/badges/shields/master/logo... Unfortunately it is still a bit big. Simply converting it to SVG would probably be smaller. I'd welcome a simple tool that does that!
Yeah, it seems like a tool like that wouldn't be hard to build... hmm... :)
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#18Seems like they could now afford to have the author consult on the project.
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#19Unfortunately I think a lot of the points in this article are lost if you assume that the CDN's serving up the TTF for FontAwesome are using GZIP compression.
I was curious and checked out FA's CDN https://use.fontawesome.com/releases/v4.7.0/fonts/FontAwesom... and the rest of the fonts as https://use.fontawesome.com/releases/v4.7.0/fonts/fontawesom... (not sure why they name the OTF differently)
otf 110KB
eot 102KB
svg 157KB
ttf 102KB
woff 96.1KB
woff2 75.8KB
Re: Saving the Internet 2000TB a Day: Fixing Font Awesome’s Fonts
#20If 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.