Boagworld Forum

Boagworld is not just a web design podcast, it is also a thriving online community. Whether you build, design or run websites there are always people here to help. Whatever your question there is sure to be somebody with the answer.

Font replacment for body text

I've been dead against this for awhile now, as I think it can slow page rendering down too much and cause problems in older browsers, but noticed that Boagworld uses Font replacement for the bodytext. 

I've also recently used it on a small site as the body text was fairly limited.

So I was wondering what everyone thinks about this- are the techniques and services for doing it getting efficient enough for replacing all your text?

Comments

  • I'd say yes. I've done it a couple of times now, and in this day and age of ridiculously fast internet speeds, and decent font embedding technology, it definitely seems to be a viable option. It's almost a must in some cases, due to the excessive boring-osity (Is that a word? It must be... I just used it!) of the default fonts that just about everyone has.

    Sometimes, as beautiful as Georgia is, it doesn't do the job. Or maybe you're sick of Arial's wannabeness (I'm on a roll here), or Verdana's.... well, it's Verdana. You get my point.

    Of course, as always, it depends on the project.

  • For me: sometimes. Depends on the project. I'll ask questions like: How important is the (specific) font for the design of the site? What is the performance of the site? So maybe for a smaller site with very few images and scripts to download adding the font might make a good positive change with little drawbacks. But in a bigger site which is already at the limit of good performance and little added benefits of a specific font I would not do it.
  • I do on my own stuff but only on some things. I don't do it on any of the actual work I do right now, company policy (something I'm working against).
  • I'm agreeing so far, I suppose it really depends on how well the site needs to perform under a given amount of traffic and requests, balancing against making it read really beautifully.

    Guess it's always easy to take it off a site if it's a problem!
  • Yeah I'd agree with Chillfinn, in that it depends on the site.

    A client of mine was insistent that we used Gill Sans for all her body copy and did my best to talk her out of it, she was that determined she suggested that i replaced the text with images.

    I obviously said no way to this and gave in and used Gill Sans and it seems to be fine, although its not a text heavy website.
  • How would one go about testing performance metrics for this? I'd love to see what the @font-face performance is like in modern browsers, especially mobile.

    One thing I did notice the last time I did @font-face and mixed it with CSS transitions was that it did something weird to the aliasing on my type. Though, now that I think about it, a more recent project didn't appear to have that issue.
  • Good question Doug_S, at the moment we do a quick scan with Chrome's Audit tools to identify blatant general hold ups, but I'm not sure how to test for tablets and phones..
  • Even on this site and having a pretty decent internet connection, I notice that sometimes when loading a page, at first I see the normal text and then after a second or two it suddenly switches over to the other.
  • The big downside is that there can be a delay in loading the font which causes the page to display without the text for a moment. That said, overall I haven't seen any major performance hit.
  • I have used font-face for body text replacement but all too often I see web companies, even some of the larger names in the industry selecting fonts based on their appearance on a mac, never testing to see how the font renders on a PC. Some fonts just don't render nicely on a PC and at times it is actually unreadable at a sizes we most commonly use for body text.

    So long as you test the font you wish to use correctly I see no issue in making full use of it.
  • And remember that the client only has to download the font once, and then has it in cache for at least the rest of the session, and probably on return visits. I know plenty of designers who would say that having the 'right' font on a site is worth the minimal performance hit.
  • I have just created a "google web fonts" only webpage that is made to run like a presentation. On slow connections it doesn't do great, but on faster ones it's perfect. I also added a loading screen overlay to hide the website while the fonts were loading. Let me know your thoughts / suggestions. Check it out here : www.missinglink.co.za
  • @keanrichmond: That's because no font renders nicely on Windows. Even the ones designed by Microsoft for Windows render only alright at best. I seem to remember someone saying Windows 8 does something new that brings it up towards Mac-level of font rendering? Or am I making that up?

    @chillfinn: I'd bet that if we saw any relative performance hit on a desktop you can assume it's going to be compounded on a mobile phone. As @boagworld says there is also that delay in load where you either get un-styled text or the wrong font. Though, this can be helped a bit by properly optimizing your font files. Most sites, for example, do no need all of the variations of o, ø, ö, ó, õ, etc. Unicode range selection can help with that. Then there are tools like FontSquirrel that allow you to select exactly which characters you want. Take a really high quality font like M+ and you can drop that down rather drastically by removing all the extra characters.

    @chris5marsh: But going back to mobile, iOS only caches files under 20kb. Or, I should say, only caches across sessions. Hit the site once and it will cache until you close Safari but once you do you'll have to re-download the files again.

    @anthonyvanbeek: Has there ever been any user studies done on preloading screens, whether it's better for a page to load all at once after such a screen or if it's better to have the page progressively load in? We're talking about slow internet speeds like they don't exist but not everyone has broadband and despite their claims to the contrary, no telecom company in the world has actual 4G. Right now, that 3G-at-best network is going to be what 50+% of all net traffic is. And while some of our websites might not be very mobile-focused right now, they're going to have to be in the future.

    The saddest part of all of this is the devices that stand to benefit the most from @font-face fonts are mobile phones due to their high pixel-densities but because of their slow connections they also just so happen to be the place that can suffer the most as a result of them.
  • @Doug_S: In my case I needed to have a preloader to hide the jumbled mess before the javascript and fonts kick in (shoot me, I know).
  • Is there a down-side to preloaders? People are used to them due to Flash websites, not to mention the OS they use. Is it bad form to use a preloader?
  • @Doug_S Yes preloaders are bad form, I'd rather have a quick site where I can see the text immediately (or close as) even if it means that the bodytext is using Verdana or what have you. I think nice typography is great and we should have it, but not at the expense of websites loading slowly with delays in loading text properly...

    I've been using webfonts.fonts.com recently, and its pretty good but I'm seeing that particularly behind corporate firewalls I'm getting obscene delays in the page text loading up (even if I'm just replacing headers and nav buttons!) sometimes, I'm not sure if this is down to the service or if it happens with the trendier webfonts services? It's making me think about going back to Cufon!

  • Don't use Cufón. It's horrible for accessibility.

    Does it still happen if you use self-hosted fonts?
  • A bit old by web standards but a colleague of mine handed me this the other day: http://www.stevesouders.com/blog/2009/10/13/font-face-and-performance/
  • @Doug_S True, and cufon has some other annoying bugs too! Self hosted fonts work better, just because the request doesn't have to battle getting through our firewall (I have a horrible dev env at work). There's still a delay of course, but it won't hang as long as the webfonts method.

    Seems clear from the metrics that for high traffic sites you should avoid at least bodytext replacement altogether. Typekit seem to have better methods for delivery, but I think the second best method seems to be roll your own and self host. It's s shame webfonts.com doesn't have the option to select Glyphs, I always did that with Cufon. Does typekit allow that?

    Thanks for the article, and from @mattiman , very good summaries and I will re-read later!
  • If you use Fontsquirrel's @font-face generator you can select specific glyphs. I'm planning on using it on an upcoming website to replace all my ampersands with sexy ones in the titles.

    But yes, as might be clear from the other thread on the subject, I've been doing a lot with page performance and @font-face is one of those things that just really drags down performance. I honestly could not tell you why it does but some of the more graphically intensive stuff (border-radius, gradients, shadows) just really drag the page's performance down.

    More, it may have gotten better but combining CSS3 transforms with @font-face fonts used to generate some of the worst aliasing I've seen in a while on webkit browsers. It may be better now but it was to the point where it was unusable.
Sign In or Register to comment.