Wednesday, October 14th, 2009

@font-face Is Cool… But Does It Scale?

Category: CSS, Performance

Steve Souders

Our favorite ex-Yahoo at-Google web performance fast-driving all-around guru Steve Souders took a look at @font-face performance recently:

There have been a number of great posts about @font-face performance issues:

* Paul Irish: Fighting the @font-face FOUT
* Stoyan Stefanov: Gzip your @font-face files
* Zoltan Hawryluk (again): More @font-face fun

This blog post summarizes Paul, Stoyan, and Zoltan’s findings plus some very important discoveries of my own.

Among these discoveries is:

* IE doesn’t render anything in the page until the font file is done downloading.
* In all major browsers, …no files were blocked [by font downloads].
* Busy indicators… are triggered [differently in each] browser

Steve also found that IE and Chrome didn’t time out in their attempts to download a font, meaning in the case of the former that the page never displays while waiting for the font, and in the latter that the text doesn’t display.

Steve’s conclusions are interesting:

* Only use @font-face is you’re absolutely certain you need it.
* If you have multiple font files, consider sharding them across multiple domains.
* Don’t include unused @font-face declarations – IE will download them whether they’re used or not.
* Gzip the font files and give them a future Expires header.
* Consider lazy loading the font files, at least in IE.

Posted by Ben Galbraith at 6:00 am

2.5 rating from 42 votes


Comments feed TrackBack URI

Short answer: not really.

Comment by richtaur — October 14, 2009

Correction update: The IE issue of page rendering being blocked only happens when there is a SCRIPT tag above the @font-face declaration. This mitigates the problem, but a significant issue may still exist. A survey of the Alexa top ten US sites shows that seven of them have a SCRIPT tag above all their stylesheets and STYLE blocks. If this is representative of @font-face early adopters, their IE users may not be happy.

Comment by souders — October 14, 2009

There are various ways of ensuring browsers don’t download unsupported font formats.

To hide @font-face declarations using EOTs from non IE browsers, use the conditional comment approach

There’s a CSS3 addition to @font-face that causes IE to ignore any font-face declarations using it. If you add a format hint to your @font-face declaration like so

@font-face {
font-family: Product;
src: url(./fonts/Know-Your-Product/know_your_product.ttf)

– format(“truetype”) *as part of the src property value* then IE ignore the rule.

*plug alert* I’ve got a chapter in my upcoming “Developing with Web Standards” (New Riders, published November 9) devoted to embedded fonts

Comment by JohnAllsopp — October 16, 2009

i want to add that i work a lot with chinese language and fonts, and imho there are several problems with combining CJK on the web and the @font-face approach.

#1 is that there are over 70.000 CJK code points defined in Unicode 5 and above. even chinese fonts that try to cover only basic needs typically have sizes counted in megabytes. for many users, especially users on slow lines, this entails a very long page loading time.

#2 to a certain degree, it is feasible to produce subsets of characters based on usage statistics, but beyond what can be said about the most freuquent characters used for a given locale, style of writing, and field of subject, it is hard to impossible to predict the occurrence of not-so-frequent characters. this is to be expected, and a well-documented side-effect of zipf’s law (basically: linguistic distributions that draw from large repertoires have very pronounced long tail characteristics, meaning that arbitrarily rare items can and will occasionally occur in arbitrary contexts. e.g. your speech consists to 99.99% or so of words you find in webster’s; but in the course of a year of talking, you will repeatedly utter the occasional valid, known, and documented word that is still outside of the collections of bookshelf dictionaries).

in short, this means that it is impossible to pre-produce, without given a concrete text, a properly subsetted font and be reasonably sure it will be possible to write a given text with such a pre-produced subset. the other way round: if the solution for big, general-purpose CJK font files are subsets, then such subsetted fonts can only ever meaningfully produced on an individual, text-by-text basis (akin to the customized font subsets used e.g. for PDFs).

it is remarkable in this context that while languages using scripts with smaller repertoires, such as english, greek, romanian, or hindi, we can often rely on the following heuristic:

“if letter X is used, and letter X is at unicode codepoint C, which is in unicode block B, then it is likely that (1) for this kind of text, other letters from that block B will also occur in the document; (2) codepoints C+1, C-1, C+2, C-2, … will also occur in texts of this kind.”

that is, texts for most languages will show a strong tendency for clustered unicode codepoints, using a rather small and pretty compact subset of unicode.

not so in chinese. even BMP1 defines thousands upon thousands of chinese characters. these are arranged in a fashion that is not linked to any kind of usage statistics (which would not have been feasible in detail). as an effect, and because the character repertoire of any given, non-contrived natural language text will be small against the repertoire of chinese characters as defined in unicode, densely packed for a given class of texts the usage statistics of unicode characters will be not.

in other words, while usage of H makes usage of G, then F, then E, and of I, then J, then K, and so on more likely in latin script, neighboring codepoints having a strong preponderance to co-occur in typical situations, in chinese, this does not work in chinese. to wit, here are the first few codepoints of the cjk unified ideographs block of unicode, from 0x4e00 onwards: ????????????????????????????????????????????????. anyone with a cursory knowledge of chinese or japanese can immediately see that while this list contains characters that appear in virtually *each* and *any* chinese or japanese text (like ????), it is also dotted with characters that a vast majority of native writers will *never* *ever* write or encounter as individual characters *in a lifetime*, such as ???. this is zipf’s law at work.

the net effect is that subsetting chinese and japanese makes only sense when done individually; for web development, this means you will have to change the font download in case a text has been edited.

i want to remark that while it seems techically possible to prepare appropriate downloads for CJK fonts. as outlined above, the technology is in no way — IN NO WAY — prepared to handle the needs of roughly 14% of the world’s population.

this is not least due to the incredible amount of superfluous complications and deliberate obfuscation and a dearth of capable software in the field of font design and font mangement. doing fonts is simply too hard. it is a complex problem, but font definitions and the way that fonts are employed in present systems have complexities that are not connected with the problems to display a legible and correct image of writing, but are caused by historical reasons, bad implementations, and intellectual property considerations.

add to this the fact that while virtually each single computer in existence is able to spell out latin-1, or at least ascii, the installation of even basic CJK capabilities is still considered to be an opt-in add-on feature for computers delivered to customers outside of china, taiwan, japan and so on. meaning that a typical box bought in germany or hawaii will only display meaningless boxes even for common chinese characters.

Comment by loveencounterflow — October 17, 2009

see what i mean? your comment system swallowed all the chinese characters i entered. it did keep all the latin-1 characters.

wake up people, this is 2009.

for people interested, i here give the codepoints in a hopefully safe way. let’s try. i am not sure what the commenting system will make out of my characters that i have pasted below, using numerical character references as are used in HTML. will they appear as literals? will they be swallow? will they be rendered as chinese text? there is no way of knwoing, short of trying.

the first few characters of the cjk block are: 一丁丂七丄丅丆万丈三上下丌不与丏丐丑丒专且丕世丗丘丙业丛东丝丞丟丠両丢丣两严並丧丨丩个丫丬中丮丯

of these, very rare characters include: 丄丅丬

copy and paste that to a file, name it whatever.html, and open that in your web browser.

i am sort of flabbergasted how stupid some comment systems are when you put them to a test. now i hit the submit button… hope it will work now…

Comment by loveencounterflow — October 17, 2009

hah. i worked. no need to copy-paste for you then. ignore that sentence.

Comment by loveencounterflow — October 17, 2009

I don’t think “scalability” is the issue here – that is, whether the experience works when being delivered to a larger audience. (Let’s assume the font files are being served from Amazon WS or somehing that does scale and handle the load). From that perspective, I think it is clearly “scalable”.

Rather, the question is whether @font-face creates a *responsive* application – which, from the sound of things, it doesn’t.

Are there ways to make it degrade more gracefully?

Comment by tmarman — October 17, 2009

Leave a comment

You must be logged in to post a comment.