Por que as páginas da Web não exibem seu texto imediatamente?

Índice:

Por que as páginas da Web não exibem seu texto imediatamente?
Por que as páginas da Web não exibem seu texto imediatamente?

Vídeo: Por que as páginas da Web não exibem seu texto imediatamente?

Vídeo: Por que as páginas da Web não exibem seu texto imediatamente?
Vídeo: How to change the Automatic Calculation and Multi-Threading Features in Excel 2013 - YouTube 2024, Maio
Anonim
 Se você está propenso a observar o painel do navegador com um olho de águia, deve ter notado que as páginas carregam com frequência as imagens e o layout antes de carregar o texto - o padrão de carregamento exatamente oposto que vimos nos anos 90. O que está acontecendo?
Se você está propenso a observar o painel do navegador com um olho de águia, deve ter notado que as páginas carregam com frequência as imagens e o layout antes de carregar o texto - o padrão de carregamento exatamente oposto que vimos nos anos 90. O que está acontecendo?

A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser, uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade.

A questão

Leitor de SuperUsuários Laurent está muito curioso sobre por que exatamente páginas parecem carregar elementos de forma completamente diferente do que antigamente. Ele escreve:

I’ve noticed that recently many websites are slow to display their text. Usually, the background, images and so on are going to be loaded, but no text. After some time the text starts appearing here and there (not always all of it at the same time).

It basically works the opposite as it used to, when the text was displayed first, then the images and the rest was loading afterwards. What new technology is creating this issue? Any idea?

Note that I’m on a slow connection, which probably accentuates the problem.

See [above] for an example – everything’s loaded but it takes a few more seconds before the text is finally displayed.

Então, o que dá? Laurent, e muitos de nós, lembram-se de uma época em que o texto foi carregado primeiro e todo o resto - GIFs grosseiros animados, fundos em mosaico e todos os outros artefatos da navegação na Web do final dos anos 90 - vieram depois. O que causa a situação atual dos elementos de design primeiro, texto depois?

A resposta

O colaborador do SuperUser, Daniel Andersson, oferece uma resposta maravilhosamente detalhada que vai direto ao fundo do mistério "por que as fontes carregam":

One reason is that web designers nowadays like to use web fonts (usually in WOFF format), e.g. throughGoogle Web fonts.

Previously, the only fonts that were able to be displayed on a site was those that the user had locally installed. Since e.g. Mac and Windows users not necessarily had the same fonts, designers instinctively always defined rules as

font-family: Arial, Helvetica, sans-serif;

onde, se a primeira fonte não fosse encontrada no sistema, o navegador procuraria a segunda fonte e, por último, uma fonte "sans-serif" alternativa.

Agora, é possível fornecer uma URL de fonte como uma regra de CSS para fazer o navegador baixar uma fonte, como:

@import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700);

e, em seguida, carregue a fonte de um elemento específico, por exemplo:

font-family: 'Droid Serif',sans-serif;

Isso é muito popular para poder usar fontes personalizadas, mas também leva ao problema de que nenhum texto é exibido até que o recurso tenha sido carregado pelo navegador, o que inclui o tempo de download, o tempo de carregamento da fonte e o tempo de renderização. Espero que este seja o artefato que você está experimentando.

Como exemplo: um dos meus jornais nacionais, o Dagens Nyheter, usa fontes da web para suas manchetes, mas não suas indicações, então quando esse site é carregado, geralmente vejo os leads primeiro e meio segundo depois todos os espaços em branco acima são preenchidos com manchetes (isso é verdade no Chrome e no Opera, pelo menos. Não tentei outros).

(Além disso, os designers espalham o JavaScript em todos os lugares atualmente, então talvez alguém esteja tentando fazer algo inteligente com o texto, e é por isso que está atrasado. Isso seria muito específico do site: a tendência geral de o texto ser atrasado nesses termos. vezes é o problema de fontes da web descrito acima, eu acredito.)

Adição:

Esta resposta ficou muito defendida, embora eu não tenha entrado em muitos detalhes, ou talvezPorque disto. Houve muitos comentários no tópico da pergunta, então tentarei expandir um pouco […]

O fenômeno é aparentemente conhecido como “flash de conteúdo não-estilizado” em geral, e “flash de texto não-estilizado” em particular. Procurando por “FOUC” e “FOUT” dá mais informações.

Posso recomendar a postagem do web designer Paul Irish no FOUT em conexão com fontes da web.

O que se pode notar é que diferentes navegadores lidam com isso de maneira diferente. Eu escrevi acima que eu tinha testado o Opera e Chrome, que se comportaram de forma semelhante. Todas as baseadas no WebKit (Chrome, Safari, etc.) optam por evitar o FOUT pornão renderização de texto de fonte da web com uma fonte de fallback durante o período de carregamento da fonte da web. Mesmo se a fonte da Web é armazenada em cache,vai ser um atraso de renderização. Há muitos comentários neste encadeamento de pergunta dizendo o contrário e é totalmente errado que as fontes armazenadas em cache se comportem assim, mas, por exemplo, a partir do link acima:

Em que casos você receberá um FOUT

  • Vai: Baixando e exibindo um remoto ttf / otf / woff
  • Vai: Exibindo um ttf / otf / woff em cache
  • Vai: Baixando e exibindo um data-uri ttf / otf / woff
  • Vai: Exibindo um dado em cache-uri ttf / otf / woff
  • Não vou: Exibindo uma fonte já instalada e nomeada em sua pilha de fontes tradicional
  • Não vou: Exibindo uma fonte que é instalada e nomeada usando o local ()

Como o Chrome aguarda até que o risco FOUT desapareça antes da renderização, isso gera um atraso. Ao qualextensão o efeito é visível (especialmente ao carregar do cache) parece depender, entre outras coisas, da quantidade de texto que precisa ser renderizada e talvez de outros fatores, mas o cache não remove completamente o efeito.

O irlandês também tem algumas atualizações sobre o comportamento do navegador em 2011–04–14 na parte inferior do post:

  • Raposa de fogo (a partir de FFb11 e FF4 Final) não tem mais FOUT! Wooohoo! Http: //bugzil.la/499292 Basicamente, o texto fica invisível por 3 segundos e, em seguida, traz de volta a fonte de fallback. O webfont provavelmente carregará dentro desses três segundos, embora … esperançosamente..
  • O IE9 suporta WOFF e TTF e OTF (embora exija uma coisa de bits de incorporação - principalmente discutível se você usar WOFF). CONTUDO!!! IE9 tem um FOUT.:(
  • O Webkit tem um patch esperando para aterrissar para mostrar o texto de fallback após 0,5 segundo. Então, mesmo comportamento como FF, mas 0,5s em vez de 3s.

Se esta foi uma questão destinada aos designers, poder-se-ia procurar formas de evitar estes tipos de problemas, como

webfontloader

mas isso seria outra questão. A ligação de Paul Irish é mais detalhada sobre esse assunto.

Tem algo a acrescentar à explicação? Soe fora nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.

Recomendado: