Uma nova maneira de reduzir o impacto do carregamento de fontes: descritores de fontes CSS

O carregamento de fontes tem sido um bugbear do desempenho da Web, e realmente não há boas opções aqui. Se você quiser usar fontes da web, suas escolhas são basicamente Flash de Texto Invisível (também conhecido como FOIT), onde o texto fica oculto até que a fonte seja baixada ou Flash de Texto Sem Estilo (FOUT), onde você usa a fonte do sistema de fallback inicialmente e, em seguida, atualize-a para o fonte da web quando é baixado. Nenhuma das opções realmente “ganhou” porque nenhuma é realmente satisfatória, para ser honesto.

font-display não deveria resolver isso?

A propriedade font-display para @font-face deu essa escolha ao desenvolvedor da Web, enquanto anteriormente o navegador decidiu isso (IE e Edge favoreciam FOUT no passado, enquanto os outros navegadores favoreciam FOIT). No entanto, além disso, realmente não resolveu o problema.

Vários sites mudaram para font-display: swap quando isso foi lançado, e o Google Fonts até o tornou o padrão em 2019. O pensamento aqui era que era melhor para o desempenho exibir o texto o mais rápido possível , mesmo que está na fonte de fallback e, em seguida, troque a fonte quando finalmente for baixado.

Eu também apoiava isso naquela época, mas estou cada vez mais frustrado com o “efeito de hidratação” quando os downloads e os caracteres da fonte da Web se expandem (ou contraem) devido a diferenças entre as fontes. A Smashing Magazine, como a maioria dos editores, usa fontes da web e a captura de tela abaixo mostra a diferença entre a renderização inicial (com as fontes de fallback) e a renderização final (com as fontes da web):

Agora, quando colocadas lado a lado, as fontes da web são consideravelmente melhores e se encaixam na marca Smashing Magazine. Mas também vemos que há bastante diferença no layout do texto com as duas fontes. As fontes são de tamanhos muito diferentes e, por isso, o conteúdo da tela muda de lugar. Nesta era de Cores Web Vitals e Mudanças de Layout Cumulativas sendo (com toda razão!) reconhecidas como prejudiciais aos usuários, font-display: swap é uma escolha ruim por causa disso.

Voltei para font-display: block em sites que cuido, pois realmente acho a mudança de texto bastante chocante e irritante. Embora seja verdade que o block não pare os deslocamentos (a fonte ainda é renderizada em texto invisível), pelo menos os torna menos perceptíveis para o usuário. Também otimizei o carregamento de fontes pré-carregando as fontes que tornei o menor possível por fontes subconjuntos de auto-hospedagem - para que os visitantes muitas vezes vejam as fontes de reserva por apenas um pequeno período de tempo. Para mim, o “período de bloqueio” da swap foi muito curto e honestamente prefiro esperar um pouco mais para obter a renderização inicial correta.

Usando font-display: optional pode resolver FOIT e FOUT - a um custo

A outra opção é usar font-display: optional . Essa opção basicamente torna as fontes da web opcionais ou, em outras palavras, se a fonte não estiver lá no momento em que a página precisar, cabe ao navegador nunca trocá-la. Com esta opção, evitamos o FOIT e o FOUT basicamente usando apenas fontes que já foram baixadas.

Se a fonte da web não estiver disponível, voltaremos para a fonte de fallback, mas a próxima navegação da página (ou um recarregamento desta página) usará a fonte - pois o download deve ter terminado até então. No entanto, se a fonte da web não for tão importante para o site, pode ser uma boa ideia removê-la completamente - o que é ainda melhor para o desempenho da web!

As primeiras impressões contam e ter essa carga inicial sem fontes da web parece um pouco demais. Eu também acho – sem absolutamente nenhuma evidência para apoiar isso, a propósito! – que dará às pessoas a impressão, talvez subconscientemente, de que algo está “fora” no site e pode afetar a forma como as pessoas usam o site.

Portanto, todas as opções de fonte têm suas desvantagens, incluindo a opção de não usar fontes da Web ou usar fontes do sistema (o que é limitante - mas talvez não tão limitante quanto muitos pensam!).

Fazendo sua fonte substituta corresponder mais de perto à sua fonte

O santo graal do carregamento de fontes da web foi tornar a fonte de fallback mais próxima da fonte da web real para reduzir a mudança perceptível o máximo possível, para que o uso da swap seja menos impactante. Embora nunca possamos evitar as mudanças completamente, podemos fazer melhor do que na captura de tela acima. O aplicativo Font Style Matcher de Monica Dinculescu é frequentemente citado em artigos de carregamento de fontes e dá uma visão fantástica do que deveria ser possível aqui. Ele permite que você sobreponha o mesmo texto em duas fontes diferentes para ver quão diferentes elas são e ajustar as configurações de fonte para alinhá-las mais de perto:

Infelizmente, o problema com a correspondência de estilo de fonte é que não podemos fazer com que esses estilos CSS se apliquem apenas às fontes de fallback, portanto, precisamos usar JavaScript e a API FontFace.load para aplicar (ou reverter) essas diferenças de estilo quando a web fonte carrega .

A quantidade de código não é enorme, mas ainda parece um pouco mais de esforço do que deveria. Embora existam outras vantagens e possibilidades de usar a API JavaScript para isso, conforme explicado por Zach Leatherman nesta fantástica palestra de 2019 - você pode reduzir os refluxos e lidar com o modo data-server e prefers-reduced-motion (observe no entanto que ambos foram expostos ao CSS desde aquela palestra).

Também é mais complicado lidar com fontes em cache que já temos, sem mencionar as diferenças em vários estilos de fallback. Aqui na Smashing Magazine, tentamos várias alternativas para fazer o melhor uso das fontes do sistema que diferentes usuários e sistemas operacionais instalaram:

 font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;

Saber qual fonte é usada ou ter ajustes separados para cada um e garantir que eles sejam aplicados corretamente pode se tornar bastante complexo rapidamente.

Uma solução melhor está chegando

Então, isso é uma breve atualização sobre como as coisas estão hoje. No entanto, há alguma fumaça começando a aparecer no horizonte.

Animado para o descritor CSS "size-adjust" para fontes: reduza as mudanças de layout combinando uma fonte substituta e uma fonte da Web primária por meio de um fator de escala para glifos (porcentagem).

Veja https://t.co/mdRW2BMg6A por @cramforce para uma demonstração (Chrome Canary/FF Nightly with flags) pic.twitter.com/hEg1HfUJlT

— Addy Osmani (@addyosmani) 22 de maio de 2021

Como mencionei anteriormente, o principal problema com a aplicação das diferenças de estilo de fallback foi adicioná-las e removê-las. E se pudéssemos dizer ao navegador que essas diferenças são apenas para as fontes de fallback?

É exatamente isso que um novo conjunto de descritores de fonte propostos como parte do CSS Fonts Module Level 5 faz. Eles são aplicados às declarações @font-face onde a fonte individual é definida.

Simon Hearne escreveu sobre esta atualização proposta para a especificação de descritores de face de fonte que inclui quatro novos descritores: ascent-override , descent-override , line-gap-override e advance-override (desde que foi descartado). Você pode brincar com o playground F-mods que Simon criou para carregar suas fontes personalizadas e alternativas e, em seguida, brincar com as substituições para obter uma combinação perfeita.

Como Simon escreve, a combinação desses quatro descritores nos permitiu substituir o layout da fonte de fallback para corresponder à fonte da web, mas eles apenas modificam realmente o espaçamento e o posicionamento vertical. Portanto, para espaçamento entre caracteres e letras, precisaremos fornecer CSS adicional.

Mas as coisas parecem estar mudando mais uma vez. Mais recentemente, advance-override foi descartada em favor do próximo descritor size-adjust que nos permite reduzir as mudanças de layout combinando uma fonte de fallback e uma fonte da Web primária por meio de um fator de escala para glifos (porcentagem).

Como funciona? Digamos que você tenha o seguinte CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } h1 { font-family: Lato, Arial, sans-serif; }

Então o que você faria é criar um @font-face para a fonte de fallback Arial e aplicar descritores de ajuste a ela. Você obterá o seguinte trecho de CSS então:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

Isso significa que, quando o Lato-fallback é usado inicialmente (já que Arial é uma fonte local e pode ser usada imediatamente sem nenhum download adicional), as size-adjust e ascent-override permitem que você aproxime isso da fonte Lato. É uma declaração extra @font-face para escrever, mas certamente muito mais fácil do que os aros que tivemos que pular antes!

No geral, existem quatro descritores @font-face principais incluídos nesta especificação: size-adjust , ascent-override , descent-override e line-gap-override com alguns outros ainda sendo considerados para subscrito, sobrescrito e outros casos de uso .

Malte Ubl criou uma ferramenta muito útil para calcular automaticamente essas configurações com duas fontes e um navegador que suporta essas novas configurações (mais sobre isso em um momento!). Como Malte aponta, os computadores são bons nesse tipo de coisa! Idealmente, poderíamos também expor essas configurações para fontes comuns para desenvolvedores da web, por exemplo, talvez dar essas dicas em coleções de fontes como Google Fonts? Isso certamente ajudaria a aumentar a adoção.

Agora, diferentes sistemas operacionais podem ter configurações de fonte ligeiramente diferentes e acertar exatamente é basicamente uma tarefa impossível, mas esse não é o objetivo. O objetivo é fechar a lacuna usando font-display: swap não é mais uma experiência tão chocante, mas não precisamos ir aos extremos de fontes da web optional ou não.

Quando podemos começar a usar isso?

Três dessas configurações já foram enviadas no Chrome desde a versão 87 , embora o descritor size-adjust chave ainda não esteja disponível em nenhum navegador estável. No entanto, o Chrome Canary tem, assim como o Firefox por trás de uma bandeira, então este não é um conceito abstrato e distante, mas algo que pode pousar muito em breve.

No momento, a especificação tem todos os tipos de isenções e avisos de que ainda não está pronto para o tempo real, mas certamente parece que está chegando lá. Como sempre, há um equilíbrio entre nós, designers e desenvolvedores, testando e dando feedback, e desencorajando o uso, para que a implementação não fique travada porque muitas pessoas acabam usando um rascunho anterior.

O Chrome declarou sua intenção de disponibilizar size-adjust no Chrome 92 com lançamento previsto para 20 de julho, presumivelmente indicando que está quase lá.

Então, ainda não está pronto, mas parece que está chegando em um futuro muito próximo. Enquanto isso, experimente a demonstração no Chrome Canary e veja se ela pode se aproximar um pouco mais de resolver seus problemas de carregamento de fontes e o impacto do CLS que eles causam.