Gerando texto para a Web




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 {<br />    font-family:<br />        Baskerville,<br />        Times<br />        'Times New Roman'<br />        serif;<br />    }<br />Adicionando um stack nep-grotesque:<br />h1, h2, h3, h4, h5,<br />h6, h7 {<br />    font-family:<br />        Univers,<br />        Helvetica<br />        'Helvetica Neue'<br />        Arial<br />        sans-serif;<br />    }

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:

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 {<br />  font-family: 'Museo 500';<br />  src: url('Museo500.eot');<br />  src: local('?'),<br />       url("Museo500.woff")<br />format("woff"),<br />       url("Museo500.otf")<br />format("opentype"),<br />       url("Museo500.svg#museo")<br />format("svg");<br />    }

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 {<br />  font-family: 'Museo 500';<br />  font-style: italic;<br />  src: url('Museo500.eot');<br />  src: local('?'),<br />       url("Museo500.woff")<br />format("woff"),<br />       url("Museo500.otf")<br />format("opentype"),<br />       url("Museo500.svg#museo")<br />format("svg");<br />    }

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<br />AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css<br /><br />&#60;FilesMatch ".(js|css|html|htm|php|xml|txt|otf|ttf|eot|svg|woff)$"&#62;<br /> SetOutputFilter DEFLATE<br />&#60;/FilesMatch&#62;

Configurando o MOD_GZIP

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

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

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<br />&#60;FilesMatch ".(js|jpeg|jpg|...|otf|ttf||eot|svg|woff)$"&#62;<br />    Header set Cache-Control<br />"max-age=2592000"<br />&#60;/FilesMatch&#62;

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/



fonte: iMasters -