Inline CSS fonts | Hacker News Reader

Inline CSS fonts

blog.glebm.com

36 pointsglebm26 comments

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.

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

User agent sniffing is unreliable and evil.

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

Old wives tale.

Not to mention there are more ways to tell apart browsers than user agent sniffing.

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://wizard.ae.krakow.pl/~jb/ttf2woff/

http://caniuse.com/datauri

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/

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

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.

Fortunately Compass eases all the process with inline-font-files http://compass-style.org/reference/compass/helpers/inline-da... :)

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.

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

Some mobile browser caches have an upper limit of file size. I know the iPhone did at launch, but I haven't kept up with the limits.

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)

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.

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

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.

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

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.

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

Didn't know that! How so?

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!

I wonder if the licenses allow doing this.

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.

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/

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.

For those in the SIL Open Font License (there are a number on Google Webfonts), this is explicitly allowed:

---

"Can I use the fonts in any publication, even embedded in the file

Yes. You may use them like most other fonts, but unlike some fonts you may include an embedded subset of the fonts in your document. Such use does not require you to include this license or other files (listed in OFL condition 2), nor does it require any type of acknowledgement within the publication."

from http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ1...

Reply on news.ycombinator.com