Google WebFonts/Font Directory vs. sIFR vs. Cufon vs. others for Design & SEO


Why are people interested in custom web fonts?

Go to Google Webfont API
Google Webfont API

I am pretty sure, most of the readers of this blog know the benefits of this, but for those not knowledgeable, in the web design and development world, designers and developers have been conservative with the use of fonts, sticking to common type face types of fonts commonly installed on everyones computers.  Examples include Arial, Verdana, Geneva, Helvetica, Times New Roman, and Courier, because fonts normally rendered on your web browser are really coming form your own computer. If a designer uses a preferred font file that is not on the user’s computer, they will not see the preferred font typeface and will just see it in the browser default font Times New Roman.

The use of image headings for design creativity

The initial solution of most designers in the past was to use images to express their font creativity. And due to loading time issues, this was limited to headings alone, not being in plain text meant several things:

  • You cannot highlight the text for copying.
  • You cannot print if images are disabled in printing.
  • Font size was not as scalable as plain text when design changes were made.
  • The text on the image is not search engine friendly which required most people to update the alternative text attribute on the images.

This where Google Font API can help a lot, but the question is: Is Google Font the only option?

Let’s review several options and see the advantage and disadvantage of each.

CSS Image Replacement

Method: Uses images as CSS backgrounds of plain text tags, such as on H1 tags or other header tags. And the plain text is above the image, but uses CSS to hide the plain text using a number of techniques, such as display:none, visibility:hidden, height:0px, letter-spacing:-1000em, etc. More information found here.

  • Advantage: Search engine friendly.
  • Disadvantage: Prone to keyword stuffing which gives search engines a reason to double check for manual review. Also not a scalable solution unless the images are dynamically generated using something similar to ColdForge.

sIFR – Scalable Inman Flash Replacement

Scalable Inman Flash Replacement
Scalable Inman Flash Replacement

Method: Similar to CSS image replacement, this just uses Flash instead of images and Flash can display fonts you configure it to display as long as you supply the font file. Unlike CSS image replacement, you can highlight the text generated by sFIR. More information can be found on Mike Davidson’s site, or on the official code site with the sample demo page.

  • Advantage: Search engine friendly. Scalable and can be integrated with some CMS.
  • Disadvantage: Requires users to have the Flash player installed although almost all web browsers use Flash nowadays, and besides it can degrade gracefully rendering the next best CSS styles. Increases loading time since the Flash files and font files will be coming from the web host server. The more headings created, the more browser memory is used in rendering the headings. Although using it in a few headers should not show any noticeable difference but still something you might want to consider since page speed is now one of the search engine ranking factors. Since this runs on Flash, and the popularity of mobile sites increasing with a large percent of users on Apple’s iPhone, iTouch and iPad, you can already expect sIFR not to run at all.

Cufon

cufon - Fonts for the People
cufon - Fonts for the People

Method: A Ukraine-made full JavaScript font renderer that does not need a browser plugin as long as it is JavaScript enable which most browser are. More information at the github website.

  • Advantage: Not dependent on 3rd party browser plugins. JavaScript is rendered natively by the web browser.
  • Disadvantage: A large amount of Cufon converted text accompanied with many common JavaScript and AJAX effects may consume a large amount of the users computer memory, thus slowing down the loading of some pages. Although good programming practices should automatically prevent this from happening. Cufon will not work with JavaScript disabled, but almost every browser on the planet runs JavaScript.

CSS 3 – @font-face

512px-W3C_logo.svg
World Wide Web Consortium

Method: Simply the next wave of HTML and CSS. Websites today are mostly HTML 4 or XHTML 1 and we are now moving towards HTML 5. Most websites use CSS 2 and we are moving into CSS 3. To make this happen is making sure the browsers render these properly based on W3C defined standards, a large amount of users also upgrade to the latest browsers. Once that happens, the custom fonts will be as easy as writing HTML and CSS and giving a font source file. Nice article and samples can be found on A List Apart.

  • Advantage: Like Cufon, this is not dependent on 3rd party browser plugins and even going a step further, it is not dependent on JavaScript also. If ever this is not supported, this can do graceful degradation and have universal web fonts as a second choice fall back.
  • Disadvantage: This seems to be the future, but has to have a high adoption rate before using this method to make sure it is fully supported. Almost all latest browsers support this, and it is just a question of how many people have been updating their browsers to the latest version.

Google WebFont API

Method: This is simply running CSS 3 – @font-face. So from here alone, you can implement CSS3 without Google WebFont API, but after looking at the code deeper, there seems to be some browser detection that may slightly change the code. You can try it out today at Google Webfont API

  • Advantage: Although it is based on CSS 3 and you can do this yourself, at least you don’t have to do it yourself. For sure Google will come up with upgrades HTML and CSS standards change and various browsers upgrade, you have to worry less on the scalability, cross-browser compatibility making your site more future-proof. Using Google’s WebFont API also lessens the server load as you are pulling your font files from Google’s servers and page speed is one of the known SEO factors. Also using Google’s header rendering avoids the use all other methods that gives Google less reason to dig in deeper since CSS image replacement and sIFR are both prone to hidden text keyword stuffing.
  • Disadvantage: Still in beta stage and limited to a few font files as of this current month. Shares the same disadvantages of CSS 3 listed above.

Tested Google WebFont Differences

Rendered appearance on Google Chrome, Firefox, Opera, Safari all looked the same:

Sample Google Webfont API rendering on Google Chrome
Sample Google Webfont API rendering on Google Chrome

But for some reason, the same effect was not appearing in Microsoft Internet Explorer 8. The shadows were not appearing with and without compatibility view enabled.

Sample Google Webfont API rendering on MSIE 8
Sample Google Webfont API rendering on MSIE 8

And just for you to see how the graceful degradation happens, I have loaded Google Webfont API in Netscape Navigator 9.

Sample Google Webfont API rendering on Netscape 9
Sample Google Webfont API rendering on Netscape 9

Even if there was no shadow in MSIE, I assume they will continue to improve this and in the future it should probably be supported. For sure they are looking at browser detection in the implementation as I have compared the code of the CSS file in various web browsers, even if the URL is exactly the same, there were a few lines that were not the same proving user-agent detection is happening.

In Google Chrome:

@media screen {
@font-face {
font-family: ‘Tangerine’;
font-style: normal;
font-weight: normal;
src: local(‘Tangerine’), url(‘http://themes.googleusercontent.com/font?kit=_jMq7r9ahcBZZjpP8hftNA’) format(‘truetype’);
}
}

In MSIE 8:

@font-face {
font-family: ‘Tangerine’;
src: url(‘http://themes.googleusercontent.com/font?kit=_jMq7r9ahcBZZjpP8hftNA’);
}

In Firefox, Netscape, Safari and Opera

@font-face {
font-family: ‘Tangerine’;
font-style: normal;
font-weight: normal;
src: local(‘Tangerine’), url(‘http://themes.googleusercontent.com/font?kit=_jMq7r9ahcBZZjpP8hftNA’) format(‘truetype’);
}

Would I personally use Google WebFont API? Why not. The disadvantages do not seem to be major disadvantages, it is a scalable solution, and improves page speed which can improve SEO overall. If ever there is any other font typeface you really want that is not in Google Webfonts, then I will use CSS 3. Would you use or not use Google Webfont API? Yes? No? Why? We are interested to hear your views, and possible views from your friend web designers/developers as well.

Leave a Reply