Por que os sites não exibem imediatamente seu texto atualmente?

Notei que recentemente muitos sites demoram a exibir seu texto. Normalmente, o plano de fundo, as imagens e assim por diante serão carregados, mas nenhum texto. Depois de algum tempo, o texto começa a aparecer aqui e ali (nem sempre todo ao mesmo tempo).

Basicamente, funciona do contrário: quando o texto era exibido primeiro, as imagens e o restante eram carregados depois. Que nova tecnologia está criando esse problema? Qualquer ideia?

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

Veja abaixo um exemplo - tudo está carregado, mas leva mais alguns segundos para que o texto seja finalmente exibido:

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

Anteriormente, as únicas fontes que podiam ser exibidas em um site eram aquelas que o usuário instalava localmente. Como, por exemplo, usuários de Mac e Windows não tinham necessariamente as mesmas fontes, os designers sempre instintivamente definiam regras como

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

onde, se a primeira fonte não foi encontrada no sistema, o navegador procuraria a segunda e, finalmente, uma fonte "sans-serif" de fallback.

Agora, pode-se fornecer um URL da fonte como uma regra CSS para fazer com que o navegador faça o download de uma fonte, como:

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

e carregue a fonte para 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é o recurso ter 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á enfrentando.

Como exemplo: um dos meus jornais nacionais, Dagens Nyheter , usa fontes da Web como manchetes, mas não seus leads; portanto, quando esse site é carregado, geralmente os vejo 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 borrifam o JavaScript absolutamente em todos os lugares hoje em dia, 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 do texto a atrasar nesses textos. vezes, é o problema das fontes da web descrito acima, acredito.)

Adição

Essa resposta ficou muito positiva, embora eu não tenha entrado em muitos detalhes, ou talvez por causa disso. Houve muitos comentários no segmento de perguntas, então tentarei expandir um pouco (muitos comentários parecem ter desaparecido pouco tempo após a proteção do tópico - algum moderador provavelmente os limpou manualmente). Além disso, leia as outras respostas neste tópico, pois todas elas se expandem à sua maneira.

O fenômeno é aparentemente conhecido como "flash de conteúdo não estilizado" em geral e "flash de texto não estilizado" em particular. A busca por "FOUC" e "FOUT" fornece mais informações.

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

O que se pode notar é que navegadores diferentes lidam com isso de maneira diferente. Escrevi acima que havia testado o Opera e o Chrome, que se comportavam da mesma forma. Todos os baseados no WebKit (Chrome, Safari etc.) optam por evitar FOUT ao não renderizar o texto da fonte da Web com uma fonte substituta durante o período de carregamento da fonte da Web. Mesmo que a fonte da Web seja armazenada em cache, haverá um atraso na renderização . Há muitos comentários neste tópico de perguntas que dizem o contrário e que é totalmente errado que as fontes em cache se comportem assim, mas, por exemplo, no link acima:

Em que casos você receberá um FOUT

• Will: Fazendo o download e exibindo um ttf / otf / woff remoto
• Will: Exibindo um ttf / otf / woff em cache
• Will: Fazendo o download e exibindo um data-uri ttf / otf / woff
• Will: Exibindo um data-uri em cache ttf / otf / woff
• Não: Exibindo uma fonte que já está instalada e nomeada na pilha de fontes tradicional
• Não será: exibindo uma fonte instalada e nomeada usando o local ()

Como o Chrome aguarda até que o risco FOUT acabe antes da renderização, isso atrasa. Até que ponto 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 armazenamento em 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 da postagem:

• O Firefox (a partir do FFb11 e FF4 Final) não possui mais um FOUT! Wooohoo! http://bugzil.la/499292 Basicamente, o texto fica invisível por 3 segundos e, em seguida, retorna a fonte de fallback. O webfont provavelmente será carregado dentro desses três segundos ... espero ...
• O IE9 suporta WOFF e TTF e OTF (embora exija algo de conjunto de bits de incorporação - principalmente discutível se você usar WOFF). CONTUDO!!! O IE9 tem um FOUT. :(
• O Webkit tem um patch aguardando para pousar para mostrar o texto de fallback após 0,5 segundos. O mesmo comportamento de FF, mas 0,5s em vez de 3s.
• Além disso : o Blink também possui um bug registrado , mas parece que não foi alcançado um consenso final sobre o que fazer com ele - atualmente a mesma implementação do WebKit.

Se essa fosse uma pergunta voltada para designers, webfontloaderseria possível evitar maneiras de evitar esse tipo de problema , mas isso seria outra pergunta. O link Paul Irish entra em mais detalhes sobre esse assunto.

A razão para isso é que o texto que você ainda não pode ler está sendo renderizado com uma fonte da Web que ainda está a caminho dos canais para o seu navegador.

Além disso, como seu navegador é o Google Chrome, que usa o WebKit para renderizar a página, foi decidido por eles (ou seja, WebKit) que é melhor você não ver nenhum texto até que a fonte da Web seja baixada. Se, no entanto, você é um desenvolvedor que prefere que o texto seja legível em uma fonte de sistema alternativa adequada, use algo como o WebFont Loader do Google para conseguir isso.

Resposta curta: AJAX ou WOFF

Existem várias causas de os sites serem "lentos para exibir seu texto" . A lentidão no portableapps.com é causada pelo download de fontes WOFF . No entanto, o que você descreve como "o texto começa a aparecer aqui e ali" é mais frequentemente causado pelo AJAX .

Um site é composto de várias partes. Como essas peças são baixadas e montadas é uma opção de design sob o controle do web designer . A lentidão é causada pela maneira como o desenvolvedor escolhe montar os seguintes blocos de construção:

• Página HTML inicial
• CSS
• JS
• Imagens
• Fontes WOFF
• Solicitações AJAX
• Manipulação de DOM

Tradicionalmente sites:

Tradicionalmente, era comum os desenvolvedores colocarem o conteúdo do texto na página HTML inicial e exibi-lo assim que estivesse disponível . O HTML faria referência a vários recursos que seriam baixados. O navegador então redesenhava progressivamente a tela para incluir os estilos e imagens à medida que se tornavam disponíveis. AJAX e WOFF não estavam disponíveis.

Sites da WOFF:

As fontes WOFF permitem que um site use fontes que normalmente não estão disponíveis para o navegador, baixando fontes com o site . Alguns desenvolvedores instruem o navegador a não exibir o conteúdo do texto até que todas as fontes WOFF tenham sido baixadas. Na minha experiência, essa abordagem ainda não ganhou muito uso.

Sites AJAX:

Alguns desenvolvedores optam por não incluir o conteúdo do texto na página HTML inicial. Em vez disso, eles optam por baixar o conteúdo de texto usando o AJAX. Isso acontece após o carregamento da página básica . Na minha experiência, esse método ganhou uma adoção muito mais ampla do que as fontes WOFF e é frequentemente a causa da lentidão que você descreve.

Determinando a causa

Para determinar a causa de um site específico, é necessário analisar usando ferramentas como Firebug ou Chrome Developer Tools . Ou, como alternativa, você pode abrir o site usando o Internet Explorer 8 , que suporta AJAX, mas não WOFF. Se o site ainda estiver lento, o problema é AJAX e não WOFF.

Muitas vezes, pode ser uma escolha deliberada evitar o "flash de conteúdo não estilizado". Se o texto exibido antes do CSS for carregado, você o verá brevemente como parece bruto e depois pisca quando o navegador o redesenha. Ao colocar alguns estilos embutidos básicos para ocultar inicialmente o conteúdo, que são substituídos na folha de estilo real ou usando JS, os desenvolvedores evitam esse flash.

Como outros observaram, as fontes personalizadas provavelmente estão contribuindo para o atraso.

Para fornecer um pouco mais de experiência, o navegador está fazendo aproximadamente o seguinte antes de poder renderizar o conteúdo da página na tela:

1. buscar HTML (várias viagens de ida e volta para DNS, TCP, solicitação / resposta)
2. comece a analisar o HTML, descubra recursos externos, como CSS e JS externos. Observe que CSS bloqueia o layout e JS bloqueia a análise. Portanto, recursos externos como CSS e JS carregados no início do documento (por exemplo, na cabeça) diminuem o tempo que leva para uma página exibir o conteúdo na tela.
3. buscar CSS e JS externos (várias viagens de ida e volta: DNS e TCP se esses recursos estiverem em um domínio diferente, como CDN, bem como um RTT para a solicitação / resposta)
4. Depois que o CSS e JS externos terminarem o carregamento, analise / execute JS, analise / aplique estilos
5. se o CSS fizer referência a fontes personalizadas, essas fontes também precisarão ser baixadas, resultando em atrasos adicionais de ida e volta para renderizar qualquer parte da página que dependa das fontes personalizadas

Embora não se refira especificamente aos atrasos causados ​​por fontes personalizadas, escrevi recentemente uma postagem no blog que fornece informações adicionais sobre as causas dos atrasos na renderização. Ele fornece algumas sugestões para minimizar o tempo para pintar primeiro as suas páginas. Espero que isso seja útil para os leitores interessados ​​em tornar suas páginas mais rápidas, incluindo as páginas que desejam usar fontes personalizadas: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -um segundo/

Resposta curta: Desenvolvedores.

Quando as tags de link e script que fazem referência a documentos externos (como arquivos .css ou .js) são colocadas no cabeçalho do documento (maior no fluxo que o corpo e seus elementos), elas são carregadas primeiro. JavaScript é executado a partir da marcação que faz referência a ele; se houver muito código para processar, ou for complicado, ou mais comumente, se o texto que você espera ver estiver sendo renderizado em um servidor e preenchido no documento em carga - e esse código do servidor também for complicado, E / S grande ou bloqueadora devido ao processamento de várias solicitações simultâneas, você certamente notará um tempo de inatividade antes que o HTML tenha a chance de renderizar. Alguns desenvolvedores optam por carregar o JavaScript não relacionado à visualização após marcação e estilos (no final do corpo),

A velocidade da conexão com a Internet desempenha um papel no download lento de dados, obviamente, mas códigos mal escritos ou pilhas de tecnologia mal projetadas (para o tipo de site) desempenham um papel cada vez mais central no carregamento lento de conteúdo dinâmico, como conexões de rede mais rápidas abordagem onipresente.

Em resumo, muitos objetos carregáveis ​​que precisam ser carregados de HTTP GETs separados antes que a página possa ser exibida e uma dependência excessiva da latência média como uma medida da integridade do site.

A primeira refere-se a todas as .css, .js e webfonts que a página carrega, para não mencionar o fato de que muitos sites também precisam recuperar objetos JSON através de solicitações XHR e gerar HTML a partir daqueles que usam algum tipo de modelo.

Mas por que eles não percebem que o site é lento?

Provavelmente porque eles têm um cache de memória em algum lugar para acelerar as coisas (ou apenas contam com os caches do sistema de arquivos) e estão medindo a integridade do site usando latência média. Assim, os objetos em cache são retornados com latência de 6 milcrossegundos e ocultam o fato de que muitas solicitações GET levam 5000 milissegundos para serem concluídas. As médias devem morrer. Viva a contagem de RTTs acima de um limite máximo aceitável! Esse número deve ser 0 ou, por definição, o RTT é inaceitável.

Bem, existem várias razões. Uma razão também é que os comandos para definir um plano de fundo ou no topo de uma página html frequentemente ou recuperados em um CSS separado carregado primeiro. antes do corpo do documento ser carregado, que contém o texto.

Outra causa é que, embora seja possível digitar o tamanho de uma imagem, na maioria dos casos, os web designers não fazem uso disso. E assim, o brouwser precisa carregar as imagens inteiras primeiro nas páginas para saber como envolver o texto.

Alguns designers, também querem mostrar as primeiras fotos e o próximo texto, conseguem isso com algum javascript; por exemplo, uma página simples mostra primeiro um banner e depois tudo o mais.

Mas se você está se perguntando por que há tantas coisas comerciais de spam em minhas páginas enquanto eu só quero ler as notícias, então há uma solução para você. Você pode usar bloqueadores de spam se estiver usando o Firefox. Com esse complemento, o webrowser conhece sites que fornecem spam e simplesmente os bloqueia, resultando em um carregamento de página muito mais rápido, enquanto você ainda pode ver as imagens importantes relacionadas aos artigos que você lê.

Eu recomendaria a todos que lidam com o carregamento lento da página para tentar o Fidler. O fidler pode ser usado com o IEexplorer ou com o FireFox (usando sua função de proxy). O Fidler realmente mostrará quanto tempo realmente leva e quando partes de uma página da web são carregadas. É uma ferramenta de depuração HTML.