Hacker News new | past | comments | ask | show | jobs | submit login

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 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.




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!


I've been converting each font awesome image I need to SVG by hand. It's actually really easy.

1. Open fontawesome-webfont.svg in a text editor.

2. Find the glyph you want to use.

3. Copy it into a new file.

4. Add boilerplate[1] to new file.

5. Change the <glyph> tag to a <path> tag.

6. Add the attribute `transform="scale(0.1,-0.1) translate(0,-1536)"`

7. Open the file in Chrome and see your SVG.

[1] boilerplate:

    <?xml version="1.0" encoding="utf-8"?>
    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 179.2 179.2">
      {glyph goes here}
    </svg>
[Example]

Starting with the following glyph:

<glyph glyph-name="home" unicode="&#xf015;" horiz-adv-x="1664" d="M1408 544v-480q0 -26 -19 -45t-45 -19h-384v384h-256v-384h-384q-26 0 -45 19t-19 45v480q0 1 0.5 3t0.5 3l575 474l575 -474q1 -2 1 -6zM1631 613l-62 -74q-8 -9 -21 -11h-3q-13 0 -21 7l-692 577l-692 -577q-12 -8 -24 -7q-13 2 -21 11l-62 74q-8 10 -7 23.5t11 21.5 l719 599q32 26 76 26t76 -26l244 -204v195q0 14 9 23t23 9h192q14 0 23 -9t9 -23v-408l219 -182q10 -8 11 -21.5t-7 -23.5z" />

We end with:

    <?xml version="1.0" encoding="utf-8"?>
    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 179.2 179.2">
      <path transform="scale(0.1,-0.1) translate(0,-1536)"
        glyph-name="home"
        unicode="&#xf015;"
        horiz-adv-x="1664"
        d="M1408 544v-480q0 -26 -19 -45t-45 -19h-384v384h-256v-384h-384q-26 0 -45 19t-19 45v480q0 1 0.5 3t0.5 3l575 474l575 -474q1 -2 1 -6zM1631 613l-62 -74q-8 -9 -21 -11h-3q-13 0 -21 7l-692 577l-692 -577q-12 -8 -24 -7q-13 2 -21 11l-62 74q-8 10 -7 23.5t11 21.5 l719 599q32 26 76 26t76 -26l244 -204v195q0 14 9 23t23 9h192q14 0 23 -9t9 -23v-408l219 -182q10 -8 11 -21.5t-7 -23.5z" />
    </svg>
The `unicode` and `glyph-name` attributes can be removed.


That's more straightforward than it is easy. Easy would be:

    fa2svg f015


https://github.com/encharm/Font-Awesome-SVG-PNG

This converts the icons to either svg or png in whatever color you want, in any size you want.


That's more simple than it is easy. Easy would be:

    Think "I want that glyph" and then it's just there!


Here, reduced it from 8832 bytes down to 4710

http://olegkikin.com/badge2_cleaned.svg

And it GZips better as well (4793 -> 2120).

I opened it in Inkscape, converted the text to path. Then ran it through SVGCleaner.

You can also do manual simplification in Inkscape (Ctrl + L) till the quality starts to degrade. This lets you reduce things even further:

http://olegkikin.com/badge3_cleaned.svg

3516 bytes, 1726 GZipped.


When reducing SVGs for data urls, I've found you can reduce size even further by scaling the image up, then rounding coordinates to integers. I've written a few scripts to assist with this, but I imagine you could get a similar effect in Inkscape by snapping everything to an integer grid.

Also, merging path elements together helps.

For example, here's the logo in 1952 bytes: http://pastebin.com/YYBpWsDE

And I'm sure there's further room for manual reduction, maybe by switching between strokes/fills and further cleaning up the paths.

(It would be cool if someone were to work on an automated system for doing this kind of simplification. But I have a feeling that it's difficult find a general technique that will work across SVG hierarchies, like scaled/rotated groups, etc.)


Nice! Can I use it?

(If you want, you can also submit a patch in https://github.com/badges/shields.)


Yeah, it's your artwork, I just optimized it.


Yeah, it seems like a tool like that wouldn't be hard to build... hmm... :)


Inkscape can convert fonts inside an SVG to paths.


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.)


Thanks.

One advantage of embedding the fonts is that it eliminates FOUT. If the fonts were split out, once the fonts were loaded, the page would need to be re-rendered anyway. I don't see much practicality of rendering an already light page if it's going to be re-rendered differently quickly after.

By embedding the fonts, I've optimized for latency in downloading fewer files over HTTP1. Even a 2k CSS and 20k-ish font are hardly worth the cost in opening the connections; a 73k all-in-one is more efficent. Let's assume a reasonable 8mbit connection and 50ms RTT.

To download the 72k CSS on a new connection (because it's early in the page load), that takes 100ms to establish TCP and HTTPS handshake, and 122ms to download the 72k embedded font CSS, total: 222ms (at least, not including processing overhead).

For the split version: 100ms for handshakes, and 52ms for the 2k CSS transfer. Here, the browser might keep it open to download one (the headline font) (negligible load time for a open connection), and open another connection for the body text font. (the third monospaced font is rarely used.) The open one would download one 23k font in 73ms. The other connection (in parallel) will take 100ms for handshake, and 73ms for another 23k font. total: 325ms (at least, not including processing overhead).

For higher bandwidth connections, bigger files make even more sense. For split files to truly win, latency will need to be impossibly low, which for the hosting from my apartment basement (even on 150mbit fiber), is impossible.

Even though it's render blocking, browsers will continue loading other assets anyway. A mostly (if not fully complete) page will show the first time, often within a second on wired connections.

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

Yup. Me too!


Hah, this is getting interesting. Would be more fun doing this over a beer, but…

> Let's assume a reasonable 8mbit connection and 50ms RTT.

This is a huge assumption; you’ll be neglecting almost all of your mobile users there. But! Optimise for your use-case, of course.

If you’re self hosting your fonts I would leave them external, `preload` them, and use the preferred `font-display` mechanism to deal with (or elimiante) FOUT and/or FOIT. That’s your extra connections taken care of, and we’ve moved fonts back off of the critical path :)

I think what we’ve both hit upon here is the fact that browsers need to decide on a standard way of handling FOUT/FOIT. Leaving pages blank for up to 3s (or in Safari’s case, indefinitely) would completely eliminate the need to try and circumvent it by base64 inlining :(


Base64 fonts is not always good idea. We switched back to woff as browser was actually longer parsing base64 than downloading woff file in most cases.

With base64 you are also downloading all of them all the time.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: