Comments on: Optimizing @font-face For Performance

By: Font Dragr: A drag and drop font tester | The CSS Ninja - All things CSS, Javascript & xhtml

Tue, 20 Oct 2009 19:42:52 +0000

[...] how I could dynamically add a dropped font to be used in the page. I saw this article on embedding custom fonts using a base64 encoded string. In the file API we have the getAsDataURL() method to return a file as a data url [...]

By: samgrantdesign » Blog Archive » Using the @font-face tag

samgrantdesign » Blog Archive » Using the @font-face tag — Sun, 02 Aug 2009 00:33:43 +0000

[...] Optimizing @font-face for performance [...]

By: James John Malcolm

James John Malcolm — Sat, 25 Jul 2009 15:10:25 +0000

@Robert Quite right, that’s one of the reasons I’m happy FF3.5 shows you the text in non-@font-face fonts first.

Also, Typekit is supposed to break up the font files in different bits (as part of their drm font-protection) which would add extra latency…

By: charles

charles — Mon, 06 Jul 2009 18:53:40 +0000

But, if you could use localStorage that is new in FF3.5 then the font would ONLY be downloaded 1 time.
The only catch is how to get the data:url string from localStorage and into @font-face src?

By: Pepe

Pepe — Sun, 05 Jul 2009 09:37:55 +0000

Are fonts really cashed? I still get the effect of seing the text shown for a milisecond without the downloaded font when refreshing a page that downloads a font.

This effect is quite ugly, I don’t see this with Safari 4

By: Mithgol the Webmaster

Mithgol the Webmaster — Sun, 05 Jul 2009 03:10:44 +0000

A separate stylesheet is no better than a separate font file.

In fact, if both are external, I won’t bet (without pre-testing) on whether the Access Control headers fail for the former.

By: Robert

Robert — Sun, 05 Jul 2009 01:54:53 +0000

@James John Malcolm: Yes, but in practice the latency of several fonts will likely be more of a performance barrier than a few extra KB.

By: James John Malcolm

James John Malcolm — Sat, 04 Jul 2009 18:30:06 +0000

Well, a 10-15% overhead for a regular serif, bold serif, italic serif, nevermind a whole sans-serif family…it all adds up!

By: Da Scritch

Da Scritch — Sat, 04 Jul 2009 07:23:23 +0000

This “good advice�? will be spotted by copyright-fanatics to enweighten their websites in 3…. 2…. 1….
Oooooooh ! JPEG headers and backgrounds urldata-encoded in the source code !

Just joking. Anyway, it is very useful, if you use this kind of technique (and it’s better for very small documents, as 1Kb png images, not for 50Kb fonts), to activate gzip compression on server-side. But remember that CSS and JS zipped-served are NOT cached by MS-W-IE. So, use it a lot, it makes a better “cool and fast attitude�? for non Trident based modern navigators

By: Robert

Robert — Fri, 03 Jul 2009 20:07:50 +0000

Very true.. but most sites gzip these days cutting down the file size… I suspect you’d see 10-15% overhead in practice.

Considering the large amounts of JS and images on many sites today and the proliferation of broadband connections, file size is generally less important than the # of requests.

A typical cable modem connection these days can easily handle 6Mbps and burst as high as 20Mbps. Unfortunately the latency is still there.

An extra 30kb (assuming 2x 15kb overhead on a base64′d 50kb font) is going to be perceived faster in many cases than an 2 extra requests (assuming you only use 1 serif and 1 sans serif font). Especially if your not offloading to a CDN or other low latency origin.