Comments for Robert Accettura's Fun With Wordage

Comment on Optimizing @font-face For Performance 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!

Comment on Optimizing @font-face For Performance 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

Comment on Optimizing @font-face For Performance 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.

Comment on Optimizing @font-face For Performance by malte

malte — Fri, 03 Jul 2009 19:23:05 +0000

The base64 encoding used in the data: URI will increase the font’s size by a third. Gzipping the CSS file probably reduces this to something lower, but not to a factor of one. So if file size matters, it’s probably better to leave the font a separate file. After the first page load, (in a proper setup) it will be cached just like the CSS.

Also, the whole page won’t be shown until *all* CSS files have downloaded completely. So while this technique prevents some text from showing up in a “wrong” font for a short while, it prevents the whole page from showing up at all for that same time.

Comment on Optimizing @font-face For Performance by Justin Dolske

Justin Dolske — Fri, 03 Jul 2009 19:16:48 +0000

base64 encoding adds 33% overhead for the encoding, so I’m not sure turning large files into a data: URI is what I’d call a optimization!

Comment on @font-face Hacks by Robert

Robert — Fri, 03 Jul 2009 18:09:45 +0000

@Charles: I did a blog post dedicated just to that topic

Comment on iPod touch 2nd Generation? by Buy Cordless Screwdrivers

Buy Cordless Screwdrivers — Fri, 03 Jul 2009 14:28:36 +0000

Hello. Great job. I did not expect this on interent. This is a great story. Thanks!

Comment on @font-face Hacks by Charles

Charles — Thu, 02 Jul 2009 15:14:56 +0000

Does font-face src support a data: URL as this would allow local storage of the font and so a lot quicker?

Comment on Things You’ll Love About Firefox 3.5 by Things You’ll Love About Firefox 3.5

Things You’ll Love About Firefox 3.5 — Thu, 02 Jul 2009 06:05:38 +0000

[...] [...]

Comment on Things You’ll Love About Firefox 3.5 by James

James — Wed, 01 Jul 2009 09:14:23 +0000

Things you'll hate about Firefox 3.5 - crashing on the start page video.