Corrigindo o problema Blank Text
Não existe uma única estratégia que funcione melhor em todos os casos. Mas conheça alternativas para resolver o problema Blank Text.
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 problemaQuantas 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).
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 textoComo 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/
É Developer Advocate no Google, trabalha com tudo o que está relacionado a desempenho na web, como melhores práticas, protocolos, padrões e desempenho do navegador.
