Nos casos em que o conteúdo textual for carregado antes que as fontes baixáveis estejam disponíveis, os user agents podem renderizar o texto como ele seria renderizado se os recursos de fontes baixáveis não estivessem disponíveis ou eles podem renderizar o texto sem cor com cores substitutas para evitar um flash do texto usando uma fonte substituta – instruções de colocação de fonte.

A ambiguidade e falta de desenvolvedor de substituição na linguagem de especificação acima é uma grande lacuna e um problema de desempenho. Em primeiro lugar, a ambiguidade nos deixa com um comportamento inconsistente em vários navegadores e, em segundo, a falta de desenvolvedor de substituição significa que ou estamos renderizando o conteúdo que deve ser bloqueado, ou bloqueando desnecessariamente a renderização onde um retorno teria sido aceitável. Não existe uma única estratégia que funcione melhor em todos os casos.

Vamos quantificar o problema

Quantas vezes o algoritmo acima é chamado? Qual é o delta entre o tempo que o navegador estava pronto para processar o texto e o tipo de fonte que se tornou disponível? Falando nisso, quanto tempo geralmente leva o download de fonte? Podemos simplesmente iniciar a busca da fonte mais cedo para resolver o problema?

Quando isso acontece, o Chrome já rastreia as métricas necessárias para responder a todas as questões acima. Abra uma nova guia e vá até chrome://histograms para inspecionar as métricas (os curiosos podem ir até histograms.xml na fonte do Chromium) para seu perfil e histórico de navegação. As métricas específicas em que estamos interessados são:

• WebFont.HadBlankText: contagem de vezes que a renderização de texto foi bloqueada.
• WebFont.BlankTextShownTime: duração do Blank Text devido à renderização bloqueada.
• WebFont.DownloadTime.*: tempo para obter a fonte, segmentado por tamanho de arquivo.
• PLT.NT_Request: tempo até o primeiro byte de resposta (TTFB).

Desempenho de renderização de texto no Chrome para Android

Inspecionar seus próprios histogramas vai, sem dúvida, revelar alguns insights interessantes. No entanto, os dados do seu perfil representam a população global? O Chrome agrega estatísticas anônimas de uso dos usuários opt-in para ajudar a equipe de engenharia melhorar as características e o desempenho do Chrome, e eu tirei as mesmas métricas globais para o Chrome para Android. Vamos dar uma olhada…

29% dos carregamentos da página no Chrome para Android exibiram Blank Text: o user agent conhecia o texto que precisava pintar, mas foi impedido de fazê-lo devido ao recurso de fonte indisponível. No caso, a média do tempo de texto em branco foi de ~ 350 ms, ~ 750 ms para o percentual 75º, e um assustador ~ 2300 ms para o 95º.

Olhando para os tempos de download da fonte, também fica claro que mesmo as fontes menores (<10KB) podem demorar vários segundos para serem concluídas. Além disso, o tempo para obter a fonte é significativamente maior do que o para o primeiro byte de resposta HTML (ver PLT.NT_Request) que pode conter texto que pode ser renderizado. Como resultado, mesmo se fomos capazes de começar a busca por fonte em paralelo com a solicitação HTML, ainda existem muitos casos em que teríamos que bloquear a renderização de texto. Mais realisticamente, a busca por fonte seria adiada até sabemos que ela é necessária, o que significa esperar a resposta HTML, construir o DOM e resolver estilos, e todos eles adiam a renderização de texto ainda mais.

Desenvolvedores precisam do controle da estratégia de renderização de texto

Como os dados acima ilustram, buscar a fonte mais cedo e otimizar o tamanho do arquivo de recursos é importante, mas não suficiente para eliminar o “problema Blank Text”. A busca da rede pode demorar um pouco, e nós não podemos controlar isso.

Sabendo disso, nós podemos fornecer os controles necessários para os desenvolvedores especificarem a estratégia de renderização de texto desejada: existem casos em que usar um retorno é uma estratégia válida, e há casos em que a renderização deve ser bloqueada. Ambas as estratégias são válidas e podem coexistir na mesma página, dependendo do conteúdo que está sendo processado.

Em suma, o texto é quase sempre o único ativo mais importante na página, e nós precisamos oferecer aos desenvolvedores o controle sobre como e quando ele é processado. A proposta de renderização de fontes CSS deve, espero eu, resolver isso.

***

Ilya Grigorik faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.igvita.com/2015/04/10/fixing-the-blank-text-problem/