Skip navigation
Help

Unicode

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Sample of EPSON 太角ゴシック体B at 26pt

EPSON 太角ゴシック体B
   [ show all samples ]
 (epkgobld.ttf)
Source: Free download of ttf30.exe (a self-extracting archive) from the I Love EPSON website.
Stats: Version (blank) has 7,284 glyphs and no kerning pairs
Support: Cyrillic (Russian), Greek, Japanese (Hiragana, Katakana, and Kanji/Han Ideographs), Latin
OpenType Layout Tables: Kana (default, Japanese)

3
Your rating: None Average: 3 (1 vote)

Steve Souders

Our favorite ex-Yahoo at-Google web performance fast-driving all-around guru Steve Souders took a look at @font-face performance recently:

There have been a number of great posts about @font-face performance issues:

* Paul Irish: Fighting the @font-face FOUT
* Stoyan Stefanov: Gzip your @font-face files
* Zoltan Hawryluk (again): More @font-face fun

This blog post summarizes Paul, Stoyan, and Zoltan’s findings plus some very important discoveries of my own.

Among these discoveries is:

* IE doesn’t render anything in the page until the font file is done downloading.
* In all major browsers, ...no files were blocked [by font downloads].
* Busy indicators... are triggered [differently in each] browser

Steve also found that IE and Chrome didn't time out in their attempts to download a font, meaning in the case of the former that the page never displays while waiting for the font, and in the latter that the text doesn't display.

Steve's conclusions are interesting:

* Only use @font-face is you’re absolutely certain you need it.
* If you have multiple font files, consider sharding them across multiple domains.
* Don’t include unused @font-face declarations - IE will download them whether they’re used or not.
* Gzip the font files and give them a future Expires header.
* Consider lazy loading the font files, at least in IE.

0
Your rating: None