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

Se você está propenso a observar o painel do navegador com um olho de águia, você deve ter notado que as páginas carregam com frequência suas imagens e layout antes de carregar seu texto - o padrão de carregamento exatamente oposto que experimentamos durante a década de 1990. 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:

Tenho notado que recentemente muitos sites demoram a exibir seu texto. Normalmente, o fundo, as imagens e assim por diante serão carregados, mas não haverá texto. Depois de algum tempo, o texto começa a aparecer aqui e ali (nem sempre tudo ao mesmo tempo).

Basicamente funciona ao contrário do que costumava fazer, quando o texto era exibido primeiro, depois as imagens e o restante estavam sendo carregados depois. Que nova tecnologia está criando esse problema? Qualquer ideia?

Note que estou em uma conexão lenta, o que provavelmente acentua o problema.

Veja [acima] para um exemplo - tudo está carregado, mas leva mais alguns segundos até que o texto seja finalmente exibido.

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 animados, fundos de azulejos e todos os outros artefatos da navegação na Web dos anos 90 - veio 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 de por que as fontes carregam o último:

Uma razão é que os web designers hoje em dia gostam de usar fontes da web (geralmente no formato WOFF), por exemplo. através das fontes do Google Web.

Anteriormente, as únicas fontes que podiam ser exibidas em um site eram aquelas que o usuário tinha instalado localmente. Desde e. Usuários de Mac e Windows não necessariamente tinham as mesmas fontes, os designers instintivamente sempre definiam regras como
font-family: Arial, Helvética, sem serifa; 
onde, se a primeira fonte não foi encontrada no sistema, o navegador procuraria a segunda fonte e, por último, uma fonte substituta "sans-serif".

Agora, é possível fornecer uma URL de fonte como uma regra de CSS para fazer com que o navegador baixe uma fonte, como tal:
@import url (http://fonts.googleapis.com/css?family=Droid+Serif:400,700); 
e, em seguida, carregue a fonte de um elemento específico, por exemplo:
família de fontes: '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. Eu 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 qualquer lugar nos dias de hoje, 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 talvez Porque disto. Houve muitos comentários no tópico da questão, então vou tentar 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 por não texto de fonte da web de renderização 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 que já está 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 qual extensão o efeito é visível (especialmente ao carregar do cache) parece ser dependente, entre outras coisas, da quantidade de texto que precisa ser renderizado 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 a partir de 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 depois traz de volta a fonte de fallback. O webfont provavelmente carregará dentro desses três segundos, embora… esperançosamente…

IE9 suporta WOFF e TTF e OTF (embora exija uma coisa de bitset de incorporação - principalmente discutível se você usar WOFF). CONTUDO!!! IE9 tem um FOUT. :(

O Webkit tem um patch aguardando para ser exibido para mostrar o texto de fallback após 0,5 segundo. Então, o mesmo comportamento que o 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. O link de Paul Irish é mais detalhado 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.