

Inline CSS fonts - glebm
http://blog.glebm.com/2013/08/28/inline-css-fonts.html

======
steveax
I recently mulled this over on a project. If you have to support multiple font
formats to support a variety of browsers, I think the http request latency is
less of a factor than forcing all browsers to download all formats even if
they won't/can't use them. I think most sites fall into that category.

~~~
glebm
Instead of serving all fonts to all browsers, which would be slow, you can
serve different styles based on the user-agent.

~~~
steveax
User agent sniffing is unreliable and evil.

~~~
bigiain
While you're right - in this case it might be perfectly acceptable to decide
"I'll use unreliable user-agent sniffing to handle 80%/90%/99%/99.999% of my
traffic, and accept some small cases where a slower option occasionally needs
to be used, or possibly accept minor font differences on odd-ball browsers".

------
theandrewbailey
I recently embedded my WOFFs on my blog as data uris, specifically to
eliminate some http requests. I have three fonts. My uncompressed CSS is 100k,
but gzips to 73k.

Then I read that IE doesn't like data uris larger than 32k, so I recompressed
my fonts with zopfli, but one was still ~35k. I did more digging and
discovered that the 32k limit is for IE8; IE9's limit is 4 gig, and everything
is fine.

Some recent articles have seriously questioned the wisdom of doing this.

[http://theandrewbailey.com/](http://theandrewbailey.com/)

[http://wizard.ae.krakow.pl/~jb/ttf2woff/](http://wizard.ae.krakow.pl/~jb/ttf2woff/)

[http://caniuse.com/datauri](http://caniuse.com/datauri)

------
nilliams
Wonder how this ties in with the recent discussion over Data URI slowness on
mobile [1] [2].

I have to admit I've not read all the articles in full so the question may
have been answered. I see Pete did write in a comment to [1] _" I haven't
tried data URId fonts or SVGs but those are great ideas for follow on tests"_

[1] [http://www.mobify.com/blog/data-uris-are-slow-on-
mobile/](http://www.mobify.com/blog/data-uris-are-slow-on-mobile/)

[2] [http://www.mobify.com/blog/base64-does-not-impact-data-
uri-p...](http://www.mobify.com/blog/base64-does-not-impact-data-uri-
performance/)

~~~
glebm
Thanks for the heads up, this looks OK to use on Android 4+ and iOS 6+, I've
updated the post. Surprised to see 600ms for parsing a 20KB base64 on some
older mobile browsers.

------
yannski
Fortunately Compass eases all the process with inline-font-files
[http://compass-style.org/reference/compass/helpers/inline-
da...](http://compass-style.org/reference/compass/helpers/inline-data/#inline-
font-files) :)

------
joshfraser
The trade-off is that while you're cutting down on a large, and generally
blocking request, you're losing cache-ability of that CSS. On the next
pageview, your browser will have to download that font/CSS again. The best way
I've found to handle this is inline it, but use JavaScript to cache it in
localStorage. That way you can get the best of both worlds.

~~~
d0vs
> you're losing cache-ability of that CSS. On the next pageview, your browser
> will have to download that font/CSS again.

That is completely false. A CSS file isn't less cacheable if it embeds inline
fonts or images.

~~~
joshfraser
You don't lose cache-ability because it contains a font. You lose cache-
ability if you inline it in your HTML (which I believe was what this article
was talking about)

------
joeblau
Thanks for posting this. I actually noticed this on my site gitignore.io when
I was trying to cut the load time of my site to under half a second. This is a
great tip to cut down on the loading time, and I'll definitely use this in the
future.

------
Kiro
"flash of missing text or a font change flash while the fonts are loading"

I'm on a really slow connection and I've seen this maybe once or twice so I'm
wondering how big of a problem it really is.

~~~
kalleboo
I've been seeing it more and more recently, and it's quite annoying to have
the whole page loaded except for the actual textual content. I wish there was
an option to have the browser render fonts with a fallback before the webfont
loads.

------
w1ntermute
Isn't SPDY's multiplexing supposed to be a general solution for performance
issues from subresource loading?

~~~
glebm
The font URL is not requested until after the CSS containing it, so there
should still be a (smaller) delay and FOUC. SPDY should be enabled for both
screenshots in the article.

~~~
riobard
The SPDY server could hint the usage of the font before the browser actually
requests it.

~~~
d0vs
Didn't know that! How so?

~~~
riobard
Client: Give me the style.css file.

Server: Here you go! Oh BTW you'll almost certainly need the prettyfont.ttf
file too. Accept?

Client: Sure!

------
jeena
I wonder if the licenses allow doing this.

~~~
steveax
If the license supports website usage, I can't see that it would matter which
mechanism you used to deliver the font to the browser.

~~~
kibibu
I can easily imagine that some fonts may be licensed for distribution through
one provider only, and may not be redistributed under any other means.

Typekit terms of use explicitly prohibit using this method (emphasis mine):

\---

(a) You may Use the Licensed Content to design and develop Your Published
Websites or webpages ( _and must Use any Kit We require for such purposes_ )
and You may reference or encode a link to selected Licensed Fonts within Your
Published Website design so that when others view or interact with Your
Published Websites, they will see Your content displayed with the Licensed
Fonts as You intended; and

(b) You may only Use Licensed Fonts within Your Published Websites as
described in this Section 3.1.2.

from
[http://www.adobe.com/products/eulas/tou_typekit/](http://www.adobe.com/products/eulas/tou_typekit/)

~~~
steveax
Sure, but if the fonts are licensed for being downloaded from your website
(which isn't the case with typekit) it should not matter. I think the crux of
the biscuit here is does the license allow you to host and serve the fonts, or
must they reside on another server (which is the case with typekit and most --
perhaps all -- of the font subscription services). How the browser downloads
the font file from your server is not really the issue.

