29Aug

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

click fraud protection


Se você for propenso a assistir o painel do navegador com um olho de águia, você pode ter percebido que as páginas freqüentemente carregam suas imagens e layout antes de carregar seu texto - o padrão de carregamento oposto exato que experimentamos na década de 1990.O que está acontecendo?

Today's Question &A sessão de atendimento chega a cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento comunitário de sites Q & A.

O questionário

SuperUser Laurent é muito curioso sobre por que exatamente as páginas parecem carregar elementos de forma completamente diferente do que faziam uma vez. Ele escreve:

Eu notei que recentemente muitos sites são lentos para exibir seu texto. Geralmente, o fundo, imagens e assim por diante serão carregados, mas não há texto. Depois de algum tempo, o texto começa a aparecer aqui e aí( nem sempre é tudo ao mesmo tempo).

basicamente funciona o oposto como costumava, quando o texto foi exibido primeiro, então as imagens e o resto estavam sendo carregados posteriormente. Qual a nova tecnologia que está criando esse problema? Qualquer ideia?

instagram viewer

Observe que estou com uma conexão lenta, o que provavelmente acentua o problema.

Veja [acima] para um exemplo - tudo está carregado, mas leva mais alguns segundos antes do texto ser finalmente exibido.

Então, o que dá?Laurent e muitos de nós, lembre-se de uma época em que o texto foi carregado primeiro e tudo mais - gifs animados de garrish, fundos de azulejos e todos os outros artefatos da navegação na web até o final dos anos 90 - vieram mais tarde. O que causa a situação atual dos elementos de design primeiro, texto mais tarde?

A Resposta

O colaborador do SuperUser Daniel Andersson oferece uma resposta maravilhosamente detalhada que chega ao fundo do mistério why-the-fonts-load-last:

. Um dos motivos é que os designers da Web hoje gostam de usar fontes da Web( geralmente no formato WOFF), por exemploatravés das fontes da Web do Google.

Anteriormente, as únicas fontes que podiam ser exibidas em um site eram aquelas que o usuário instalou localmente. Como e. Os usuários de Mac e Windows não tiveram necessariamente as mesmas fontes, os designers instintivamente sempre definiram regras como fonte de família

: Arial, Helvetica, sans-serif;

onde, se a primeira fonte não fosse encontrada no sistema, o navegador procuraria o segundo e, finalmente, uma fonte "sans-serif".

Agora, pode-se dar uma URL de fonte como uma regra CSS para que o navegador faça o download de uma fonte, como tal:

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

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

fonte-família: 'Droid Serif', sans-serif;

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

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

( Além disso, os designers pulverizam JavaScript em todos os lugares em todos os dias, 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, porém: a tendência geral para o texto ser adiadaesses tempos são o problema de fontes da web descrito acima, eu acredito.)

Adição:

Esta resposta tornou-se muito upvoted, embora eu não entrei em muitos detalhes, ou talvez porque disto. Houve muitos comentários no tópico da pergunta, então eu vou tentar expandir um pouco [...]

O fenômeno é aparentemente conhecido como "flash de conteúdo não destruído" em geral, e "flash de texto não editado", em particular. A procura de "FOUC" e "FOUT" dá mais informações.

Posso recomendar a publicação do publicador da web Paul Irish no FOUT em conexão com fontes da web.

O que se pode notar é que navegadores diferentes lidam com isso de forma diferente. Eu escrevi acima que testei o Opera e o Chrome, que ambos se comportaram de forma semelhante. Todos os recursos baseados no WebKit( Chrome, Safari, etc.) escolhem evitar FOUT por e não renderizando texto de fonte da Web com uma fonte de retorno durante o período de carregamento da fonte da Web. Mesmo que a fonte da web esteja em cache, será um atraso de renderização .Há muitos comentários neste tópico de perguntas dizendo o contrário e que é errado que as fontes em cache se comportem assim, mas, por exemplo,a partir do link acima:

Em quais casos você obtém um FOUT

  • Will: Download e exibição de um ttf remoto /otf/ woff
  • Will: Exibindo um ttf em cache /otf/ woff
  • Will: Download e exibição de um data-uri ttf /otf/ woff
  • Will: Exibindo um dados em cache-uri ttf /otf/ woff
  • Não será: Exibindo uma fonte que já está instalada e nomeada em sua pilha de fontes tradicionais
  • Não será: Exibindo uma fonte instalada e nomeada usando o local() localização

Uma vez que o Chrome aguarda até que o risco FOUT tenha desaparecido antes da renderização, isso dá um atraso. Para o qual extensão o efeito é visível( especialmente quando o carregamento do cache) parece ser dependente entre outras coisas a quantidade de texto que precisa ser renderizado e talvez outros fatores, mas o cache não remove completamente o efeito.

Irish também tem algumas atualizações sobre o comportamento do navegador em 2011-04-14 na parte inferior da publicação:

  • Firefox ( a partir do FFb11 e FF4 Final) já não possui FOUT! Wooohoo! Http: //bugzil.la/ 499292 Basicamente, o texto é invisível por 3 segundos e, em seguida, traz de volta a fonte de retorno. O webfont provavelmente irá carregar dentro desses três segundos, porém. .. espero que. ..
  • IE9 suporta WOFF e TTF e OTF( embora exija uma coisa de bits de incorporação - principalmente discutida se você usar o WOFF)., SINCRONEM! !!IE9 tem um FOUT.:(
  • Webkit tem um patch esperando para aterrar para mostrar o texto de retorno após 0,5 segundos. Tão comportamento como FF, mas 0,5s em vez de 3s.

Se essa era uma questão destinada aos designers, poderia-se entrar em maneiras de evitar esses tiposde problemas como o webfontloader, mas essa seria outra questão. O link Paul Irish envia mais detalhes sobre este assunto.

Tem algo a ser adicionado à explicação? Som nos comentários. Deseja ler mais respostas de outras tecnologias, Usuários experientes do Stack Exchange? Veja o tópico de discussão completo aqui.