If you're like any modern web designer worth their salt, you love you some @font-face. And with the coming of the retina display to laptops (still rumored of course), you know that @font-face will save us all. You do know that, right?
There is of course two popular ways to implement your webfonts. You can use the tried and true method of converting your web-licensed fonts to a CSS ready package from Font-Squirrel's generator, or you can use a slick javascript based implementation from everybody's favorite recently Adobe aquired startup, Typekit.
Typekit of course gives you a whole library at your disposal, depending on the pricing plan you sign up for, making it a pretty robust choice for designers working on lots of projects.
The self-hosted, CSS based option (Font-Squirrel, Google Fonts API, etc), however, turns out to be the more performance friendly option. Especially when you dig a little deeper...
We don't need no stinking basics
Font-Squirrel has tons of free webfont kits already setup for you on their site, with pretty standard settings. But we don't want "pretty standard" performance, we want optimized performance, baby!
This is where we instead go to the generator. The deal here is that you can upload local files and then create your own advanced settings for the @font-face kit that results. If you want any of the fonts on Font-Squirrel but wish to use the generator, just download the basic font to your local, and then upload it again to your generator.
There's several settings that you'll want to be mindful of, and with some basic understanding you can pick the correct performance-optimized options. For more details on this, you've GOT to check out this excellent article from Artzstudio.com: Web Font Performance: Weighing @font-face Options and Alternatives.
Enter the Basic Latin subset
I was already familiar with most of the performance optimized settings, but it wasn't until after my friend and fellow CURE colleague JK forwarded me that article that I found out about the Basic Latin subset.
So it turns out that in the Font-Squirrel generator, if you select "Advanced", and then under "Subsetting" you select "Custom Subsetting", you can drastically reduce your font file size by selecting only the set of characters you're only going to be using on your site. So if you only plan to use English language on your site (and don't intend to support things like Google translate mind you), then you can pretty safely select only "Basic Latin" from the "Unicode Tables" category, and leave everything else unchecked.
If it turns out that Basic Latin doesn't cover all of your needs, you can either add additional categories as needed, or even add single characters to the set! What this means is that your resulting font file will only contain the characters you need, thus dramatically reducing the overall file weight, and in turn reducing the user's load time.
BONUS: Data URI
One thing the article does not talk about that I always recommend is using the Data URI option. Under "CSS Options," be sure to check the "Base64 Encode" (screeenshot).
What this does is convert the font file to a Data URI, which essentially means that the font file is embedded directly in your stylesheet as Base64 data. It makes your stylesheet longer, but it reduces the number of server requests that the users browser will have to make for loading the page. So overall it's a win.
Plus, if you are using a service like Tumblr, or even a CDN where your stylesheet is referencing assets held on a server that your site doesn't live on, Firefox does't like that (without designated accepts headers anyway) and you have to use this method if you want your webfonts to show up in Firefox. So it's a win-win.
But for it to really be performance positive (and not neutral or negative) I suggest using only the Data URI, and removing the previous declaration in the generated stylesheets for the linked font versions.