Rendering Fonts in Today’s Browsers
Update: Since this post was published, we’ve released Font Events to help you control how fonts load on a page. Read on for details.
All new technologies come with unique quirks — and using fonts with CSS and @font-face is no different.
When experimenting with linked fonts, we have noticed that there can be a delay between when a page loads and when a font displays. It’s by no means ideal, and as designers we cringe when it happens. But why does it happen, and what can we do about it?
All the way back
To get to the root of this issue it’s important to understand the asynchronous nature of the Web. A web page is made of of an HTML document which contains pointers to external resources. Those resources might be CSS files, Javascript files, images, and now fonts. The browser needs to download and parse each of these resources, and then integrate it into the web page that the user sees.
The browser must decide how to handle each of these resources. Each one may take from several milliseconds to a few seconds to retrieve. During that time, a decision must be made whether to display the page without the resource, or to wait until it arrives.
Browser developers each have differing philosophies on what to do in this situation. For example, Safari will wait until it has obtained all known resources before displaying the page. Firefox will display the page while it waits for a resource to download. Both of these methods is perfectly valid; they simply prioritize one thing over another. The manifestation of these decisions is what users ultimately see when they load a web page.
The best right now
The first step is to get the fonts to the browser as quickly as possible. To do this, Typekit has servers on each continent, ensuring that all users have the fastest possible connection to our fonts. This gives our service a consistent starting point — it then comes down to an individual user’s geography, internet connection, browser, and operation system to determine their final experience.
But, we’re working on some tricks to make the perceived delay less apparent. That’s one of the reasons we use Javascript to load fonts – it provides a powerful level of control to designers. We recently rolled out an upgrade to that Javascript which improved compatibility, rendering perception and reduced the file size tenfold. There’s more to come – for example, we’re adding hooks which tell you when the fonts have loaded.
Moving forward
Over the years, browsers have evolved and refined the way they display web layouts, images, and other resources. We fully expect to see improvements in the handling of fonts loaded via @font-face as well. We’re also looking forward to future formats such as WOFF and EOT Lite to provide compression and other optimizations for fonts online. And we’re working with standards bodies and browser makers to better understand how to make progress in all of these areas.
In the meantime, Typekit will continue to improve the actual and perceived speed of font rendering, and give as much control as possible to the designers and developers using our service.
16 Responses
Comments are closed.
So with the new hooks that tell me when the fonts are loaded, I can make all headlines invisible when the page starts to load and then show them once the special fonts are loaded (or after a couple of seconds if the script loads slowly or fails)?
Exactly, that’s the idea. Just a little more testing before we can beta this feature.
…and just a beta invite for me before I can try it out *hint hint nudge nudge* 😉
If we had the ability in TypeKit to apply additional properties to the CSS tags we declare in the “kit”, I would try this trick:
In my site’s CSS, I would set the color of text to be the same as the background of the elements (on body or some root-level element). Then, in TypeKit, I’d apply the “real” color I want. Thus, the text would be “invisible” – blending into the background – until TypeKit’s stuff loaded completely.
There might be other issues with doing this, but it would be interesting to try.
Well, that would only work on pages with solid color backgrounds. Just setting the text to invisible (using CSS) is better. It’s important to note that this method should degrade gracefully, so that the text is visible if the loading of Typekit fails. See my suggested method above.
Woah! And what about accessibility? If you set the font color to be the same as the background color in your CSS and for some reason, any reason, the JS does not load, the user will have unreadable text all around! What’s worse, it’d probably be the headers of your site he cannot read! That’s pretty bad.
I like the idea of hooks. May I suggest a FAQ or Tips page on Typekit to avoid improper use (like the one stated above) of the features? Something like “Best Practices” or “How to spice your site with typekit without losing older browsers”.
Typekit is good and all, but if it’s going to be used improperly then it’s just another problem to be solved rather than a solution.
I agree completely with Enrique R.
To get lower hits on Google, or worse than than, getting a “This page has xx errors” on xhtml validator at w3.org, it´s not an option.
When following a new path towards better designs (and development improvements), the way is forward… not moving in circles.
Good idea to the “Best practices” approach. My two cents, imho.
Cheers to the typekit team!!
So you have servers on every continent—does that include Australia? Some people like to argue Australia is just a big island (but I think officially it’s a continent and Greenland is the world’s biggest island). I’m impressed if you’ve got servers here too.
If you’re testing wacky fonts, you should try the fonts that come bundled with fudemame: http://fudemame.net/
I know others have had trouble with those fonts, although I think it’s mostly the name tables on those fonts that have been the issue.
I don’t know anything really about your service yet, but after reading this post I suggest making the text first load as a common font (ARIAL etc) and then when the fancy font is loaded, change the text to that font. Not a perfect solution of-course, but just an idea.
Interesting read
The flicker when the original font is replaced by the TypeKit font is the one factor preventing me from embracing TypeKit. I’d love to keep my text from appearing until the fonts have loaded (subject to some maximum delay time in case TypeKit service is interrupted), and in this post you mention hooks that might let me do that, but I haven’t seen anything else on the subject since.
I hope that you’ll make a priority of this feature. And if there’s a way for us JS coders to do this already, please let us know!
Great idea!,Jacarri
Thank you.It is grate This is cool,Jacarri
Great stuff!! All working wonderfully,Jacarri
I’m with Trevor and unfortunately this issue still exists as of June 2010. While I’d love to use your fonts, the font “shifting” is just too noticeable and distracting.
Great post. I wish there were less issues with browser compatibility.