No último um ano e meio, está havendo uma volta do interesse em
tipografia web, marcada pela popularidade de sites como o ilovetypography.com (agora com mais de 67 mil assinantes) e o aumento de artigos sobre tipografia
pertencentes a esse assunto pela comunidade de webdesign e de desenvolvimento.
A tipografia permanece centralizada em estética, acessibilidade e, claro,
legibilidade. Aqueles que são bons nisso e aplicam sua sabedoria na web têm
sido admirados pela ingenuidade de seu trabalho, tanto estilosamente quanto na
sua implementação técnica.

A tipografia traz ordem estética para a informação, auxiliando na leitura e na
navegação A tipografia gera diferenciação; ela é o elemento principal do
branding. No final das contas, uma boa tipografia aplicada na web cria
experiências que são mais simples e prazerosas de usar. Esse entusiasmo
renovado no campo tem gerado uma nova era na tipografia web, que pode ser
atribuída principalmente à ascensão de fontes web e sua crescente
disponibilidade através de todos os tipos de browsers, nos permitindo ir além
de fontes “seguras” para a web (Andale Mono, Arial, Courier, TNR, Impact,
Verdana, Georgia, and Trebuchet MS).

Uma boa tipografia começa com a seleção de
caracteres tipográficos apropriados para o texto a ser escrito; os caracteres
tipográficos certos ou os grupos de caracteres para o trabalho certo. Montar um
romance com gráficos horrendos em TNR ou Helvetica seria impróprio para o
gênero do livro, e do meio gráfico que utiliza. No entanto, seria difícil de ler um bom romance,
daqueles que você não consegue parar de ler (para o que um caractere tipográfico
de transição como o TNR seria bem melhor empregado), se
estivesse em um caractere do tipo script.

A tipografia existe para honrar o conteúdo – Robert Bringhurs

Selecionar bons caracteres é um dos passos, e talvez agora ele esteja
ainda mais difícil, pois temos mais do que apenas fontes “seguras” para a web
para trabalhar (ou aquelas que são as mais prováveis de serem instaladas).
Implementá-las em nossos web sites é outro obstáculo técnico. Este artigo
enaltece as opções para gerar texto para a Web e cobre cada método em detalhe
enquanto mantém seu foco nos padrões da web.

Opções para trazer fontes para a Web

Os browsers implementam fontes customizadas de maneiras diferentes. Essa
disparidade se resume a um debate entre aberto e fechado – trancar os métodos
para assegurar que os ativos das fontes não sejam facilmente alvo de download
nos web sites que os utilizam versus um modelo mais aberto baseado em
confiança. Em algum grau, esse debate apresenta similaridades com aquele que
surgiu quando as imagens se tornaram acessíveis na Web pela primeira vez e, da
mesma maneira, essas diferenças em implementação têm sido largamente
estabelecidas, na medida em que estão, esperançosamente, sendo finalizadas como
padrão pelo W3C.

Existe uma variedade de métodos disponíveis para que possamos trazer
fontes para composição Web. São elas, em uma ordem histórica não muito precisa
de disponibilidade:

• Fontes
  instaladas (a maioria seguras para web);
• Flash (p.e.
   SIFR) e outras técnicas de recolocação JS;
• Cufón, entre
  outros;
• Webfonts EOT/Lite @font-face;
• Webfonts OT/TT via @font-face;
• Webfonts SVG via @font-face;
• Webfonts WOFF via @font-face;
• e Serviços de
  Licenciamento & Hosting.

Fontes instaladas

Escolher fontes instaladas é o método mais fácil e simples. Nas
stylesheets dentro do nosso CSS nós simplesmente recorremos a uma lista de
fontes através da propriedade ‘font-family’e as ordenamos por:

• Desejadas
• De reserva
• Genéricas (p.e.
   serif, sans-serif, monospace,)

Por exemplo, o stack de uma fonte serif
transacional:

p {
    font-family:
        Baskerville,
        Times
        'Times New Roman'
        serif;
    }
Adicionando um stack nep-grotesque:
h1, h2, h3, h4, h5,
h6, h7 {
    font-family:
        Univers,
        Helvetica
        'Helvetica Neue'
        Arial
        sans-serif;
    }

Se a primeira fonte disponível na sequência não está instalada na máquina do
cliente, ela obviamente não pode ser usada para renderização, então ela pula
para o próximo atributo na lista, e assim por diante, até que uma fonte
disponível é encontrada. Boas font stacks refletem o que é mais provável
de ser instalado nas máquinas dos usuários, levando em conta bibliotecas de
fontes padrão para sistemas operacionais populares. Isso permite irmos além,
cuidadosamente, das principais fontes “seguras” para web ao colocar outra fonte
preferencial na lista que também é bem popular.

Técnicas de substituição com Flash

Substituição com Flash é um método estiloso de substituir o texto HTML
com texto Flash com a ajuda de um arquivo JavaScript. A técnica mais popular é
a ‘Scalable Inman
Flash Replacement’ (SIFR).

Apesar de ela suportar sub-definições, esta não é uma solução viável a
longo prazo para trazer fontes realmente customizadas para a Web,
particularmente pela sua confiança em tecnologias que não são padrão e seu uso
de Javascript. Ela também requer bastante performance, gerando um maior tempo
de carregamento da página (predominantemente devido ao número de pedidos feitos
aos arquivos Flash, JavaScript, e CSS necessários). Suas melhores
implementações são para configurar um único cabeçalho ou uma pequena série de
cabeçalhos, mas isso está longe de ser prático para configurar um body copy.

Cufón, entre outros

Uma série de outras opções de
substituição JavaScript se tornam disponíveis em um esforço para fazer o
trabalho sem usar Flash. Cufón é provavelmente a mais popular delas, com uma
fácil conversão online de front-end dos dados da fonte para JavaScript, e que
oferece um bom suporte para sub-definições com uma gama de outras opções de kerning,
escala e compartilhamento de recursos de cross objects (CORS) que limitam o uso
para uma lista de domínios.

Cufón converte caminhos de fontes para VML (na maioria das vezes
obsoleto pelo SVG) armazenados em JSON e renderizados pelo mecanismo de
renderização do JavaScript dentro do agente do usuário. Apesar de ele ter bom
suporte em browser, ele também não é viável como uma solução de longo prazo
devido à sua pobre acessibilidade.

Webfonts: EOT/Lite

Desde o final de 1997, o Internet Exlorer 4 tem suportado o Embedded
OpenType (EOT) para uso através do @font-face, elemento que foi introduzido na
especificação. O (EOT) da Microsoft permitiu o download de ativos de fontes
customizadas para uso em renderizações de texto em uma página web (e tem
ajudado a trazer sistemas de escrita que não são suportados pelo padrão Web)
sem transformar estes ativos utilizáveis no desktop, sendo complacente com as
leis de direitos autorais das fontes.

Os subconjuntos de EOT comprimem e finalmente criptografam ativos da
fonte TrueType, e o CORS é fornecido como parte de uma lista de “caminhos
confiáveis. Sem novidades, com um método proprietário de compressão, um
processo proprietário de criptografia/decodificação, e suportado apenas no
Internet Explorer, EOT e até mesmo o EOT Lite (o qual omite a compressão
autoritária MTX e os confiáveis CORS na listagem padrão) é uma solução
proprietária e não-padrão como um formato webfont.

Arquivos EOT podem ser criados com o WEFT da Microsoft, ou através do ttf2eot, uma implementação open source do conversor. Vale a pena pular o WEFT porque:

• ele usa o método
  de compressão MTX e é ultrapassado por outros métodos como o gzip;
• ele somente
  funciona em Windows e tende a funcionar de maneira não confiável sob
  emuladores; (p.e. Parallels);
• o ttf2eot não
  pode ser comprimido – use uma compressão de sever-side no lugar;
• O Font Squirrel’s @font-face web
  front-end para ttf2eot é simples e
  fácil de usar.

Webfonts: OT/TT

Estas funcionam de maneira similar a webfonts EOT sendo referenciadas no
@font-face src: declaração para que seja feito o download e que
sejam usadas diretamente para renderizar o texto.

OpenType/TrueType é um método viável de disponibilizar fontes com um
suporte decente de browser. Safari 3.1+, Firefox 3.5+, Opera 10+, Chrome
4+;beta, and Android 2.2+). Claro que instantaneamente percebemos que os ativos
das fontes não estão criptografados, restritos a rotas confiáveis, ou a
limitações CORS e estão disponíveis em um formato pronto para usar no desktop,
fora do browser (p.e. editoração eletrônica e processamento de texto) uma vez
que foi feito o download. Além disso, sub-definições e compressões não são automáticas
e os ativos da fonte são de responsabilidade do host.

Webfonts: SVG

Estas também fazem parte das especificações de webfonts do @font-face,
são feitas referência a SVG no src: declaração exatamente como as fontes EOT,
OTF, OU TTF.

Mais uma vez, arquivos SVG não são obscuros e assim facilmente
disponíveis para download para usos que vão além da página web em que estes
estão sendo referenciados. O suporte para browser também é bem diversificado
(Firefox 3.5+ Chrome 0.3+, Opera 9+, Apple+, and Safari 3.1+), e, com ou sem
fontes OT/TT, sub-definições e compressões caem sobre o host.

Arquivos SVG podem ser comprimidos pelo gzip em arquivos.svgz.

Webfonts: WOFF

Técnicas de substituição de Flash/JavaScript e o Cufón mostraram aos
tipográfos e tecnólogos web que um formato de webfont dedicado, aberto e
padronizado era necessário. O EOT, da Microsoft, a extensão Lite EOT da
Ascender, OT/TT e a fonte direta SVG vinculando todas elas, competiram no
terreno aberto da Web em concursos de popularidade para ver qual deles iria ser
adotada primeiro com o maior uso generalizado e suporte de browser. Essa
competição trouxe à tona a discussão sobre o w3c em vez de um formato aberto
e padronizado de webfont. O woff  tem o objetivo de preencher essa lacuna.

Trabalhando com a declaração do @font-face, a WOFF combina a compressão
de dados sfnt-font (PostScript, TrueType, ou OpenType) com um pacote de
meta-data XML para criar um arquivo de fonte aberto perfeito para trazer fontes
para a Web. Arquivos WOFF são criados com a open source sfnt2woff. Sub-definições são da responsabilidade do host. CORS está
disponível via cabeçalhos de resposta HTTP. Em última instância, os dados da
fonte ainda podem ser extraídos, mas, se sub-criados, de-packing um arquivo de
fonte WOFF para extrair informações úteis para uso externo requerem esforço, e
é possível que os dados da fonte recebidos estejam limitados (devido às
sub-criações).

Atualmente, a WOFF é suportada no Firefox 3.6+, WebKit, Chrome 5+, e no
beta de desenvolvimento.

Hosting &
Serviços de Licenciamento

Enquanto a procura por um formato de webfont bom, aberto e padronizado
estava passando por muitas empresas de criação de fontes, muitos tecnólogos começaram a explorar
suas próprias idéias para trazer fontes customizadas para a Web. Desde que o
número de web hosting e serviços de licenciamento começaram a oferecer uma
biblioteca de fontes a uma variedade de planos comerciais e grátis: TypeKit, Kernest, Fontdeck, Monotype’s
webfonts.fonts.com, Typotheque’s
webfont service, &c. Crie uma conta, veja a biblioteca,
selecione, pague, insira algumas linhas de código, atualize; pronto.

 

Homepage da fontdeck.com

Pelo lado técnico, esses serviços fornecem a melhor ou a correta fonte
(EOT, OT/TT, SVG,e em breve WOFF) para os browsers corretos – se uma pergunta é
feita por um usuário usando Internet Exlorer, um arquivo EOT seria indicado.
Sub-definições são feitas pelos provedores, dependendo de quais linguagens e
recursos você deseja e provavelmente vai usar, e a compressão também é um
serviço à parte.

As implementações são comumente baseadas nos padrões, e fornecem um
suporte de browser extensivo. Os front-ends web são fáceis de usar, e têm uma
ampla biblioteca de fontes de qualidade para seleção entre todos os provedores
de serviço.

Achando fontes sem licença

Agora que podemos implementar fontes customizadas na Web usando @font-face,
você deve estar se perguntando onde conseguir fontes de qualidade sem licença e
sem custos para usar na Web (e em qualquer lugar). Lugares que merecem sua
atenção:

• openfontlibrary.org;
• theleagueofmoveabletype.com;
• fontsquirrel.com, particularmente kits font-face pré-configurados;
• webfonts.info
  na lista wiki;
• O Font Directory do Google disponível via seu Font API diretamente
  para linking.

Usando @font-face

Se você escolher não usar um hosting ou um serviço de licenciamento e optar
por hospedar e referenciar arquivos de fontes usando o @font-face você mesmo,
criar os vários arquivos de fontes e pegar a sintaxe para a declaração parece
assustador. Na verdade, se você usar uma sintaxe à prova de balas do Paul Irish
e o Font Squirrel no @font-face, o front-end da web fica moleza.

Criando arquivos de webfonts @font-face

Se você tem uma fonte que você pode e quer usar na web, sua fonte tem
grandes chances de ser um arquivo PostScript OT/TT, que você precisa criar já
comprimido e sub-definido para EOT, OT/TT, WOFF e SVG. A maneira mais fácil de
atingir todos esses objetivos é usar o Font Squirrel do
@font-face web front-end:

Kits gerados pelo Font Squirrel @font-face

Simplesmente selecione e carregue sua fonte, de modo que você pode pegar
o caminho mais fácil e usar configurações padrão para deixar o Font Squirrel
gerar seu kit para você fazer o download, ou você pode pegar o caminho “expert”
e afinar cada detalhe dos arquivos de fonte resultantes. O acesso à
customizacão das sub-definições garante um controle preciso sobre
sub-definições de tipos de caracteres, linguagens, através de tabelas e
escalas, bem como sobre caracteres específicos, apresentando uma lista dos
caracteres que serão incluídos nos arquivos de fonte das sub-criações
resultantes.

Quando você tiver terminado, faça o download do seu kit pronto para o
deployment.

Declarações @font-face “à prova de
bala”

Escrever um @font-face “à prova de bala” não é difícil, mas aqui temos
algumas dicas para você ficar esperto. Vamos ao trabalho.

Basicamente, queremos alimentar o Internet Explorer e o arquivo EOT e
também outros arquivos OT/TT em outros browsers, enquanto fornecemos suporte
para browsers que suportam WOFF. A ordem em que listamos esses arquivos nas
declarações do src: são importantes porque (surpresa, surpresa), o Internet
Explorer vai fazer o download dos outros arquivos mesmo que ele não possa
suportá-los, desperdiçando o tempo de carregamento da página em conexões
adicionais e tráficos desnecessários. Assim, usando
Museo:

@font-face {
  font-family: 'Museo 500';
  src: url('Museo500.eot');
  src: local('?'),
       url("Museo500.woff")
format("woff"),
       url("Museo500.otf")
format("opentype"),
       url("Museo500.svg#museo")
format("svg");
    }

Ao dissecar ists, começamos por dar à fonte que queremos um nome a que
podemos referenciar para o font stacks. O atributo é arbitrário.

Em seguida vem o arquivo EOT; primeiramente no src: liste para evitar
sobreposição.

Em seguida, o local src: chamado, embora nós na verdade omitiremos a
especificação de uma declaração local src:, em vez disso, digite ‘?’.

Existem duas razões principais para isso. Primeiramente, ela previne
(apesar de muito improvável) a chance de um usuário ter uma fonte instalada (a
qual será usada no lugar, evitando o download) que corresponde seu atributo
local mas não é exatamente a fonte desejada, acabando com seu font stack e
possivelmente com seu design. É bem improvável que uma fonte instalada se
chamará ‘?’, e sob a especificação OpenType qualquer unicode de dois bytes não
vai funcionar como o nome de uma fonte, excluindo inteiramente os Macs desse
problema com essa solução.

Em segundo lugar, existe uma grande variedade de bugs ainda evidentes no
Webkit e nos Macs no que diz respeito a lidar com referências locais. Se você
está certo de que existe uma grande probabilidade de um usuário ter sua fonte
desejada instalada, (p.e. é uma fonte popular disponível de graça e sem
licença, como a Museo) e seria improvável que tivesse outra fonte instalada que
apresenta a mesma referência local, então você pode criar entradas locais – se
trata de pesar a probabilidade em cada caso.

Se você quiser definir uma referência local src:, pode parecer estranho
que você possa escrever duas entradas levemente diferentes para o local no
src:, por exemplo: src: local(“Museo 500 Italic”),
local(“Museo500-Italic”). Hein? Isso é porque alguns browsers se
referem a fontes locais através de seus nomes PostScripts. Para encontrar os
nomes locais para uma fonte em um Mac, abra o Font Book, selecione sua fonte e
selecione Preview?Show Font Info (ou ? + I). Para Windows,
existe uma extensão das propriedades da fonte que está disponível para
download. Quando instalada, clique com o botão direito, e zip para Propriedades
em um arquivo de fonte e clique na aba do nome para ver seus detalhes.

Screenshot do FontBook de um Mac OS demonstrando o modo de visualização
do Font Info.

Em seguida, vêm as definições para WOFF e OT/TT  src: ,
seguidas pela definição para SVG. Note o #museo em “Museo500.svg#museo”.
Isso é porque arquivos SVG são arquivos XML e assim precisamos de refereciar a
div inicial (p.e. Depois da abertura da meta-data), que marca o início do
caminho vetor da fonte.

Pronto. Créditos vão para Paul Irish por revelar detalhes essenciar para
escrever definições de sintaxe @font-face à prova de bala.

Problema: estilos e variantes dobrados

 

Ao usar @font-face, é provável termos que lidar com arquivos de fonte
separados da mesma família, para os vários estilos de fonte, p.e. foobar-regular.otf,
foobar-italic.otf, foobar-bold.otf, foobar-smallcaps.otf, e assim por diante.

Isso pode ser tornar um problema – considere elementos como “strong” e “em”
que estão estilizados com a fonte em negrito e itálico, respectivamente. Se
declararmos o itálico como sempre fazemos no CSS (como faríamos para colocar o
estilo em nosso design), o que acontecerá é que o itálico fica digitalmente
grifados (itálicos falsos) pelo mecanismo de renderização da fonte. O
restultado? Nossa fonte itálica ou negrito é digitalmente grifada e colocada em
negrito, criando resultados feios.

Se evitarmos ou sobrepormos as várias declarações (p.e. em { font-style:
normal; }), e por algum motivo nossa fonte @font-face não estiver disponível,
nós roubamos outras fontes no font-stack dos seus estilos. Nós resolvemos esses
dois problemas ao configurar o estilo da fonte dentro da declaração no @font-face,
informando ao usuário agente que já estamos, na verdade, definindo o itálico ou
o negrito, e que estes devem ficar do jeito que estão quando usados para
configurar algo que é declarado via CSS para ser itálico ou negrito.

@font-face {
  font-family: 'Museo 500';
  font-style: italic;
  src: url('Museo500.eot');
  src: local('?'),
       url("Museo500.woff")
format("woff"),
       url("Museo500.otf")
format("opentype"),
       url("Museo500.svg#museo")
format("svg");
    }

Considerações

Advertências, inconvenientes e compromentimentos existem em tudo, e com
a configuração de fontes não é diferente. Existem várias considerações que
precisam ser feitas e mantidas na cabeça ao colocar um texto na Web. Muitos dos
compomentimentos que são feitos no mundo das impressões em papel não se aplica
no meio web, mas outros tomam seu lugar.

Mais não significa melhor

Devido ao crescimento da disponbilidade de novas fontes para a Web, é
importante notar que mais fontes não querem dizer, necessariamente, melhores
tipografias. Fontes são ativos. Elas podem ser vistas como uma ferramenta na
sua caixa de ferramentas; um papel de parede dentro da coleção de um designer.
Ela pode ter acesso a milhares de padrões e cores diferentes de papéis de
parede, mas se a maioria deles forem de pouca qualidade ou apenas deixam a
desejar em recursos que são necessários para abrir e iluminar (ou escurecer, de
acordo com a situação) o espaço, então ter outras mil fontes disponíveis na
verdade não ajuda muito. 

Para a tela ou para o papel?

Além das questões artísticas, muitos caracteres disponíveis como fontes
para a Web não foram designados para o uso na web (ou melhor, para o uso na
tela). O design de texto e tipografia floresceram na indústria de impressão em
papel. Existem centenas de fontes maravilhosamente e profissionalmente criadas,
e famílias disponíveis para qualquer tipo de trabalho em papel, mas muitos
deles não foram preparados para o uso na tela. Boas fontes que foram carregadas
para o mundo digital tem sido cuidadosamente otimizadas para renderizar
perfeitamente em uma tela de pixels. Essa otimização é conhecida como hinting,
e boas fontes web consequentemente têm boas tabelas de hinting.

Sub-denifição

Uma fonte digital é composta de dados e fontes extensas, isto é, quelas
que têm um extenso conjunto de glifos, cobrindo uma grande variedade de
caracteres vão começar a se tornar ativos consideráveis, para o usuário que irá
fazer o download para renderizar. Duas técnicas são utilizadas aqui para
reduzir o tamnho dos ativos das fontes para deixá-las menores e assim reduzindo
a latência da rede.

A primeira técnica é chamada sub-setting e é um processo de removeção de
glifos de caracteres de um arquivo da fonte que não é usado. Imagine uma super
família de alta qualidade com um fantástico suporte de linguagem que também
suporta ligaduras históricas adicionais, vários conjuntos extras de
estilos,SWASHES, letras minúsculas e mais. Uma única fonte só para somente o
‘roman’ desta família excederia 1024 kB. Se nada além de ASCII, Latin 1, Latin
Extended-A, and Latin Extended-B é necessário (o que cobre todas as línguas
Western European com um pouco de espaço para manobras) existem muitos
caracteres não utilizados para os quais os glifos podem ser adquiridos por download
redundantemente.

A sub-definição pode ser feita em um editor de fontes (tais como o FontForge, o
software live para edição de fontes). Simplesmente abra sua fonte, selecione os
blocos de caracteres não usados e os deletes; salve – mas mantenha uma cópia do
seu original.

Compressão

A segunda técnica é a compressão. Comprimir ativos de fontes é muito
parecido com comprimir arquivos para reduzir o tamanho dos anexos de e-mail.
Através da compressão de arquivos de fontes, nós podemos reduzir a latência e o
tráfico na rede. Essa operação é feita no server-side, comprimindo vários
ativos que o usuário requisita, e que na hora do download são descomprimidos
instantaneamente e utulizados para renderizar a página web.

Os dois métodos mais populares são através de extensões externas dos
módulos para o servidor web Apache; mod_deflate e mod_gzip. É provável que seu
serviço de hospedagem web disponbilize suporte para pelo menos um deles (se
não, é um pedido importante de se fazer – afinal de contas, diminui a latência
e o tráfego é do interesse operacional deles).

Se você estiver utilizando o IIS da Microsoft, existe uma configuração
de compressão HTTP que pode ser ativada e ligada.

Configurando o MOD_DEFLATE

Uma vez instalada e ativada, podemos configurar mod_deflate no  .htaccess do nosso arquivo:

# Compression using deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css

<FilesMatch ".(js|css|html|htm|php|xml|txt|otf|ttf|eot|svg|woff)$">
    SetOutputFilter DEFLATE
</FilesMatch>

Configurando o MOD_GZIP

Similarmente, mod_gzip também pode ser configurado no arquivo .htaccess:

# Gzips content if possible
<IfModule mod_gzip.c>
    mod_gzip_on Yes
    mod_gzip_dechunk Yes
    mod_gzip_item_include file
.(html?|txt|css|js|php|pl|otf|ttf|eot|svg|woff)$
    mod_gzip_item_include handler
^cgi-script$
    mod_gzip_item_include mime
^text.*
    mod_gzip_item_include mime
^application/x-javascript$
    mod_gzip_item_include mime ^application/json$
    mod_gzip_item_include mime
^application/vnd.ms-fontobject$
# There is no content-type for OTF yet, so we can get away by just
# listing the extension in the mod_gzip_item include file listing.
# For the sake of being good I have added the vendor-specific
# IANA content-type for EOT.
mod_gzip_item_exclude mime ^image.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
    mod_gzip_send_vary On
</IfModule>

Assim como o mod_deflat do FilesMatch usando o mod_gzip_item_include
file, podemos listar as extensões do arquivo para aquivos onde o mod_gzip
deveria procurar comprimir. O conteúdo dos textos também pode ser listados
através das linhas mod_gzip_item_include mime ao notar o  IANA media types, como é feito para o EOT específico do vnd.ms-fontobject.

 Você pode testar quão bem a compressão está indo através de uma
variedade de plugins para browser ou do uso do REDbot, de Mark Nottingham, um
robô que checa os recursos HTTP procurando por problemas comuns e armadilhas.
Por exemplo, ao chegar em http://sitepoint.com,
o REDbot nota, através do Content-Encoding, que o mod_gzip está em uso. Ao
checar os ativos, podemos ver que 84% do tamanho original da página (quando
descomprimida) foram salvos atrvés do uso do mod_gzip, com figuras detalhadas
para os vários ativos.

Caching 

Finalmente podemos colocar em cache nossos arquivos de fonte, reduzindo
tanto a latência quanto o tráfico de rede. O caching nos permite informar aos
usuários que acessam nossos site e fazem download dos nossos ativos que alguns
desses ativos são improváveis de mudar em um futuro próximo e, assim, acessar o
site para fazer o download novamente será um desperdício de tempo e dados –
apenas coloque (‘cache’) nesses ativos no cache local do usuário. Ativos com
menos chance de mudarem provavelmente incluem stylesheets (arquivos .css ),
arquivos Javascript para a funcionalidade (aquivos script .js) do site e,
claro, dos ativos das fontes.

Podemos colocar em cache vários ativos através do arquivo .htaccess, ao
selecionar novamente uma gama de conteúdo de texto com o FilesMatch e então
configurando o tempo máximo em que estes ativos devem ser colocados em cache
pelos usuários antes de fazerem o download do ativo novamente (como segurança,
cópias do cache continuam sendo atualizadas). Nota: o tempo máximo é definido
em segundos (aqui, 2592000 segundos = 43,200 minutos = 720 horas = 30 dias).

# Cache following file types for one month
<FilesMatch ".(js|jpeg|jpg|...|otf|ttf||eot|svg|woff)$">
    Header set Cache-Control
"max-age=2592000"
</FilesMatch>

E é isso aí!

Agora com a capacidade de aplicar fontes customizadas na Web, seja
self-hosted ou através de um licenciamento de fonte e um serviço de hospedagem,
não se esqueça de ler o próximo artigo desta série sobre estilos que
rapidamente deixam as fontes bonitas.

Texto original de Simon Pascal Klein,
disponível em http://klepas.org/getting-type-to-the-web/.